web-dev-qa-db-ja.com

sshはパスワードを決して要求しません

どういうわけか、私のSSHはパスワードの入力を決して望みません。

だから私は世界のどこかにあるランダムなサーバーにVPSをセットアップし、sshでそれに接続したい。

キーをセットアップできますが、これを行うと：

ssh -l some-user IP

エラーが表示されます：

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

詳細を見ると、パスワードがオプションの1つであることがわかります。

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

それでも、SSHはパスワードの入力を決して求めません。 publickeyメソッドと思われるもので5回試行した後、失敗します。なぜsshはパスワードを試さないのですか？！

念のため、私のssh_configファイルには次のものがあります。

PasswordAuthentication yes

完全なログ

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
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 XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA Host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
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: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root
sshpassword
14
Alexis Wilke

次を使用して、公開鍵認証を無効にしてログインしてみてください

ssh -o PubkeyAuthentication=no root@newserver
17
Klaus-Dieter Warzecha

ほとんどの場合、.ssh/configファイルに複数のidentityfile行があります。

identityfile構成の下にHostがある場合でも、グローバルに適用されます。つまり、sshは、サーバーからパスワードプロンプトを要求する前に、すべてのホストですべてのIDファイル（つまり公開キー）を試行します。

これを修正するには

  1. 1つを除くすべてのidentityfile行を削除する、または
  2. PubkeyAuthentication noを.ssh/configに追加、または
  3. -o PubkeyAuthentication=noパラメーターを使用してsshを実行します。

man 5 ssh_configから：

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

公開鍵を使用した一般的な手順：

  1. 一般に、クライアント（ワークステーション）ごとに1つの秘密キーのみを持ち、クライアントがアクセスする必要があるすべてのサーバーに一致する公開キーを配置する必要があります。つまり、サーバー間で公開キーを共有し、複数のデバイスで同じ秘密キーを使用しないでください。
  2. 常にデバイスでキーペアを生成し、公開キーのみを送信します。そうすれば、たとえサーバーが危険にさらされたとしても、あなたの秘密鍵はまだ安全で安全です。これは、たとえばバックアップなど、驚くべき方法で発生する可能性があります。
  3. 他の誰かがサーバーを管理している場合、youはそれらの公開鍵を提供する必要があります。 notキーペアを生成し、秘密鍵を送信する必要があります。そうすれば、彼らはあなたの鍵であなたになりすますことができません（もちろん、通常は彼らがやりたいことは何でもできます）。また、公開鍵では、整合性（つまり、誰かが公開鍵を変更しなかった）のみを保護する必要があります。秘密鍵では、機密性（つまり、他の誰も鍵を取得していない）を保存する必要があり、侵害されていないことを完全に確認することはできません。
  4. 複数のサーバーへの接続に同じ秘密キーを使用しても、サーバーを侵害しても他のサーバーは侵害されません（その秘密キーをサーバーに送信した場合を除きます。絶対にしないでください）。
  5. ワークステーションのセキュリティを侵害すると、とにかく秘密鍵が公開されます。複数の秘密キーを持つことはこれに役立ちません（異なる強力なパスフレーズがあり、それらのすべてが攻撃者に利用できるわけではない場合を除く）。

これにはいくつかの例外がありますが、多すぎません。

17
Olli

ローカルsshがパスワードを要求するのではなく、相手側のsshサーバーがパスワードを要求する必要があります。サーバーがパスワード認証を受け入れないように設定されている可能性があります。私もパスワードを要求しません。

4
Marc