it-swarm-ja.tech

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

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

29
Aliud Alius

sshdは、$ HOME、$ HOME/.ssh(両方のディレクトリ)、および$ HOME/.ssh/authorized_keysに対する権限について奇妙なものになります。

私のLinuxボックスの1つが、$ HOMEディレクトリに対するdrwxrwxrwx権限で終了しました。 Arch Linuxボックスは、$ HOMEディレクトリの他のグループの「w」権限を削除するまで、公開鍵を使用してログインすることは絶対にありません。

$ HOMEと$ HOME/.ssh /に、グループやその他の権限をさらに制限するようにしてください。それがsshdに任せていないかどうか確認してください。

32
Bruce Ediger

次の権限が必要です。

  • _.ssh_フォルダー:700 (drwx------)
  • 公開鍵:644 (-rw-r--r--)
  • 秘密鍵:600 (-rw-------)
8
Sagar Naik

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

$HOMEディレクトリの権限を変更することで修正されました。ただし、chmod g-w ~/を実行するだけでは問題は解決しませんでした。 chmod g-w ~/に加えて、$HOMEを実行してchmod o-wx ~/ディレクトリのothersの権限を変更する必要もありました。

一緒:

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

o-xが必要かどうかはわかりませんが、念のため実行しただけです。

5
izzy.artistic

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

1
Dogukan

この動作をグーグルで検索すると、この質問が最初の検索結果に表示されるので、解決策も追加します。

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

ssh -v [email protected] 

次に、Macのように、SSHプログラムが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

...そしてボイラ

0
Schurik

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

説明と必要な回避策については、 https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting を確認してください。

0
fheub

私の場合、リモートサーバーで次のファイルを使用します。

/etc/ssh/sshd_config

次のプロパティがnoに設定されていました:

PubkeyAuthentication no

ハッシュでコメントする:

#PubkeyAuthentication no

トリックの半分を行い、残りはsshサービスを再起動することでした:

/etc/init.d/sshd restart

出典: ssh-copy-idを実行した後も、パスワードを入力する必要があります

0
shabby

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

0
dinbo

私はこれをコメントとして投稿しますが、おそらく長すぎます。 ssh-copy-id/.sshフォルダ内の$HOMEの場所から公開鍵を送信しようとすることを追加したいと思います。

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

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

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh [email protected] "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

私はこのシナリオを実際に数回(今朝を含めて)遭遇し、誰かが同じ状況に陥った場合に備えて、2セントを入れようと思った。

0
rubynorails

言及されている他の貢献者と同様に、これはおそらく許可の問題です。

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

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

別の考えられる問題は、サーバーが鍵アルゴリズムをサポートしていないことです。私の場合、sshdログ(/var/log/auth.log 私の場合):

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

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

0
Florian Brucker