SSHキー認証が失敗する

Question 1

これにより、SSH認証キーの権限に関するほとんどの問題が解決されます。サーバー側誰かが権限に追加の変更を加えていないと仮定します。

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（これは何ユーザー化チームの Web ダッシュボードの変更に基づいて、権限の問題を自動的に更新して修正するために、「shim」スクリプトが実行されます。

管理者が.ssh/ディレクトリまたは.ssh/authorized_keysファイルをrootとして作成した場合（これが最も一般的な問題の原因です）、そのユーザーが根。

Answer

これにより、SSH認証キーの権限に関するほとんどの問題が解決されます。サーバー側誰かが権限に追加の変更を加えていないと仮定します。

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

（これは何ユーザー化チームの Web ダッシュボードの変更に基づいて、権限の問題を自動的に更新して修正するために、「shim」スクリプトが実行されます。

管理者が.ssh/ディレクトリまたは.ssh/authorized_keysファイルをrootとして作成した場合（これが最も一般的な問題の原因です）、そのユーザーが根。

Question 2

2台のサーバーでまったく同じ問題が発生しました。Debian Stretchを実行しているLinuxとNAS（Synology DS715）です。

どちらの場合も、サーバーのホームディレクトリの権限が間違っていたことが判明しました。

サーバーのauth.logは非常に役に立ちました

Authentication refused: bad ownership or modes for directory /home/cyril

Linuxでは、書き込み/グループビットがオンになっていた（drwxrwxr--x）ため、少なくとも書き込みグループを削除する（chmod gw ~/）必要があり、その後動作しました。

Synologyでは、何らかの理由で、粘着性のあるビットがありました

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

私はそれを変更しなければならなかった

chmod -t ~/

そしてパスワードなしで接続できるようになりました

Answer

2台のサーバーでまったく同じ問題が発生しました。Debian Stretchを実行しているLinuxとNAS（Synology DS715）です。

どちらの場合も、サーバーのホームディレクトリの権限が間違っていたことが判明しました。

サーバーのauth.logは非常に役に立ちました

Authentication refused: bad ownership or modes for directory /home/cyril

Linuxでは、書き込み/グループビットがオンになっていた（drwxrwxr--x）ため、少なくとも書き込みグループを削除する（chmod gw ~/）必要があり、その後動作しました。

Synologyでは、何らかの理由で、粘着性のあるビットがありました

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

私はそれを変更しなければならなかった

chmod -t ~/

そしてパスワードなしで接続できるようになりました

Question 3

CentOS 7 を使用している場合、sshd を使用する他の Linux OS にも当てはまると確信しています。ルートアクセスを使用すると、認証が失敗する理由をさらに詳しく判断できます。これを行うには、次の手順を実行します。

デーモンのログ記録を有効にしますsshd。sudo vi /etc/ssh/sshd_config
ログ記録の下でコメントを解除します:

SyslogFacility AUTH
LogLevel INFO

LogLevelからINFOに変更DEBUG
保存して終了
SSHデーモンを再起動しますsudo systemctl restart sshd
メッセージファイルを見るtail -l /var/log/messages
別の端末を使用してsshで接続を試みる
接続を試みるssh
正確な原因については認証ログを確認してください

たとえば、私は上記と同じ問題のいくつかを経験していました。

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

これらの手順を使用して、問題がファイルの権限にあることを確認できましたauthorized_keys。ユーザーのファイルchmod 644を設定すると、問題は修正されました。authorized_keys

Answer

CentOS 7 を使用している場合、sshd を使用する他の Linux OS にも当てはまると確信しています。ルートアクセスを使用すると、認証が失敗する理由をさらに詳しく判断できます。これを行うには、次の手順を実行します。

デーモンのログ記録を有効にしますsshd。sudo vi /etc/ssh/sshd_config
ログ記録の下でコメントを解除します:

SyslogFacility AUTH
LogLevel INFO

LogLevelからINFOに変更DEBUG
保存して終了
SSHデーモンを再起動しますsudo systemctl restart sshd
メッセージファイルを見るtail -l /var/log/messages
別の端末を使用してsshで接続を試みる
接続を試みるssh
正確な原因については認証ログを確認してください

たとえば、私は上記と同じ問題のいくつかを経験していました。

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

これらの手順を使用して、問題がファイルの権限にあることを確認できましたauthorized_keys。ユーザーのファイルchmod 644を設定すると、問題は修正されました。authorized_keys

Question 4

私が持っていました同様の問題、ここで、ssh 接続はキーを試行します~/.ssh/id_rsaが、予期せず停止します。

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

私の場合、ディレクトリ内に古い公開鍵ファイルが残っていたのが原因でした.ssh。

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

id_rsa.pubディレクトリから移動/削除すると.ssh問題は解決しました。

私が理解しているところによると、クライアント側に公開鍵が存在する場合、SSH はまずそれに対して秘密鍵を検証します。検証に失敗すると、秘密鍵を使用してリモート接続しようとはしません。

openssh メーリングリストに電子メールを送信しました:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html。

Answer