web-dev-qa-db-ja.com

このユーザーのSSHキー認証が失敗するのはなぜですか？ （CENTOS 7）

新しいユーザーアカウントがコマンド経由でRSAキー認証を使用してCentos 7サーバーに正常にSSH接続できないという事実をデバッグしようとしています

ssh theuser@theserver

以下の観察を行うことができます。

  • ユーザーアカウント（ユーザー）が存在し、ロックされていません
  • ユーザーのホームフォルダーには、authorized_keysファイル（600アクセス許可）を含む.sshディレクトリ（700アクセス許可）が含まれています。
  • authorized_keysファイルには、ローカルマシンからの公開鍵のコピーが含まれています
  • ローカルマシンの〜/ .ssh/configファイルは、このサーバーに使用する正しいキーファイルを指します
  • sshは、キー認証が失敗したときにユーザーのパスワードを入力することで正常に実行できます
  • 公開鍵によるSSHは、別のユーザーアカウントで実行できます。
  • / var/log/secureファイルは、ユーザーとしてキーが拒否されても何も記録しません

私の同僚と私は行き詰まっているので、誰かがこの問題の原因を見つけて見つけるために取るべき次のステップを提案できますか？

編集：含まれているssh -vvv出力

debug1: Host 'theserver' is known and matches the ECDSA Host key.
debug1: Found key in /Users/ambulare/.ssh/known_hosts:20
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare (0x7fc#obfuscated#), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
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: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
centosssh
4
Ambulare

@DevilaNの提案のおかげで、私は問題を解決しました。

Ssh-copy-idを試行すると、「authorized_keysでのアクセスが拒否されました」というエラーが返されました。権限エラーだったので、authorized_keysファイルの所有権と権限のチェックに戻りました。このファイルでユーザーに所有権を設定しても（私の元の質問のように）、明らかに、私または同僚は最初のセットアップから何かをしました。これにより、所有権が「ルート」に変更されました。

それは単純な所有権の問題でした。

chown theuser:theuser authorized_keys

出来上がり、sshが動作しています。

グーグル検索を介してこの回答を見つけた人のために：authorized_keysファイルの間違ったユーザーによる所有権は、ssh-copyを行うまで、それが許可エラーである場所に戻ったりログしたりせずに、sshログイン試行をサイレントに失敗させるようですid。

4
Ambulare