authorized_keysでsshを介した自動ログインが機能しないのはなぜですか？

12

プライベート/パブリックのdsa-keypairを作成しました。公開鍵をサーバーに入れました

~/.ssh/authorized_keys

すべてが他のサーバーと同じように設定されていますが、サーバーは私の努力を無視しているようです。

security ssh login

— マグナール
ソース

チェック/etc/ssh/ssh_configして/etc/ssh/sshd_config欲しい何が無効になっていないことを確認します。

— クリストファージョンソン

sshd_configも確認する必要があります。

— Vagnerr 2009

ありがとう。私は答えを更新しました（元々はssh_configのみに言及していました）。

— クリストファージョンソン

上記の説明はすべて、opensshスタイルのsshを使用している場合に最適です。システムがssh2を使用している場合、キーを管理するまったく変わった方法があります。この記事では、方法と内容について説明します。burnz.wordpress.com/2007/12/14/…–

— クリス

1

通常/var/log/auth.log、Debianシステムまたは/var/log/secureRedHat システムをチェックすると、何が

— 誤解されて

15

あなたの問題はすでに他の回答で解決されている可能性がありますが、サインオフする前に十分なマシンからsshd_configの変更を検証しないようにロックアウトしているため、sshd構成の変更の将来のデバッグに役立つ可能性がある以下のプロセスを考え出しました：

テストで動作が期待どおりであることを確認した後は、アクティブなSSH接続を切断しないでください。

a。sshdが実行しているはずの動作を確認する

b。「-t」を使用して構成が有効であることを確認します

c。ライブモニターできるサーバーの詳細な「テスト」バージョンを開始する

d。ライブモニターできる詳細な「テスト」クライアント接続を開始する

a。sshdが実行しているはずの動作を確認する

sshd構成ファイルを次のようなコメントなしで確認します（sshd_configが正しいファイルであり、/ etc / sshにあると想定）

$ grep -v "^＃" / etc / ssh / sshd_config | grep -v "^ $"

これは単に問題をクリアするだけなので、変更していると思われるものを検証します（必ずしも正しいかどうかとは限りません）。

b。「-t」を使用して構成が有効であることを確認します

私が使用しているsshdのmanページから、

-tテストモード。構成ファイルの有効性とキーの健全性のみを確認してください。これは、構成オプションが変更される可能性があるため、sshdを確実に更新するのに役立ちます。

その他の変更は、より微妙な状況になる可能性があります。たとえば、公開鍵認証が正しく機能していることが確実になるまで、パスワード認証を無効にしないでください。

c。ライブモニターできるサーバーの詳細な「テスト」バージョンを開始する

$ sudo / usr / sbin / sshd -ddd -p 9999

これにより、既存の作業セッションがアクティブなままになりますが、sshdの別のインスタンスを使用して、新しい構成の変更を確認できます。SSHDがフォアグラウンドでユーザー定義のポート（この例では9999）まで実行され、/ var / log / authlog（または場合によっては/var/log/auth.log）で追跡できる多くのノイズの多いデバッグ情報をプッシュしていますあなたのOS上で。）

d。ライブモニターできる詳細な「テスト」クライアント接続を開始する

詳細モードでsshクライアント接続を実行して、エラーのデバッグに役立つ可能性のある詳細情報を画面に表示します。

$ ssh -vvv -p 9999サーバー名

これで、問題を特定するために、サーバーのログファイルまたはクライアントの接続画面に十分な情報が含まれているはずです。

解決策は一般にファイルの権限に帰着します（Magnarとsetatakahashiが示したように）

最高の幸運

— サムト
ソース

クライアントエンドのssh_configファイルも期待どおりに動作していることを確認する必要があると思います。以下のようなものを使用してコメントをgrepします。> grep -v "^＃" / etc / ssh / ssh_config | grep -v "^ $"

— samt

さて、クライアントのssh設定はいつでも修正できます。間違って設定した場合、ロックされるサーバーです。

— ソビエロ2012

33

サーバーは、所有者のプロパティが間違っている場合、authorized_keysファイルを無視します。これをこれに変更すると修正されます：

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— マグナール
ソース

6

ssh -vvv -l username server.domainは、送信した鍵が有効かどうかを通知します

— Dave Cheney

sshdがホームディレクトリの不正なアクセス権について不平を言うのを見たことがあります。そのため、setatakahashiのように、 "chmod o-rwx〜"（または少なくとも "chmod ow〜"）をリストに追加します。これは通常、ログファイルを監視すると明らかになります。そこで見たエラーメッセージは常に正しい方向を指しています。

— オラフ

この答えが最も可能性が高いようですが、Dave Cheneyのコメントが、実際に何が起こっているかを確認する唯一の方法です。サーバーログも確認してください。

— dwc 2009年

これが私の問題でした。私はこれに何時間も頭をぶつけました。本当にありがとう！

— Sam Soffes、2010年

1

これはトリックをしましたが、私の以前の権限はなかった0775と0644、それぞれ。権限を減らすことが役立つのはなぜですか？これはどこかに設定されているセキュリティ対策ですか？

— Dean

11

$ chmod 700〜

$ chmod 700〜/ .ssh

$ chmod 600〜/ .ssh / authorized_keys

/ etc / ssh / sshd_configでこれらの属性を確認します

$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config

$ sudo grepプロトコル/ etc / ssh / sshd_config

— せたたかはし
ソース

2

〜の優れた点は、自分以外の誰もホームディレクトリに書き込めないようにすることです。そうしないと、〜/ .sshディレクトリの名前が変更される可能性があります

— Dave Cheney

最後のchmodは次のようになります：$ chmod 600 ~/.ssh/authorized_keysnot$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe

3

属性値には何をすべきこと？

— マイケル、

0

別の重要な落とし穴。

ホームディレクトリが暗号化されている場合、sshdは〜/ .ssh / authorized_keysにアクセスできません。

この回答を見る

— アプリオリ
ソース