公開鍵認証でsshを使用してもパスワードプロンプトが表示されるのはなぜですか？
私はここで見つけたURLから作業しています：
私のsshクライアントはUbuntu 64ビット11.10デスクトップで、私のサーバーはCentos 6.2 64ビットです。私は指示に従いました。 sshでパスワードプロンプトが表示されます。
次に何をしたらよいかわかりません。
~/.sshディレクトリの権限とその内容が適切であることを確認してください。最初にssh鍵認証を設定したとき、~/.sshフォルダが適切に設定されていなかったため、怒鳴られました。
- ホームディレクトリ
~、~/.sshディレクトリ、およびリモートマシン上の~/.ssh/authorized_keysファイルは、自分だけが書き込み可能にする必要があります。rwx------とrwxr-xr-xは問題ありませんが、あなたがグループの唯一のユーザーであっても、rwxrwx---はダメです¹（数値モードを好む場合：700ではなく755または775）。~/.sshまたはauthorized_keysがシンボリックリンクの場合、 正規パス（シンボリックリンクが展開されている）がチェックされます 。 ~/.ssh/authorized_keysファイル（リモートマシン上）は読み取り可能（少なくとも400）である必要がありますが、さらにキーを追加する場合は書き込み可能（600）である必要があります。- （ローカルマシン上の）秘密鍵ファイルは、あなただけが読み書きできる必要があります：
rw-------、つまり600。 - また、SELinuxがenforcingに設定されている場合、
restorecon -R -v ~/.sshを実行する必要がある場合があります（例 buntuバグ96566 および Debianバグレポート＃658675 を参照）。これは- CentOS 6でパッチ ）。
¹ グループ内の唯一のユーザーである場合にグループの書き込み可能性を許可するようにコードにパッチを適用した一部のディストリビューション（Debianおよび派生物）を除きます。
サーバーへのrootアクセス権がある場合、このような問題を解決する簡単な方法は、サーバーで/usr/sbin/sshd -d -p 2222のようなものを発行することにより、デバッグモードでsshdを実行することです（sshd実行可能ファイルへのフルパスが必要、which sshdはヘルプ）、次にssh -p 2222 user@Hostを使用してクライアントから接続します。これにより、SSHデーモンがフォアグラウンドにとどまり、すべての接続に関するデバッグ情報が表示されます。のようなものを探します
debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/
代替ポートを使用できない場合は、SSHデーモンを一時的に停止して、デバッグモードのデーモンに置き換えることができます。 SSHデーモンを停止しても既存の接続は強制終了されないため、リモート端末を介してこれを実行することは可能ですが、やや危険です-デバッグ置換が実行されていないときに何らかの理由で接続が切断されると、マシンからロックアウトされます再起動できるまで。必要なコマンド：
service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start
（Linuxディストリビューションによっては、代わりに最初/最後の行がsystemctl stop sshd.service/systemctl start sshd.serviceになる場合があります。）
あなたのホームディレクトリは暗号化されていますか？その場合、最初のsshセッションではパスワードを入力する必要があります。同じサーバーへの2番目のsshセッションは、認証キーで動作しています。この場合、authorized_keysを暗号化されていないディレクトリに移動し、~/.ssh/configのパスを変更できます。
私がやったことは、ユーザー名が所有する/etc/ssh/usernameフォルダを作成し、適切な権限を付与して、そこにauthorized_keysファイルを配置することでした。次に、/etc/ssh/configのAuthorizedKeysFileディレクティブを次のように変更しました：
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
これにより、複数のユーザーがアクセス許可を損なうことなく、このsshアクセスを持つことができます。
キーをリモートマシンにコピーしてauthorized_keys内に配置したら、次のようにする必要があります。
ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
次のコマンドを試してください
ssh-keygenプロンプトが表示されるまでEnterキーを押します
ssh-copy-id -i root@ip_address（一度ホストシステムのパスワードを要求します）
ssh root@ip_addressこれで、パスワードなしでログインできるはずです。
リモートのホームディレクトリに適切な権限がない場合、問題に直面しました。私の場合、チーム内のローカルアクセスのために、ユーザーがホームディレクトリを777に変更しました。マシンはsshキーで接続できなくなりました。許可を744に変更すると、再び機能し始めました。
私たちは同じ問題に遭遇し、答えの手順に従いました。しかし、それでもまだうまくいきませんでした。私たちの問題は、ログインが1つのクライアントからは機能するが別のクライアントからは機能しないことでした（.sshディレクトリがNFSマウントされ、両方のクライアントが同じキーを使用していた）。
だから私たちは一歩先に行かなければなりませんでした。 sshコマンドを冗長モードで実行すると、多くの情報が得られます。
ssh -vv user@Host
私たちが発見したのは、デフォルトのキー（id_rsa）が受け入れられず、代わりにsshクライアントがクライアントのホスト名と一致するキーを提供したことです：
debug1: Offering public key: /home/user/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
明らかに、これは他のクライアントからは機能しません。
この場合の解決策は、デフォルトのrsaキーをuser @ myclientが含まれているものに切り替えることでした。キーがデフォルトの場合、クライアント名のチェックは行われません。
次に、切り替え後に別の問題が発生しました。どうやらキーはローカルのsshエージェントにキャッシュされており、デバッグログに次のエラーが記録されています。
'Agent admitted failure to sign using the key'
これは、sshエージェントにキーをリロードすることで解決しました。
ssh-add
RedHat/CentOS 6上のSELinux pubkey認証に問題があります 、おそらくいくつかのファイルが作成されたときに、selinuxはACLを正しく設定していません。
RootユーザーのSElinux ACLを手動で修正するには：
restorecon -R -v /root/.ssh
これは、サーバー側でのSSHの構成ミスです。サーバー側のsshd_configファイルを編集する必要があります。にあります /etc/ssh/sshd_config。そのファイルで、変数を変更します
ChallengeResponseAuthentication、PasswordAuthentication、UsePAMの「はい」から「いいえ」
PubkeyAuthenticationの「いいえ」から「はい」
http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/ に基づく
AuthorizedKeysFileが正しい場所を指していることを確認し、ユーザー名のプレースホルダーとして%uを使用します。
# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys
行のコメントを外す必要があるだけかもしれません：
AuthorizedKeysFile .ssh/authorized_keys
変更を有効にするには、sshサービスをリロードする必要があることに注意してください。
service sshd reload
私は同様の問題に遭遇し、デバッグモードを使用して手順に従いました。
/usr/sbin/sshd -d
これは次の結果を示した
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic
それは本当に混乱しました
[root@sys-135 ~]# ls -l /
drwxrwxrwx. 2 root root 4096 Dec 14 20:05 bin
drwxrwxrwx. 5 root root 1024 May 6 2014 boot
drwxrwxrwx. 2 root root 4096 Dec 2 2013 cgroup
drwxrwxrwx. 10 root root 1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root 12288 Dec 16 10:26 etc
drwxrwxrwx. 11 root root 4096 Jan 14 2014 lib
drwxrwxrwx. 9 root root 12288 Dec 14 20:05 lib64
drwxrwxrwx. 2 root root 16384 Jan 10 2014 lost+found
drwxrwxrwx. 2 root root 4096 Jun 28 2011 media
drwxr-xr-x. 2 root root 0 Dec 10 14:35 misc
drwxrwxrwx. 2 root root 4096 Jun 28 2011 mnt
drwxrwxrwx. 4 root root 4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root 0 Dec 10 14:35 proc
drwxrwxrwx. 45 root root 4096 Dec 16 10:26 root
これは、ルートディレクトリにすべてのユーザーのアクセス許可があることを示しています。他のユーザーが権限を持たないように変更しました。
[root@sys-135 ~]# chmod 750 /root
キー認証が機能し始めました。
私の解決策は、アカウントがロックされたことでした。/var/log/secureにメッセージが見つかりました：アカウントがロックされているため、ユーザーは許可されません解決策：ユーザーに新しいパスワードを与えてください。
2つのコメント：これは元のファイルを上書きします。生成された公開鍵をコピーして、次のようにします。
cat your_public_key.pub >> .ssh/authorized_keys
これにより、使用するキーが既存のキーのリストに追加されます。また、一部のシステムではauthorized_keys2ファイルを使用するため、念のため、authorized_keysとauthorized_keys2の間を指すハードリンクを作成することをお勧めします。
私が間違っていたのは、サーバーシステムのホームディレクトリの所有権でした。サーバーシステムはdefault：defaultに設定されているので、
chown -R root:root /root
そしてそれはうまくいった。もう1つの安価な回避策は、StrictModesを無効にすることです。 sshd_config。これにより、少なくとも鍵交換と接続プロトコルが適切かどうかがわかります。次に、不正な権限を探しに行くことができます。
/ etc/selinux/configファイルで、SELINUXを無効に変更すると、パスワードなしのsshが正常に機能するようになりました。
以前は、一方向でそれを行うことができました。これで双方向から、パスワードなしのsshを実行できます。
過去に、sshのパスワードなしのセットアップを実現する方法を説明したチュートリアルに出くわしましたが、一部は悲しいことに間違っています。
最初からやり直して、すべてのステップを確認します。
- FROM CLIENT-キーを生成：
ssh-keygen -t rsa
公開鍵と秘密鍵（id_rsa.pubおよびid_rsa）は、~/.ssh/ディレクトリに自動的に格納されます。
空のパスフレーズを使用すると、セットアップが簡単になります。そうしたくない場合は、このガイドに従ってください。ただし、以下の箇条書きも確認してください。 - FROM CLIENT-公開鍵をserverにコピーします：
ssh-copy-id user@server
クライアントの公開鍵はサーバーの場所~/.ssh/authorized_keysにコピーされます。 - FROM CLIENT-サーバーに接続します：
ssh user@server
ここで、説明されている3つの手順を実行しても問題が解決しない場合は、以下を試してください。
- クライアントおよびサーバーマシンで
~/sshフォルダーの権限を確認します。 - serverの
/etc/ssh/sshd_configをチェックして、RSAAuthentication、PubkeyAuthentication、およびUsePAMオプションが無効になっていないことを確認します。これらは、yesでデフォルトで有効にできます。 - クライアントキーの生成中にパスフレーズを入力した場合は、
ssh-agent＆ssh-addを試して、セッションでパスワードなしの接続を確立できます。 - serverの
/var/log/auth.logの内容を確認して、キー認証がまったくスキップされる問題を見つけます。
私にとって、解決策は反対でした Wojtek Rzepala's ：私はauthorized_keys2をまだ使用していることに気付きませんでした 非推奨になりました 。おそらくサーバーが更新されたときに、私のsshセットアップが機能しなくなった。 .ssh/authorized_keys2の名前を.ssh/authorized_keysに変更すると、問題が修正されました。
ああ！
Ubuntu 16.04マシンに接続するPuTTYでもまったく同じ問題が発生していました。 PuTTYのpscpプログラムが同じキーで正常に機能していたため（そして、同じキーがPuTTYで別のホストに接続するように機能していたため）、それは不可解でした。
@UtahJarheadからの貴重なコメントのおかげで、/ var/log/auth.logファイルを確認したところ、次のことがわかりました。
sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
OpenSSHの新しいバージョンは、デフォルトでDSAキーを受け入れないことがわかりました。 DSAキーからRSAキーに切り替えると、問題なく動作しました。
別のアプローチ：この質問では、DSAキーを受け入れるようにSSHサーバーを構成する方法について説明します。 https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less -authentication？lq = 1
アクセス許可を確認し、ここに記載されている他のいくつかの解決策を試した後、サーバーのsshディレクトリを削除し、公開鍵を再度セットアップしました。
サーバーコマンド：
# rm -rf ~/.ssh
ローカルコマンド：
# ssh-copy-id [email protected] # where <user> is your username and <192.168.1.1> is the server IP
Sshでも同様の問題がありました。私の場合の問題は、hadoop cloudera（centos 6のrpmから）をインストールし、ホームディレクトリでユーザーhdfsを作成したことでした。
/var/lib/hadoop-hdfs（標準の/home/hdfsではありません）。
/ etc/passwd /var/lib/hadoop-hdfsを/home/hdfsに変更し、ホームディレクトリを新しい場所に移動して、公開鍵認証で接続できるようになりました。
サーバーで：
$ ls -lh /home
$ Sudo chmod 700 /home/$USER
そうだった directory permission issue。サーバーでは777だったので、I changed it back to 700。このfixed私の問題ssh password less login failureコピー後も$USER/.ssh/id_rsa.pubサーバー$USER/.ssh/authorized_keys。
私はこれと同じ問題を抱えていましたが、私にとっての解決策はUsePAMをnoに設定することでした。 PasswordAuthenticationをnoに設定しても、keyboard-interactiveが引き続き表示されます。私の場合、なんらかの理由で、ローカルのsshプログラムがデフォルトに設定しています。
同じ状況の人を助ける追加の背景：Dropbearを実行しているホストからOpenSSHを実行しているホストに接続しています。 PasswordAuthenticationとUsePAMの両方がリモートマシンでnoに設定されている場合、ssh user@serverと入力すると次のメッセージが表示されます。
ssh: Connection to user@server:22 exited: Disconnect received
IDファイルに-iを指定すると、すべてが期待どおりに機能します。
これらのステップはあなたを助けるはずです。私はこれを多くの64ビットUbuntu 10.04マシンで定期的に使用しています。
[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'
これをいくつかのプロンプトを含むスクリプトに入れて、次のように呼び出すことができます
script_name username remote_machine
私のシナリオは、プライマリアカウントの作成後にNASサーバーにbackupbotユーザーを作成し、ログインして最初にbackupbotユーザー。Sudo vim /etc/ssh/sshd_configをいじってbackupbotユーザーを作成した後、vimは、少なくともUbuntu 16.04上で、~/.vimrc設定に基づいてスワップファイル vimセッションによる/etc/ssh/sshd_configの編集から残っています。
/etc/ssh/.sshd_config.swpが存在するかどうかを確認し、存在しない場合はそれを削除してsshdデーモンを再起動します。
$ Sudo rm /etc/ssh/.sshd_config.swp
$ Sudo service sshd restart
これは魔法のように私の問題を解決しました。私は以前にすべての権限と、公開鍵と秘密鍵のRSAフィンガープリントさえもチェックしていました。これは奇妙で、sshdのバグである可能性があります。具体的にはこのバージョンです。
OpenSSH_7.4p1 Ubuntu-10、OpenSSL 1.0.2g 2016年3月1日
さらに別のオプションは、@ Jagadishのバリアントです answer ：to strace sshデーモン。
これには、sshdを停止する必要がないという大きな利点があります。これは、何かがうまくいかなかった場合に完全なロックアウトを引き起こす可能性があります。
まず、メインのsshdプロセスのpidを見つけます。ここでは、pstree -pa|less。
|-sshd,633 -D <-- THIS IS WHAT WE WANT!
| `-sshd,21973
| `-sshd,21996
| `-bash,22000
| `-screen,638 -r
Pidが633であることを知った後、その子に従ってstraceできます。
strace -p 633 -s 4096 -f -o sux
結果は、このsshdとその子プロセスが行ったeverythingがsuxという名前のファイルにstraceされます。ローカルディレクトリ。
次に、問題を再現します。
カーネルコールログの大規模なリストが表示されます。これは、ほとんどの場合は理解できない/無関係ですが、どこにでもあるわけではありません。私の場合、重要なことはこれです：
6834 sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84
これは、sshdがメッセージをログに記録しようとしたことを意味していましたアカウントがロックされているため、ユーザーcicaは許可されていません-ロギングが十分ではなかったため、許可できませんでしたそのための冗長。しかし、アカウントがロックされていたため、公開鍵は拒否されました。
それはまだ解決策ではありません-今私たちはグーグルする必要があります、それはsshdの場合には「ロックされたアカウント」を意味します。それはおそらく些細なことです/etc/passwd、/etc/shadowウィザードリィ、しかし重要なことが行われます-問題は神秘的ではありませんが、簡単にデバッグ可能/グーグル可能な問題です。
私の場合、すべての権限があり、-vvvフラグを指定してsshを実行した場合でも、何が問題なのか理解できませんでした。
remote Hostで新しい証明書を生成しました
ssh-keygen -t rsa -C "[email protected]"
生成されたキーをローカルマシンにコピーし、新しい公開キーをリモートホストの〜/ .ssh/authorized_keysに追加しました
cat id_rsa.pub >> authorized_keys
リモートホストマシン接続から生成されたキーの使用が機能するようになりました。したがって、他のソリューションが失敗した場合、これは別の試みです。