linux – SSHが自動的にすべてのIDファイルを試さないように設定するにはどうすればいいですか?

authentication linux ssh unix

ssh identity ファイルを ~/.ssh/ フォルダの中に入れています。そこにはおそらく 30 個ほどのファイルがあります

サーバーに接続する際には、以下のようなもので使用するIDファイルを指定します

ssh -i ~/.ssh/client1-identity client1@10.1.1.10

しかし、IDファイルを指定せずに、こんな感じのものを使っているだけだと

ssh user123@example.com

エラー

Too many authentication failures for user123

が発生します

IDファイルが指定されていなくて、sshがIDファイルを見つけられた場合、すべてのIDファイルを試してしまうからだと理解しています

また、~/.ssh/configファイルを編集して、次のような指定ができることも理解しています

Host example.com
PreferredAuthentications keyboard-interactive,password

を使用して、その接続が既知の ID ファイルを試すことを防ぐことができます

そこで、IDファイルを~/.ssh/ディレクトリの外に移動させるか、設定ファイルでIDファイル認証を無効にしたいホストを指定することができると思うのですが、デフォルトでIDファイルを検索しないようにSSHに指示する方法はありますか?あるいは、検索するファイルを指定する方法はありますか?

  131  cwd  2011-04-09


ベストアンサー

IdentitiesOnly=yes オプションと IdentityFile オプションを併用することができます (ssh_config man page を参照してください)。この方法で、どのファイルを探すかを指定することができます

この例では、ssh は ssh_config ファイルで指定された ID とコマンドラインで指定された 4 つの ID のみを調べます (エージェントによって提供された ID は無視されます)

ssh -o IdentitiesOnly=yes \
-o IdentityFile=id1.key \
-o IdentityFile=id2.key \
-i id3.key \
-i id4.key \
user123@example.com

-i-o IdentityFile=は互換性があります

.ssh/configでは、このようにconfigを含めることができます

Host example
User user123
Hostname example.com
IdentityFile ~/.ssh/id_rsa_example
IdentityFile ~/.ssh/id_rsa_example2
IdentitiesOnly yes

128  None  2011-04-09


user76528さんの短い回答は正しいのですが、私はちょうどこの問題を抱えていたので、いくつかの精緻な説明が役に立つだろうと思いました。また、「なぜ ssh は私の identityfile 設定オプションを無視しているのか」と疑問に思った場合は、この解決策も気になるかもしれません

まず第一に、ssh_config の他のすべてのオプションとは異なり、ssh は最初に見つかった IdentityFile を使用しません。その代わりに、IdentityFile オプションはそのファイルを使用する ID のリストに追加します。複数の IdentityFile オプションを積み重ねることができ、 ssh クライアントは、サーバがそのうちのひとつを受け入れるか接続を拒否するまですべてのオプションを試します

第二に、ssh-agent を使用している場合、ssh_config の IdentityFile (または -i) オプションで鍵を指定していなくても、ssh は自動的にエージェント内の鍵を使おうとします。これが Too many authentication failures for user エラーが発生する一般的な理由です。IdentitiesOnly yes オプションを使用すると、この動作を無効にします

複数のシステムに複数のユーザとして ssh している場合は、ssh_config のグローバルセクションに IdentitiesOnly yes を入れ、それぞれの IdentityFile を適切な Host サブセクションに入れることをお勧めします

90  chrishiestand  2012-06-12


私は一般的にそうしています

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

オプションは以下の通りです

  • -o IdentitiesOnly=yes – CLI経由で提供された鍵のみを使用し、$HOME/.sshまたはssh-agent経由で提供された鍵は使用しないようにSSHに指示します
  • -F /dev/null$HOME/.ssh/configの使用を無効にします
  • -i ~/path/to/some_id_rsa – 接続に明示的に使用するキー

Example

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

上の出力では、sshはCLI経由でmy_id_rsaの秘密鍵を識別しているだけで、それを使ってどこかのサーバに接続していることに注目してください

具体的には、これらのセクション

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

and:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

25  slm  2015-12-09


多くの鍵を持っている場合、必ず「認証に失敗しました」というエラーが発生します。パスワードを持っていて、単にパスワードを使ってログインしたい場合は、以下のようにしてください

パスワード認証のみを使用し、Public-key を使用せず、やや誤解を招く “keyboard-interactive” (パスワードを含む上位セット) を使用しないようにするには、コマンドラインから以下のようにします

ssh -o PreferredAuthentications=password user@example.com

14  Greg Rundlett  2015-06-19


IdentityFile を使用しますが、パスフレーズの再現を避けるために ssh-agent を使用し続けます

受け入れられている解決策は IdentitiesOnly yes を使用することで、ssh-agent を利用することができなくなり、結果として鍵を読み込む際にパスフレーズの入力を繰り返し求められることになります

ssh-agentを使い続けて、「認証失敗が多すぎる」というエラーを回避するには、次のようにしてください

  1. ssh-agentに自動的にキーをロードする対話型コンソール起動スクリプトを削除します

  2. クライアントの ssh 設定に AddKeysToAgent yes を追加してください。これにより、最初の接続時にパスフレーズの入力を求められますが、その後エージェントに鍵を追加します

  3. 認証が多すぎる」エラーが発生した場合は、ssh-add -D を使用します。これは単に ssh-agent キャッシュを「リセット」 (削除) するだけです。その後、同じセッション内で再度接続を試みます。パスフレーズの入力を求められますが、受け入れられれば、それがエージェントに追加されます。あなたのエージェントには鍵が 1 つしかないので、接続が許可されます。 ssh-agent はその後も同じセッション中に将来の接続のために存在し、再送を回避します

    Host ex example.com
    User joe
    HostName example.com
    PreferredAuthentications publickey,password
    IdentityFile /path/to/id_rsa
    AddKeysToAgent yes
    

10  AndrewD  2017-09-01


~/.ssh/configファイルの最後にこれを追加することで、設定されていないサーバでの鍵の使用を防ぐことができます

Host *
IdentitiesOnly=yes

4  Maxim Akristiniy  2019-07-23


ssh クライアントと ssh-agent は、SSH_AUTH_SOCK 環境変数 (起動時にエージェントによって設定される) によってクライアントに指定された名前の Unix ドメインソケットを介して通信しています

したがって、クライアントの単一の呼び出しがエージェントに問い合わせることを防ぐために、この変数には空の文字列のような無効なものを明示的に設定することができます

$ SSH_AUTH_SOCK= ssh user@server

このようなクライアントの呼び出しはエージェントとの通信に失敗し、~/.ssh/のファイルとして利用可能な身元、またはコマンドラインで-iを使って指定した身元をサーバに提供することしかできません

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

4  mikini  2017-06-02


最初から(ほぼ)答えが出ていましたね

Host *
PreferredAuthentications keyboard-interactive,password

私のために働いてくれた

0  Henry Grebler  2011-08-14


タイトルとURLをコピーしました