☰

authorized_keys にキーがあるのに、拒否されてしまいます

tag-icon • tag-icon ssh authentication public-key
authorized_keys にキーがあるのに、拒否されてしまいます

マシン M1 からマシン M2 に ssh を使用して接続しています (他のマシンの同じユーザーに対して)。ユーザーは両方のマシンで同じキーを共有していることにも言及する必要があります。パスワード認証では、すべて正常に動作しますが、公開キー認証ではそうではありません。M2~/.ssh/authorized_keysに承認された RSA キーがあることを確認しましたが、それでも ssh はパスワード認証にフォールバックします。次のようになりますssh -vvv。

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred 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: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

私は午前他のマシンから公開鍵認証を使用して接続できます (同じ鍵ではありません)。

この場合、キーベースの認証が失敗する可能性のある理由は何ですか?

注: マシンは両方とも SLES (SuSE Linux Enterprise Server) 11 です。

答え1

クライアントから使用して正しい操作を行っていましたssh -vvv。次のように、デバッグ モードで sshd とペアリングします。

2 番目のサーバー インスタンス: # /usr/sbin/sshd -p 1234 -dddd

接続するための専用クライアント: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

私の場合、重要な情報はクライアントにのみ印刷されていました。サーバーは

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

一方、クライアントは次のように考えました。

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

それで、ここで何が起こっていたのでしょうか?

サーバーが古すぎてヘルパーアルゴリズムをネゴシエートできなかった。キーも日付付き、しかし概ね問題ありません。

今の基本的なアプローチは何でしょうか?

  1. 別のポートで専用サーバーを起動する
  2. 新しいセッションでクライアントから接続する
  3. 両側の鍵交換を段階的に比較する
  4. 新しく生成された2番目のキーペアを使用して結果を検証する

この特定の例では、安全でない古いメソッドであり、非推奨であった（つまり、ここで説明されている）ことが明確に説明されていました。 https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

その古いボックスを更新できるようにするには、-o PubkeyAcceptedKeyTypes=+ssh-rsaクライアントの ssh コマンドラインに追加することで接続できました。

答え2

基本を確認してください:

  1. id_rsa と id_rsa.pub は M1 と M2 の両方に存在する
  2. id_rsa は M1 と M2 の両方で権限 600 (つまり所有者のみが読み書き可能) を持っています。
  3. authorized_keys ファイルには、キーが 1 行として貼り付けられています (改行なし)
  4. authorized_keysの権限は600です
  5. 通常、.ssh フォルダの権限は 600 (デフォルト) です。
  6. /homeから.sshまでの各フォルダの権限を確認します。
  7. RSA を使いたいのはわかりますが、DSA キーを試して、それが機能するかどうかを確認してください。機能すれば、SSH と RSA の構成がゼロになります。

答え3

表示されるエラーは

/home/joeuser/.ssh/id_dsa: No such file or directory

このファイルが存在し、追加した公開キーに対応する秘密キーが含まれており、そのファイルが次のユーザーに属しjoeuser、600ユーザー権限を持っていることを確認します。

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

また、次のように秘密鍵を明示的に定義することも必要です。

ssh -i ~/.ssh/id_rsa [email protected]

これが正しいキーかどうかわからない場合は、新しいRSAキーペアを作成することをお勧めします。

ssh-keygen -b 4096

公開キーの内容を~/.ssh/id_rsa.pubリモート サーバーの authorized_keys ファイルに追加します。他のサーバーにログインするために必要な既存の秘密キーを上書きしないように注意してください。

関連情報