SSH公開キー認証が機能しない[クローズ]

私のサーバーはCentOS 5.3を実行しています。Leopardを実行しているMacを使用しています。私はこれに責任があるのか​​わかりません：

パスワード認証を介してサーバーに正常にログオンできます。PKAをセットアップするためのすべての手順を実行しました（http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.htmlで説明されています）が、私はSSHを使用していますが、公開鍵の検証を試みることさえ拒否しています。コマンドを使用する

ssh -vvv user@host

（-vvvは詳細レベルを最大レベルに上げます）次の関連する出力を取得します。

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

パスワードの入力が求められます。問題を強制しようとすると

ssh -vvv -o PreferredAuthentications=publickey user@host

私は得る

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

だから、サーバーが公開鍵認証方式を受け入れていると言っていて、SSHクライアントがそれを主張していても、反論します。（上記の「公開キーの提供：」行が目立たないことに注意してください。）提案はありますか？

Centosマシンに次のものがあることを確認します。

RSAAuthentication yes
PubkeyAuthentication yes

sshd_configで

また、centosマシンの〜/ .ssh /ディレクトリに対する適切な権限があることを確認してください。

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

トリックを行う必要があります。

同様の問題がありました-リモートPCは公開鍵認証を使用してCentOs 6サーバーにログインできませんでした。私の場合の問題はSELinux関連でした-ログインしようとしているユーザーのホームディレクトリにセキュリティコンテキストが表示されていました。このrestoreconようにツールを使用してこれを解決しました：

restorecon -Rv /home

1- / etc / ssh / sshd_configを確認し、持っていることを確認します

RSAAuthenticationはい
PubkeyAuthenticationはい

2-リモートマシンからセキュアログを確認し、詳細sshdデーモンエラーログを検索します。例えば私のUbuntuで

＃grep 'sshd' / var / log / secure | grep '認証は拒否されました' | 尾-5
8月4日06:20:22 xxx sshd [16860]：認証が拒否されました：所有権またはディレクトリ/ home / xxxのモードが正しくありません
8月4日06:20:22 xxx sshd [16860]：認証が拒否されました：所有権またはディレクトリ/ home / xxxのモードが正しくありません
8月4日06:21:21 xxx sshd [17028]：認証が拒否されました：ディレクトリ/ home / xxxの所有権またはモードが正しくありません
8月4日06:21:21 xxx sshd [17028]：認証が拒否されました：ディレクトリ/ home / xxxの所有権またはモードが正しくありません
8月4日06:27:39 xxx sshd [20362]：認証が拒否されました：ディレクトリ/ home / xxxの所有権またはモードが正しくありません

次に、ディレクトリ/ home / xxxの所有権とモードを確認します。これを実行する必要があるかもしれません

chmod 755 / home / xxx

ローカルマシンとリモートマシンの両方について、アクセス許可が正しく、ファイル構造（特にスペル）が正しいことを再確認してください。参照するURLにはすべて記載されていますが、一致するものを確認する価値があります。通常、パーミッションは関連するエラーをスローします。

CentOS 5.3ボックスのsshd_configがPubkeyAuthenticationまたはRSAAuthenticationを許可するように設定されていることを確認しましたか？

CentOSシステムのSSHサーバーログを確認します-詳細が提供される場合があります。CentOSがdebianが行うブラックリストsshキーのチェックを行うかどうかはわかりませんが、-vvv出力に関する限り比較的静かなssh公開キーの拒否を見てきましたが、ログは何が起こっているかを明確に説明していました

とった！クライアント側の問題であることが判明しました。（サーバー側の問題があれば、より有用なデバッグ出力が得られると思います。）私の知らない理由で、私のMacでは、ファイル/ etc / ssh_configに次の行がありました。

PubkeyAuthentication = no

その一行をコメントアウトしましたが、今ではすべてが正常に機能します。

ファイル/ディレクトリのモードに加えて、所有権が正しいことを確認してください！ユーザーは、独自のホームディレクトリ、.ssh /、およびその中のファイルを所有する必要があります。

私はchown -R $user:$user /home/$usersshの失敗を乗り越えるために走らなければなりませんでした。

また、キーを自動で供給できるかどうかを確認し、そうでない場合または単にテストするために-i path / to / keyを使用します

構成の問題のように思えます。ダニエルが提案したように、チェックすることが2つあります。

1. のSSHキー$HOME/.ssh/authorized_keysは読み取り可能です。そして
2. SSHdは、公開鍵ログインを許可するように構成されています。

ログインしようとしているユーザー名を確認してください。デフォルトでは、ローカルマシンのユーザー名です。

クライアントの出力は、ssh -vプロトコルの特定のステップに問題があることを示しますが、サーバー上の何かが原因である場合、クライアントには原因が通知されません。サーバーのログファイルを確認して、何が問題なのかを確認してください。そうするrootための許可を得るには、おそらくあなたがいる必要があります。たとえば、sshdsyslogにログを記録するように構成されている場合、メッセージはにあり/var/log/secureます。これらのように：

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

この場合の理由は、（愚かな）デフォルトdefaultでした0002。つまり、グループの書き込みアクセス。（グループ名=ユーザー名ですが、それでも。）SSHデーモンは、ユーザー以外のユーザーによって改ざんされる可能性のあるファイルを信頼しません（もちろん、そしてrootもちろん）。を使用して問題を解決できchmodます。

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

fedoraコア16からセント5.5にアクセスするのと同じ問題に巻き込まれました

ログと詳細はまったく同じに見えた

問題は公開鍵であり、いくつかの偽データを取得し、それを再生成してsshd_serverに投稿します。sshd_clientは鍵情報を送信していますが、サーバーによって認識されません（authorized_keysのいずれかの鍵と一致します）

これにかまれた別の。長い検索の後、秘密鍵の代わりに公開鍵を（-iオプションを使用して）明示的に提供していたことがわかりました。ど！