公開鍵を〜/ .ssh/authorized_keysに追加しても自動的にログインしない
Authorized_keysファイルに公開sshキーを追加しました。 ssh localhostはパスワードを要求せずにログインしてください。
私はそれをしてssh localhostとタイプしてみましたが、それでもパスワードをタイプするよう私に頼みます。それを機能させるために私が経験しなければならない他の設定はありますか？
権限を変更するための指示に従いました。
ssh -v localhostを実行した場合の結果は以下のとおりです。
debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA Host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
それからそれは上記の丸太の後でpassphaseを頼みます。パスワードなしでログインできないのはなぜですか？
authorized_keysファイルと、それが配置されているフォルダー/親フォルダーの権限を確認する必要があります。
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
詳細については このページ を参照してください。
グループや他のユーザーの書き込み権限を削除するには、ホームディレクトリの権限を変更または確認する必要があります。
chmod go-w ~
SELinuxはauthorized_keysが機能しない原因にもなります。特にCentOS 6および7のroot用です。無効にする必要はありません。権限が正しいことを確認したら、次のように修正します。
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh
setting ssh authorized_keys は単純そうですが、把握しようとしているトラップを隠します。
- サーバー -
/etc/ssh/sshd_config に設定して、サーバーが一時的にパスワード認証を受け付けるようにするpasswordAuthentication yes
- クライアント -
cygwin をLinuxエミュレーションとして検討し、opensshをインストールして実行します。
1. 秘密鍵と公開鍵を生成する（クライアント側）# ssh-keygen
ここでENTERキーを押すだけでDEFAULT2個のファイル " id_rsa "と " id_rsa.pub "/ 〜/ .ssh/ しかし、あなたが name_for_the_key を与えた場合、生成されたファイルはあなたの pwd に保存されます。
2. your_key.pub をターゲットマシンに配置ssh-copy-id user_name@Host_name
デフォルトキーを作成していないのであれば、これが最初のステップです。
ssh-copy-id -i path/to/key_name.pub user_name@Host_name
3. logging ssh user_name@Host_nameはデフォルトのid_rsaに対してのみ機能するので、ここではssh -i path/to/key_name user@Hostを実行するために必要な2つ目のトラップです。
（ ssh -v ... オプションを使用して、何が起こっているのかを確認してください）
serverがまだパスワード を要求する場合は、smthを指定しました。 to パスフレーズを入力してください： あなたが鍵を作成したとき（だから普通です）
sshがデフォルトのポート22をリッスンしていない場合はssh -p port_nrを使用する必要があります。
- サーバー-----
4. modify /etc/ssh/sshd_config にする
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
（場合は無意味）
これはsshにauthorized_keysを受け入れ、.ssh/authorized_keysファイルに書かれたkey_name文字列をユーザのホームディレクトリで探すように指示します。
5 ターゲットマシンに権限を設定する
chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
パス認証もオフにする
passwordAuthentication no
すべてのssh root/admin /....@ your_domainの試行へのゲートを閉じる
6 すべての非ルートホームディレクトリの所有権とグループの所有権が適切であることを確認します。
chown -R ~ usernamehere
chgrp -R ~/.ssh/ user
=================================================
7. 優れたものを検討する http://www.fail2ban.org
8. extra ssh TUNNEL MySQLにアクセスする（bind = 127.0.0.1）
必然的に、混乱した端末からid_rsa.pubテキストをコピーすることで、authorized_keysファイルに余分な改行が含まれないようにすることもできます。
.ssh/authorized_keysに公開鍵をリストすることは必要ですが、sshd（サーバー）がそれを受け入れるには不十分です。秘密鍵がパスフレーズで保護されている場合は、毎回ssh（クライアント）にパスフレーズを渡す必要があります。あるいは、ssh-agent、またはそれと同等のgnomeを使用することもできます。
あなたのUPDATEによるトレースは、パスフレーズで保護された秘密鍵と一致しています。 ssh-agentまたはssh-keygen -pを参照してください。
たとえすべてのパーミッションが問題ないように見えても、SELinuxがこのエラーを引き起こす可能性があることに注意してください。それを無効にすることは私にとってトリックでした（それを無効にすることについての通常の免責事項を挿入してください）。
ユーザーはあなたのユーザー名です
mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts
私のためにトリックをしたことは、 owner/group がrootではなくuserであることを確認することでした。
chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user
書き込みコマンド：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
これをした後、あなたのdirがそのようであることを確かめなさい：
drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab 436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab 413 Mar 13 07:35 id_rsa.pub
私の場合は、authorized_keysファイルを.opensshに入れる必要がありました。
この場所は、オプション/etc/ssh/sshd_configの下のAuthorizedKeysFile %h/.ssh/authorized_keysに指定されています。
覚えておくべきもう一つのヒント。 v7.0以降のOpenSSH は継承の弱さのためにデフォルトで DSS/DSA sshキーを無効にしています。 OpenSSH v7.0以降をお持ちの場合は、キーがssh-dssではないことを確認してください。
DSAキーを使い続けている場合は、
sshd_configおよび~/.ssh/configファイルを次のような行で更新することで、ローカルでサポートを再度有効にすることができます。PubkeyAcceptedKeyTypes=+ssh-dss
"ssh-add"を試してみてください。
あなたが注意しなければならないもう一つの問題。生成したファイルがデフォルトではない場合id_rsaおよびid_rsa.pub
あなたは.ssh/configファイルを作成し、あなたが接続で使用しようとしているidファイルを手動で定義する必要があります。
例はここにあります：
Host remote_Host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub
ターゲットユーザーにパスワードが設定されていることを確認してください。設定するにはpasswd usernameを実行してください。パスワードSSHログインが無効になっていても、これは私にとって必要でした。
server の /var/log/auth.log を見てください。クライアント側で -vv を使用して追加の冗長性を設定しても意味がありません。攻撃者にサーバーが提供する情報が多すぎる可能性が低いためです。
公開鍵全体をauthorized_keysにコピーしたことを確認してください。キーが機能するには、ssh rsaプレフィックスが必要です。
ファイルのプロパティを確認する必要があります。必要なプロパティを割り当てるには
$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub
これは私の問題を解決します
ssh-agent bash
ssh-add
許可の問題のようです。通常、ファイル/ディレクトリのパーミッションが正しく設定されていないと起こります。ほとんどの場合、それらは~/.sshと~/.ssh/*です。私の場合、それらは/home/xxxです。
Sshdのログレベルを変更するには、/etc/ssh/sshd_configを変更し（LogLevelを検索し、それをDEBUGに設定します）、/var/log/auth.logの出力を確認して正確に何が起こったかを確認します。
私は上からSudo chmod 700 ~/.sshとchmod 600 ~/.ssh/authorized_keysとchmod go-w $HOME $HOME/.sshを発行しました、そしてそれは私がsamba共有を動かそうとしている間に許可をめちゃめちゃにしたCentOS7箱に関する私の問題を修正しました。ありがとう
ホームディレクトリは標準外の場所とsshdログにあります。
Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied
たとえすべてのパーミッションが問題ないとしても（他の答えを見てください）。
私はここで解決策を見つけました： http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191
私の特定のケースでは：
/etc/selinux/targeted/contexts/files/file_contexts.homedirsに新しい行を追加しました：これは通常のホームディレクトリの元の行です。
/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0これが私の新しい行です。
/data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
続いて
restorecon -r /data/とsshdの再起動
そのメモでは、あなたがsshdの設定を持っていることを確認してください - 。
PermitRootLogin without-password
上記のように設定してから、sshdを再起動します（/etc/init.d/sshd restart）。
ログアウトしてから再度ログインしてください。
デフォルトだと思う - 。
PermitRootLogin no
sshd認証エラーについてはサーバー上の/var/log/auth.logを見てください。
他のすべてが失敗した場合は、sshdサーバーをデバッグモードで実行します。
Sudo /usr/sbin/sshd -ddd -p 2200
その後、クライアントから接続します。
ssh user@Host -p 2200
私の場合は、最後にエラーセクションが見つかりました。
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
debug3: send packet: type 51 [preauth]
debug3: receive packet: type 50 [preauth]
この情報で、私のsshd_configはログインをsshグループのメンバーに制限していたことに気づきました。次のコマンドでこの権限エラーを修正しました。
Sudo usermod -a -G ssh NEW_USER
私はこの問題を抱えていて他の答えのどれもそれを解決しませんでした、もちろん他の答えは は正しいです 。
私の場合、/rootディレクトリ自体（例えば/root/.sshではない）が間違った許可を持っていたことがわかった。必要だった：
chown root.root /root
chmod 700 /root
もちろん、これらの許可はそのようなもの（おそらくchmod 770）であるべきです。しかし、たとえ/root/.sshと/root/.ssh/authorized_keysが両方とも正しいパーミッションと所有者を持っていたとしても、それは特にsshdが動作するのを妨げました。
ログインユーザーのグループを別のユーザーに追加したときにこの問題が発生しました。 userAというsshログインユーザーと、ssh以外のログインユーザーuserBがあるとします。 userAはグループuserAも持っています。グループuserAも持つようにuserBを変更しました。 userAがプロンプトなしでログインすることができなかったように、説明された振る舞いへとつながりました。 userBからグループuserAを削除した後、プロンプトなしのログインが再び機能しました。
私の問題は、/ etc/ssh/authorized_keysを生成するための自動化がまだ実行されていなかったときの、AuthorizedKeysFileの修正です。
$Sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
私の場合は、ユーザーのグループが設定ファイル/ etc/ssh/sshd_configのAllowGroupsに設定されていないためです。それを追加した後、すべてうまくいきます。