ssh-copy-idにもかかわらずsshがパスワードを要求する

リモートシェルでの使用とsshfsマウントのために、リモートサーバーで公開鍵認証をしばらく使用しています。sshfsディレクトリのumountを強制した後、sshがパスワードの入力を求め始めたことに気付きました。ローカルマシンに関する記述からリモートの.ssh / authorized_keysをパージし、リモートマシンへの参照からローカルマシンを削除しました。次にssh-copy-idを繰り返し、パスワードの入力を求められ、正常に戻りました。しかし、驚いたことに、リモートサーバーにsshするとき、パスワードの入力を求められます。私は問題が何であるかについて少し混乱しています、何か提案はありますか？

sshdは、$ HOME、$ HOME / .ssh（両方のディレクトリ）、および$ HOME / .ssh / authorized_keysのパーミッションについて奇妙になります。

私のLinuxボックスの1つは、$ HOMEディレクトリに対するdrwxrwxrwxパーミッションで終わりました。Arch Linuxボックスは、$ HOMEディレクトリにあるグループの 'w'パーミッションを削除するまで、公開鍵を使用して絶対にログインしませんでした。

$ HOMEと$ HOME / .ssh /にグループやその他のアクセス許可を制限してみてください。それがsshdにそれをさせないかどうか見てください。

次の権限が必要です。

• .sshフォルダ：700 (drwx------)
• 公開鍵： 644 (-rw-r--r--)
• 秘密鍵： 600 (-rw-------)

私も最近この問題を経験しました。

$HOMEディレクトリの権限を変更することで修正されました。ただし、単に実行chmod g-w ~/しても問題は修正されませんでした。さらにchmod g-w ~/、次のコマンドを実行othersして、$HOMEディレクトリのアクセス許可を変更する必要もありました。chmod o-wx ~/

一緒に：

chmod g-w ~/
chmod o-wx ~/

o-x必要かどうかはわかりませんが、予防策として単に実行しただけです。

〜/ .sshフォルダーのアクセス許可を変更すると、スーパーユーザーSEのこの投稿によると、私の問題は解決しました。

並列ログインでも問題が発生しますか。つまり、sshセッションを開いている間にsshfsをマウントしようとした場合ですか。そうでない場合は、ホームディレクトリが暗号化されていると思いますか？この場合$HOME/.ssh/authorized_keys、最初のログイン後に（パスワードを使用して）リモートマシンでのみ使用可能になります。

チェックアウトhttps://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting説明し、必要な対応策については。

これをコメントとして投稿しますが、おそらく長すぎるでしょう。フォルダー内ssh-copy-idの/.ssh場所から公開キーを送信しようとするものを追加したかっただけ$HOMEです。

ssh公開鍵を使用してルートとして（セキュリティ関連のコメントを保存）ssh-copy-idしようとしている場合、$HOME変数が/root（通常のユーザーのホームディレクトリに設定されているなど）以外に設定されていると、間違った公開鍵でログインしようとしている可能性があります）したがって、ルートの公開キーがリモートシステムにインストールされていないため、ルートユーザーにプロンプ​​トが表示されます。

次のワンライナーを使用して、正確な公開キーを指定できます。

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

私はこのシナリオに何度か遭遇し（今朝を含む）、誰かが同じ状況に陥った場合に備えて、2セントを投入しようと考えました。

言及された他の貢献者のように、これはおそらく許可の問題です。

これを診断する最善の方法は、デバッグオプションをオンにしてリモートサーバーでSSHデーモンを再起動することです。通常は「-d」オプションです。OpenSSHデーモンのメッセージは非常に明確です。たとえば、次のようなメッセージが表示されます。

Authentication refused: bad ownership or modes for directory /some/path

再起動後に公開キーが存続しなかったのは、サーバーのホームディレクトリが暗号化されていたためです。（サーバーのインストール中にこれを行います）

別の考えられる問題は、サーバーがキーアルゴリズムをサポートしていないことです。私の場合、sshdログに次のメッセージが見つかりました（/var/log/auth.log私の場合）。

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

その場合は、sshd構成でそのアルゴリズムのサポートを有効にする必要があります（最新sshdバージョンへの更新が必要になる場合があります）、またはsshd接続しようとしているものがサポートするアルゴリズムにキーを切り替える必要があります。

この動作をグーグルで検索すると、最初の検索結果にこの質問が表示されるため、ソリューションも追加します。

私の場合、許可に関連するものは何もありませんでした。sshコマンドを実行するときに、何らかの理由で（実際に簡単な修正を見つけたので、その理由をわざわざ調べる必要はありませんでした）、プログラムは正しいIDファイルを探しませんでした。1つの解決策は、SSHプログラムが使用しようとしたSSHキーをリモートサーバーに手動で追加することでした。コマンドに-vを追加すると、コマンドを実行するときにSSHプログラムが何を行うかを観察できます。

ssh -v username@your-host-ip-or-domain 

次に、SSHプログラムがMacでIDファイル/秘密鍵を見つけようとする公開鍵をローカルマシンで取得します。

cat ~/.ssh/id_rsa.pub

...そして、次のリモートのauthorized_keysファイルに追加します。

~/.ssh/authorized_keys

別の、私の場合のより良い解決策は、ローカルssh構成ファイルにカスタムホストを追加することでした。私のMacでは次のとおりです。

/Users/my-user-name/.ssh/config

ここでは、たとえば次のようなものを追加できます。

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

次に、実行する必要があります：

ssh mynewserver

...そしてVoilà