〜/ .ssh / authorized_keysに公開鍵を追加しても自動的にログインされません

公開SSHキーをauthorized_keysファイルに追加しました。 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>

次に、上記のログの後にパスフェーズを要求します。パスワードなしでログインしないのはなぜですか？

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

ssh authorized_keysの設定は単純なようですが、理解しようとしているいくつかのトラップを隠しています

-サーバー-

中には、/ etc / ssh / sshd_config設定 passwordAuthentication yesできるように受け入れるサーバーの一時的なパスワード認証

-クライアント-

cygwinをLinuxエミュレーションと見なし、 opensshをインストールして実行します。

1. 秘密鍵と公開鍵を生成する（クライアント側） # ssh-keygen

ここでENTERを押すだけで、DEFAULT 2ファイル「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.ロギングssh user_name@host_nameはデフォルトのid_rsaに対してのみ機能するため、ここでは、2番目のトラップを行う必要がありますssh -i path/to/key_name user@host

（何が起こっているかを確認するには、ssh -v ...オプションを使用してください）

場合は、サーバーがまだパスワードを要求、あなたはなめらかを与えました。パスフレーズを入力するには：キーを作成したとき（これは正常です）

sshがリッスンしていない場合、デフォルトのポート22を使用する必要があります ssh -p port_nr

-サーバー-----

4. / 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. MySQL（バインド= 127.0.0.1）サーバーにアクセスするための追加の SSH TUNNEL

また、ホームディレクトリが他のユーザーから書き込み可能でないことを確認してください

chmod g-w,o-w /home/USERNAME

ここから答えが盗まれる

混乱した端末からid_rsa.pubテキストをコピーするため、desperateはさらに、authorized_keysファイルに余分な改行がないことを確認できます。

ユーザーはあなたのユーザー名です

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

すべての権限に問題がないように見えても、SELinuxがこのエラーをトリガーする可能性があることに注意してください。それを無効にすることは私にとってはトリックでした（無効にすることについての通常の免責事項を挿入してください）。

公開鍵を.ssh / authorized_keysにリストすることは必要ですが、sshd（サーバー）がそれを受け入れるには不十分です。秘密鍵がパスフレーズで保護されている場合は、ssh（クライアント）に毎回パスフレーズを与える必要があります。または、ssh-agentまたは同等のGNOMEを使用できます。

あなたの更新のトレースは、パスフレーズで保護された秘密鍵と一致しています。ssh-agentを参照するか、を使用してくださいssh-keygen -p。

書き込みコマンド：

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

ついに私にとってのトリックは、所有者/グループがrootではなくユーザーであることを確認することでした：

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

私のために働いた「ssh-add」を試してください。

覚えておくべきもう一つのヒント。v7.0以降、OpenSSH は継承の弱点により、デフォルトでDSS / DSA sshキーを無効にします。したがって、OpenSSH v7.0以降を使用している場合は、キーがでないことを確認してくださいssh-dss。

DSA鍵で立ち往生している場合、次のような行でsshd_configと~/.ssh/configファイルを更新することにより、ローカルでサポートを再度有効にできます。PubkeyAcceptedKeyTypes=+ssh-dss

私の場合、authorized_keysファイルをに置く必要がありました.openssh。

この場所は/etc/ssh/sshd_configオプションで指定されますAuthorizedKeysFile %h/.ssh/authorized_keys。

ターゲット・ユーザーにパスワードが設定されていることを確認してください。実行passwd usernameして設定します。これは、パスワードSSHログインが無効になっている場合でも必要でした。

これは私の問題を解決します

ssh-agent bash

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

私が発行したsudo chmod 700 ~/.sshとchmod 600 ~/.ssh/authorized_keysし、chmod go-w $HOME $HOME/.ssh上から、それは私がsambaの共有が機能して取得しようとしている間に許可を台無しにしたことCentOS7ボックスに私の問題を修正しました。ありがとう

許可の問題のようです。通常、これは、一部のファイル/ディレクトリの権限が正しく設定されていない場合に発生します。ほとんどの場合、それらは~/.sshおよび~/.ssh/*です。私の場合はそう/home/xxxです。

変更/etc/ssh/sshd_config（検索LogLevel、それをに設定）してsshdのログレベルを変更しDEBUG、出力をチェックして、/var/log/auth.log何が起こったかを正確に確認できます。

私の問題は、/ etc / ssh / authorized_keysにデータを入力するための自動化がまだ実行されていなかったときに、変更されたAuthorizedKeysFileでした。

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

サーバーの/var/log/auth.logを確認してください。クライアント側で-vvを使用して追加の詳細度を設定しても、サーバーが攻撃者に情報を提供しすぎる可能性は低いため、役に立ちません。

公開鍵全体をにコピーしたことを確認してくださいauthorized_keys。ssh rsa接頭辞は、仕事への鍵が必要です。

ファイルのプロパティを確認する必要があります。必要なプロパティの用途を割り当てるには：

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

見て/var/log/auth.logのためのサーバー上のsshd認証エラー。

他のすべてが失敗した場合は、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

そのメモで、sshd configに-があることを確認してください。

PermitRootLogin without-password

上記のように設定してから、sshd（/etc/init.d/sshd restart）を再起動します

ログアウトして、もう一度ログインしてみてください！

私が信じているデフォルト--

PermitRootLogin no

私の場合は、ユーザーのグループが構成ファイル/ etc / ssh / sshd_configのAllowGroupsに設定されていないためです。追加後、すべて正常に動作します。

ホームディレクトリが標準以外の場所にあり、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

• 続いてa restorecon -r /data/とsshd再起動

私にはこの問題があり、他の答えはどれもそれを解決しませんでしたが、もちろん他の答えは正しいです。

私の場合、/rootディレクトリ自体（例：ではない/root/.ssh）に誤ったアクセス権があることがわかりました。必要だった：

chown root.root /root
chmod 700 /root

もちろん、これらのアクセス許可は、そのようなもの（多分chmod 770）である必要があります。しかし、それは、具体的防止sshdにもかかわらず、作業から/root/.sshと/root/.ssh/authorized_keysの両方が適切なアクセス権と所有者を持っていました。

ログインユーザーのグループを別のユーザーに追加すると、この問題が発生しました。userAと呼ばれるssh-loginユーザーと、非ssh-loginユーザーuserBがいるとします。userAには、userAというグループもあります。userBを変更して、グループuserAも作成しました。説明された動作につながるため、userAはプロンプトなしでログインできませんでした。userBからグループuserAを削除した後、プロンプトなしのログインが再び機能しました。