web-dev-qa-db-ja.com

公開鍵でパスワードなしでサインインできないのはなぜですか？

私のホームネットワークには、Ubuntuを実行しているサーバーとWindows 7を実行している別のデスクトップがあります。Windowsマシンでcygwinを使用してサーバーにSSHで接続しています。これら2つのマシン間でキーを設定しようとしました。 Windowsマシンでは、ssh-keygen -t rsaを使用してキーを作成しました。次に、結果のid_rsa.pubをサーバーに「scp」して、~/.ssh/authorized_keysファイルに配置しました。私が知る限り、これを機能させるために必要なのはそれだけです。しかし、ご想像のとおり、そうではありません。

[email protected]を使用してsshしようとしています。私の推測（私は素晴らしい情報を得ることができなかった）は、cygwinを使用するために少し異なるものを設定する必要があるか、またはホスト名ではなくIPアドレスを使用することに何らかの関係があるかもしれないということです。 。指示やアイデアはありますか？

sshcygwinkeys
5
Hector Scout

これは、おそらく〜/ .sshディレクトリまたは〜/ .ssh/authorized_keysファイルのいずれかの権限の問題です。

〜/ .sshディレクトリを700にchmodし、authorized_keysファイルを少なくとも644にchmodする必要があります。/var/log/secureログファイルを確認すると、失敗の理由に関するヒントが得られます。

9
vmfarms

Sshで認証の問題が発生している場合、最初に調査することは、クライアントがデバッグを行って何を言っているかです。

% ssh -v Host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
...

成功した公開鍵接続です。

% ssh -v Host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/david/.ssh/identity
debug1: Trying private key: /home/david/.ssh/id_rsa
debug1: Next authentication method: password
david@ace's password: 
...

これは、公開鍵認証が拒否された理由についての多くの情報を提供しません。最良の情報はサーバーで入手できます。 SshdはAUTHのsyslog機能にログを記録するので、ログに記録されている場所の情報を見つけることができます（Debianの場合は/var/log/auth/）。

Aug 19 08:18:36 ace sshd[10100]: Authentication refused: bad ownership or modes 
       for directory /home/david/.ssh

これは、.sshの権限が間違っていることを示しており、簡単に修正できます。

Aug 19 08:26:41 ace sshd[12156]: error: key_read: uudecode
       ZAAAAB3NzaC1kc3MAAACBAIUuAmpj9FuE71EfqJDVAfI+pUZ++xSWbUvEh7U36WW/...

これは、その特定のキーの読み取りに失敗したことを示しているため、修正する必要があります。

ログから有用な情報が得られない場合は、ログを上げることができます。編集/etc/ssh/sshd_configとLogLevel行を次のように変更します。

 LogLevel DEBUG

次に実行します

 /etc/init.d/ssh reload

接続しようとすると、次のようなログが表示されます。

Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /usr/share/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file 
      /etc/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: temporarily_use_uid: 1002/513 (e=0/0)
Aug 19 08:32:12 ace sshd[13537]: debug1: trying public key file 
      /home/david/.ssh/authorized_keys
Aug 19 08:32:12 ace sshd[13537]: debug1: fd 4 clearing O_NONBLOCK
Aug 19 08:32:12 ace sshd[13537]: debug1: matching key found: file 
      /home/david/.ssh/authorized_keys, line 1
Aug 19 08:32:12 ace sshd[13537]: Found matching DSA key: 
      1c:46:89:52:c1:79:c8:8f:43:3c:4e:77:ad:a1:5d:1b

これはログインに成功しました。

さらに情報が必要な場合は、DEBUG2およびDEBUG3を使用して詳細情報を取得できます。問題を修正したら、ログレベルを（おそらくINFOに）戻すことを忘れないでください。

4
David Pashley

権限は〜/ .ssh/authorized_keysファイルにとって重要です。ファイル自体には、他のユーザーがファイルに書き込むことを許可するアクセス許可があってはなりませんchmod go-rwx ~/.ssh/authorized_keysまた、.sshディレクトリは書き込みを許可してはなりませんchmod go-rwx ~/.sshホームディレクトリも書き込みを許可しないchmod go-w ~/

この理由は、他の誰かが（グループ権限または他の権限を介して）ディレクトリに書き込むことができた場合、誰かがあなたの知らないうちに許可されたキーをそこに詰め込むことは非常に簡単です。ホームディレクトリが書き込みを許可している場合、誰かが.sshディレクトリとその内容を再作成する可能性があります。

1
Alex

一部のディストリビューションでは、ssh-copy-idというツール（実際にはシェルスクリプト）が提供されています。これを使用すると、ユーザーのキーの.pub部分をリモートアカウントのauthorized_keysファイルにコピーすることで多くの頭痛の種を回避できます。

使用法

$ ssh-copy-id user@remotehost

異なるキーをコピーするように指示することもできます（デフォルトではid_rsa*キーに設定されています）。

$ ssh-copy-id -i ~/.ssh/somekey.pub user@remotehost

このスクリプトは、リモートホスト上にユーザーの$HOME/.sshディレクトリも作成しますand許可を正しく設定します。

$ ssh-copy-id --help
Usage: /usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine

それに沿った基本的なmanページがあります。私のRed Hatベースのディストリビューション（Fedora、CentOS、RHEL）では、標準のopenssh-clientパッケージの一部でした！

1
slm