web-dev-qa-db-ja.com

SSHDが「サーバーがキーを受け入れる」でハングするのはなぜですか

私は公開鍵認証を使用して1年間問題なくこのボックスにSSH接続しています。

クライアントまたはサーバーのssh構成は変更されていません。現在、ssh接続は完了したり失敗したりすることはなく、ハングするだけです。接続しようとしたときのデバッグ出力は次のとおりです。

OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/jivan/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <Host> [<ip>] port <port>.
debug1: Connection established.
debug1: identity file .ssh/id_rsa.pub type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file .ssh/id_rsa.pub-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-7ubuntu1
debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: ECDSA 81:63:05:0c:39:6b:77:d7:a2:25:93:30:80:f1:ba:0e
debug1: Host '[<Host>]:<port>' is known and matches the ECDSA Host key.
debug1: Found key in /home/jivan/.ssh/known_hosts:39
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/id_rsa.pub
debug1: Server accepts key: pkalg ssh-rsa blen 279

サーバーログ：

Feb 24 12:02:38 balance sshd[5734]: debug1: Forked child 6745.
Feb 24 12:02:38 balance sshd[6745]: Set /proc/self/oom_score_adj to 0
Feb 24 12:02:38 balance sshd[6745]: debug1: rexec start in 5 out 5 newsock 5 pip
e 7 sock 8
Feb 24 12:02:38 balance sshd[6745]: debug1: inetd sockets after dupping: 3, 3
Feb 24 12:02:38 balance sshd[6745]: Connection from 207.204.228.55 port 57967
Feb 24 12:02:38 balance sshd[6745]: debug1: Client protocol version 2.0; client 
software version OpenSSH_6.0p1 Debian-3ubuntu1
Feb 24 12:02:38 balance sshd[6745]: debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1
 pat OpenSSH*
Feb 24 12:02:38 balance sshd[6745]: debug1: Enabling compatibility mode for prot
ocol 2.0
Feb 24 12:02:38 balance sshd[6745]: debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
Feb 24 12:02:39 balance sshd[6745]: debug1: PAM: initializing for "jivan"
Feb 24 12:02:39 balance sshd[6745]: debug1: PAM: setting PAM_RHOST to "207.204.228.55"
Feb 24 12:02:39 balance sshd[6745]: debug1: PAM: setting PAM_TTY to "ssh"
Feb 24 12:02:40 balance sshd[6745]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Feb 24 12:02:40 balance sshd[6745]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Feb 24 12:02:40 balance sshd[6745]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Feb 24 12:02:40 balance sshd[6745]: debug1: trying public key file /home/jivan/.ssh/authorized_keys
Feb 24 12:02:40 balance sshd[6745]: debug1: fd 4 clearing O_NONBLOCK
Feb 24 12:02:40 balance sshd[6745]: debug1: matching key found: file /home/jivan/.ssh/authorized_keys, line 1
Feb 24 12:02:40 balance sshd[6745]: Found matching RSA key: 5f:8c:76:ad:48:6a:f5:73:03:6a:36:13:c0:ea:3b:45
Feb 24 12:02:40 balance sshd[6745]: debug1: restore_uid: 0/0

問題が何であるかについて何か考えはありますか？

更新：問題はそれが始まったのと同じくらい不思議なことに止まりました。何がこれを引き起こしたのかについての洞察にまだ興味があります。

linuxubuntusshssh-keys
3
JivanAmara

これは通常、逆引きDNSの問題が原因で発生します。先週、私のレガシーサーバーの1つでこれが発生しました。 sshd -dを呼び出すのは正しいことですが、代わりにsshd -dddを使用して実行し、debug3の出力が表示されない限り、DNSの逆引きの問題は実際には明らかになりません。

逆引きDNSの問題は発生しませんが常に接続の試行に関連する十分なDNSルックアップが失敗している場合（つまり、すべてのDNSサーバーが完全に利用できない場合、または関連するゾーンが十分にある場合）、これはひどくバックアップされます。逆引きゾーンはタイムアウトになります）、一部の構成では、システムへのsshアクセスを完全にロックアウトするだけで十分です。サーバーが焦って接続を切断した場合、クライアントのタイムアウトをどれだけ高く設定してもかまいません。

3
Andrew B

私もこの問題を抱えていましたが、ここでクライアントが話をする番でした。この場合、gpg-agent（ssh-agent-supportモードで実行）の存在が原因であるように見えました。それを強制終了するか、ssh-add -Dを実行すると、ssh接続を再開できます。

1
fche

上記の状況はDNSに関連している可能性が高いですが、直後にストールが発生し続けました

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

それも一貫していませんでした。それは次のことによって消えました：

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

実際のオリジンはIPv6トンネルの制限されたMTUであると思われますが、これはまだ確認していません。 Googleはこの質問を見つけます。

0
mcr

私の場合、それは破損したキーリングが原因でした。より多くのデバッグ情報（ssh -vvv）を使用して実行すると、次のようになります。

debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug2: input_userauth_pk_ok: fp
SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug3: sign_and_send_pubkey: RSA
SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

this ごとに、SSH_AUTH_SOCK変数に関連するヒントが得られました。それから私はそれを見つけました：

user@user-office / $ $SSH_AUTH_SOCK
bash: /run/user/1000/keyring/ssh: No such device or address

次に、このファイルを削除して、sshコマンドを再実行しました。これにより、パスプロンプトが表示され、機能しました。

0
Deleet