web-dev-qa-db-ja.com

SSH接続は、キーは受け入れられるがパスワードを要求する

SSHキーが受け入れられたように見えても、パスワードの入力を求められます。私の知る限り、以下のログにある「Server accepts key：pkalg ssh-rsa blen 277」という行は、私の鍵が受け入れられたことを意味します。

デバッグログは次のとおりです。

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sam/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <<HASH REDACTED>>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: Trying private key: /home/sam/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

SSHの問題が発生していることがわかったすべての人が、私が目にしている以前の時点で失敗しました。

sshrsa
12
SamStephens

あなたの秘密鍵は確かに受け入れられません、それは試みられただけです。 SSHキーベースの認証が失敗する可能性のある方法はいくつかあり、ロギングはそれほど優れていないため、この特定の問題のデバッグは私の個人的な問題の1つです。エラーは通常であり、次のいずれかの状況の結果であることがわかりました。

  • あなたの~/.ssh/authorized_keysファイルが開きすぎます。あなた自身の保護のためにsshdはあなたをあなた自身から保護しようとします。許可されたキーファイルの権限がある場合、認証に失敗します。 chmod -R go-rwx ~/.sshを実行します。
  • ~/.ssh/authorized_keysの公開鍵の形式が正しくありません。これは多くの問題の結果である可能性がありますが、最も一般的なのはコピーペーストの問題です。一部の端末では、画面間でコピー/貼り付けを行うと、行の折り返しが新しい行として解釈されます。 authorized_keysファイルの各エントリmustは1行です。これを確認するには、ターミナルエミュレータのサイズを変更し、ブレークがあるかどうかを確認し、wc -l ~/.ssh/authorized_keysの出力と、そこにあるべきキーの数を比較します。 、またはあなたにとって最も効果的なものは何でも。各キーが1行であることを確認してください。問題はありません。
11
Scott Pack

貼り付けたssh -v出力は、キーを使用しようとしたが機能しないことを示唆しているため、キーボードインタラクティブに移行しました。

接続しているサーバーの認証ログを確認しましたか？ （例：/var/log/auth.log）。リモートエンドでの設定が正しくない場合（たとえば、権限が間違っている場合）、ssh -v（または-vvまたは-vvv）はこれを通知しませんが、sshdによってログに記録されます。

7
Daniel Lawson

私の場合、ファイル/var/log/authlogは次のことを示しています：

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory

.sshで正しい所有権/権限を確認しましたが、$HOMEには777の権限がありました。 $HOMEに755の権限を設定すると、sftpが機能するようになりました。再度、感謝します。

5
Robin AA

サーバーに（直接または別のログインを介して）アクセスできる場合は、サーバーのログインを確認します（たとえば）/var/log/sshdまたは/var/log/secureシステムに応じて

通常は、~/.ssh/authorized_keysファイルの権限エラーが原因です。誰でも読み取り可能ではないことを確認してください。ただし、sshdを実行しているユーザー（場合によってはサービスユーザー）が読み取り可能であることを確認してください

2
Ash

リモートでの~/.ssh/authorized_keysの権限は重要です（私のシステムではRHELおよびSolarisの場合は600）

リモートでのホームディレクトリの権限は重要です（私のシステムでは700）

最後に、別のポートでデバッグモードのリモートマシンでsshdを実行すると便利です。

Sudo /usr/sbin/sshd -p 5555 -dd

5555はポートの例であり、変更できます。この点に関する詳細については、以下を参照してください。 http://ubuntuforums.org/archive/index.php/t-2219973.html

1
sepehr hakimi

sshdサービスを使用すると問題が発生することがわかりました。この問題を回避するには、service sshd stopを使用してsshdサービスを停止し、Sudo /usr/sbin/sshdを使用してコマンドプロンプトからsshdデーモンを開始します。

0
Yoganand Bijapur

試す

/sbin/restorecon -r /root/.ssh

権限の設定で起こりうる問題。

0
abkrim