sshで公開キー認証のパスワードプロンプトが表示されるのはなぜですか？

私はここで見つけたURLから作業しています：

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

私のsshクライアントはUbuntu 64ビット11.10デスクトップで、サーバーはCentos 6.2 64ビットです。私は指示に従いました。まだsshでパスワードプロンプトが表示されます。

次に何をすべきかわかりません。

~/.sshディレクトリとそのコンテンツの権限が適切であることを確認してください。sshキー認証を最初にセットアップしたとき、~/.sshフォルダーが適切にセットアップされていなかったため、大声で叫びました。

• あなたのホームディレクトリ~、あなたの~/.sshディレクトリと~/.ssh/authorized_keys：リモートマシン上のファイルには、あなただけ書き込み可能でなければならないrwx------とrwxr-xr-x罰金ですが、rwxrwx---（：あなたは、数値のモードを好む場合、あなたのグループの唯一のユーザーであっても、何らgood¹はありません700か755、ではありません775） 。
  場合~/.sshやauthorized_keysシンボリックリンクである、（拡大シンボリックリンク付き）正規のパスがチェックされます。
• あなたの~/.ssh/authorized_keys（リモートマシン上の）ファイルには、（少なくとも400）読み取り可能でなければなりませんが、あなたがそれに任意の複数のキーを追加する場合は、（600）にも書き込み可能にそれをする必要があります。
• （ローカルマシン上の）あなたの秘密鍵ファイルは、あなただけで読み書き可能でなければなりませんrw-------、すなわち600。
• また、SELinuxが強制に設定されている場合、実行する必要がある場合がありますrestorecon -R -v ~/.ssh（たとえば、Ubuntuバグ965663およびDebianバグレポート＃658675を参照してください。これはCentOS 6でパッチされています）。

¹ _{グループの唯一のユーザーである場合、グループの書き込みを許可するためにコードにパッチを適用した一部のディストリビューション（Debianおよび派生物）を除きます。}

サーバーへのルートアクセスがある場合、このような問題を解決する簡単な方法は/usr/sbin/sshd -d -p 2222、サーバー上で（sshd実行可能ファイルへのフルパスが必要ですwhich sshd）を発行してデバッグモードで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そこにファイルを配置することでした。次に、AuthorizedKeysFileディレクティブをに変更しまし/etc/ssh/configた：

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

これにより、権限を損なうことなく、複数のユーザーがこのsshにアクセスできます。

キーをリモートマシンにコピーして内部に配置した後、authorized_keys次のような操作を行う必要があります。

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

次のコマンドを試してください

1. ssh-keygen

   プロンプトが表示されるまでEnterキーを押します

2. ssh-copy-id -i root@ip_address

   （一度ホストシステムのパスワードを要求します）

3. ssh root@ip_address

   これで、パスワードなしでログインできるはずです。

リモートのホームディレクトリに正しい権限がない場合、私は課題に直面しました。私の場合、ユーザーはチーム内でのローカルアクセスのためにホームディレクトリを777に変更しました。マシンはsshキーで接続できなくなりました。許可を744に変更すると、再び機能し始めました。

RedHatの/ CentOSの6のSELinuxはpubkeyで認証の問題を持っているいくつかのファイルが作成されると、おそらくSELinuxが正しくそのACLを設定していません、。

rootユーザーのSElinux ACLを手動で修正するには：

restorecon -R -v /root/.ssh

私たちは同じ問題にぶつかり、答えの手順に従いました。しかし、それでもまだうまくいきませんでした。私たちの問題は、ログインが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

サーバーエンドでのSSHミス設定です。サーバー側のsshd_configファイルを編集する必要があります。にあり/etc/ssh/sshd_configます。そのファイルで、変数を変更します

• ChallengeResponseAuthentication、PasswordAuthentication、UsePAMに対して「yes」から「no」

• 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

2つのコメント：これは元のファイルを上書きします。生成された公開鍵をコピーして、次のようなことをするだけです。

cat your_public_key.pub >> .ssh/authorized_keys

これにより、使用するキーが既存のキーのリストに追加されます。また、一部のシステムはfileを使用するため、念のauthorized_keys2ため、との間authorized_keysを指すハードリンクを作成することをお勧めしauthorized_keys2ます。

私の解決策は、アカウントがロックされたことです。/ var / log / secureにあるメッセージ：アカウントがロックされているため、ユーザーは許可されません解決策：ユーザーに新しいパスワードを与えます。

同様の問題が発生し、デバッグモードを使用して手順を実行しました。

/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

キー認証が機能し始めました。

/ etc / selinux / configファイルで、SELINUXを強制から無効に変更すると、パスワードなしのsshが正常に機能するようになりました。

以前、私は片道でそれをすることができました。これで、両方からパスワードなしのsshを実行できるようになりました。

私が間違っていたことの1つは、サーバーシステム上のホームディレクトリの所有権です。サーバーシステムはdefault：defaultに設定されているため、次のようにします。

chown -R root:root /root

そしてそれは働いた。別の安価な回避策は、StrictModesを無効にすることです：StirctModes no。sshd_configで。これにより、少なくともキー交換および接続プロトコルが適切かどうかがわかります。その後、不正なアクセス許可を探しに行くことができます。

私にとっては、解決策はWojtek Rzepalaの反対でした。私はまだ使用authorized_keys2していることに気づきませんでした。私のsshセットアップは、おそらくサーバーが更新されたときに、ある時点で機能しなくなりました。名前を変更.ssh/authorized_keys2し.ssh/authorized_keysて問題を修正しました。

ど！

過去に、パスワードなしのsshセットアップを実現する方法を説明するチュートリアルに出くわしましたが、悲しいことに間違っているものもあります。
もう一度やり直して、すべてのステップを確認しましょう。

1. FROM CLIENT -Generate key：ssh-keygen -t rsa
   公開キーと秘密キー（id_rsa.pubおよびid_rsa）が~/.ssh/ディレクトリに自動的に保存されます。
   空のパスフレーズを使用すると、セットアップが簡単になります。そうしたくない場合は、このガイドに従ってください。ただし、以下の箇条書きも確認してください。
   
   
2. FROM CLIENT-公開キーをサーバーにコピー：ssh-copy-id user@server
   クライアントの公開キーはサーバーの場所に コピーされます~/.ssh/authorized_keys。
   
   
3. FROM CLIENT-サーバーに接続します：ssh user@server
   
   

ここで、説明した3つのステップを実行してもまだ機能しない場合は、次を試してください。

• クライアントおよびサーバーマシンの~/sshフォルダーのアクセス許可を確認します。
• チェック/etc/ssh/sshd_configして、サーバーのことを確実にするためRSAAuthentication、PubkeyAuthenticationおよびUsePAMオプションが無効になっていない、彼らはでデフォルトで有効にすることができますyes。
• クライアントの鍵を生成しながら、パスフレーズを入力した場合、あなたは試すことssh-agent＆ssh-addあなたのセッションでパスワードなしの接続を実現します。
• サーバー/var/log/auth.log上のの内容を確認して、キー認証がまったくスキップされない理由を見つけます。

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

これらの手順は役立ちます。多くの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

sshでも同様の問題がありました。私の場合、問題はhadoop clouderaをインストールし（centos 6のrpmから）、ホームディレクトリでユーザーhdfsを作成したことでした

/var/lib/hadoop-hdfs（標準ではありません/home/hdfs）。

/ etc / passwd /var/lib/hadoop-hdfsをに変更し/home/hdfs、ホームディレクトリを新しい場所に移動し、公開キー認証で接続できるようになりました。

私はちょうど同じ問題を抱えていたので、解決策はに設定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、すべてが期待どおりに機能します。

ここにもう少し情報があるかもしれません。

許可を確認し、ここにリストされている他のいくつかの解決策を試した後、サーバー上のsshディレクトリを最終的に削除し、公開鍵を再度設定しました。

サーバーコマンド：

# rm -rf ~/.ssh

ローカルコマンド：

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

サーバーで：

$ 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です。

さらに別のオプションは、@Jagadishさんの変種である答えに：straceSSHデーモン。

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とその子プロセスが行ったことはすべてsux、ローカルディレクトリに指定されたファイルに追跡されます。

その後、問題を再現します。

カーネルコールログの膨大なリストがありますが、ほとんどの場合、これはわかりにくい/無関係ですが、どこにでもあるわけではありません。私の場合、重要なことはこれでした：

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は、アカウントがロックされているため、User cica not allowedというメッセージをログに記録しようとしましたが、ログに記録できないため、記録できませんでした。しかし、アカウントがロックされていたため、公開鍵は拒否されました。

これはまだ解決策ではありません-sshdの場合は「ロックされたアカウント」を意味するGoogleを使用する必要があります。おそらく些細な/etc/passwd、/etc/shadow魔法のようなものになりますが、重要なことは行われています-問題は謎めいたものではなく、簡単にデバッグ/グーグルできる問題です。

私の場合、私にはすべての権限があり、-vvvフラグを指定してsshを実行した場合でも、何が問題なのかわかりませんでした。

そこで、リモートホストで新しい証明書を生成しました

ssh-keygen -t rsa -C "your_email@example.com"

生成されたキーをローカルマシンにコピーし、リモートホストの〜/ .ssh / authorized_keysに新しい公開キーを追加しました

cat id_rsa.pub >> authorized_keys

リモートホストマシン接続から生成されたキーを使用できるようになりました。したがって、他のソリューションが失敗した場合、これは別の試みです。

私のシナリオではbackupbot、プライマリアカウントの作成後にユーザーを作成したNASサーバーがあり、ログインして最初に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日