概要
SSH の公開鍵認証設定が正しいはずなのにどうしても接続先パスワードを聞かれたときに、実際に確認した内容のまとめた記事です。
最終的に通信経路上に設置されていたセキュリティ機器が SSH 通信をスキャンしていたことが原因でした。*1 *2
試行錯誤しているときは以下の記事などを参考にポート番号を 22 番から変更することで事象が解消されましたが、可能であればセキュリティ機器の設定を修正するのが適切だと思います。
- openssh - ssh client not trying publickey authentication on port 22 - Unix & Linux Stack Exchange
https://unix.stackexchange.com/questions/594404/ssh-client-not-trying-publickey-authentication-on-port-22
以下、原因にたどりつくまでに確認した項目などを列挙しています。
環境
- クライアント・サーバ:共に Ubuntu 20.04
- ssh:OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
確認1:鍵設定の手順を確かめる
なるべくまっさらな状態で確立された手順を確かめつつ実施する。
基本的には以下の通りでうまく動くはず。コマンド実行なのでファイル名のタイポやパーミッション誤りも防げる。 *3
- Ubuntu 20.04でSSHの鍵をセットアップする方法 | DigitalOcean
https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-20-04-ja
ssh-keygen ssh-copy-id username@remote_host ssh username@remote_host
確認2:パーミッション
パスワードを聞かれる原因のほとんどはこれらしい。関連記事も多数。 いつの間にか /home/user/ が 777 になってしまっていたというのが多い様子。
<接続元(クライアント)の設定例>
- chmod 755 /home/
- chmod 755 /home/user
- chmod 700 /home/user/.ssh
- chmod 600 /home/user/.ssh/id_rsa
- chmod 644 /home/user/.ssh/id_rsa.pub
<接続先(サーバ)の設定例>
- chmod 755 /home/
- chmod 755 /home/user
- chmod 700 /home/user/.ssh
- chmod 600 /home/user/.ssh/authorized_keys
確認3:sshd_config の設定値
サーバで公開鍵認証が許可されているか確認する。 デフォルトが yes なので no と明示設定されていない限りは問題ないはず。
# サーバー側 vi /etc/ssh/sshd_config PubkeyAuthentication yes
確認4:sshd のログ
ログを確認してエラーが出力されていないか確認する。最初に確認するのが解決の近道。
[CentOS] /var/log/secure [Ubuntu] /var/log/auth.log
確認5:SELinux が止めていないか確認する
今回の環境は Ubuntu なのであまりないものの、なんらか SELinux の制限にひっかかっている場合も。 以下で ssh 関係の出力がされていないか確認する。
[CentOS] yum install policycoreutils-python cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow
確認6:マシンを再起動する
個別のリスタートでうまくいかなければ。 もしかすると設置値がうまく反映されない場合があるかもと一縷の望みをかけて。
復旧しても往々にして原因不明のままになるので、基本的には避けたい。
確認7:ssh のデバッグログ
今回の事象解消に役に立った方法。 -v
を付けた状態で ssh を実行する。 *4
ssh -v username@remote_host
ずらっとログが出力されるので、パスワードを聞かれる少し上にあるはずの以下の個所を確認。
debug1: Authentications that can continue: password
上記のように password になっている場合、サーバ側で公開鍵認証が許可されておらず、 パスワード認証のみが有効になっている状態を意味する。
本来想定される出力は例えば以下のような感じ。
debug1: Authentications that can continue: publickey,password
設定などが正しいにも関わらず password のみになっている場合、 ポート番号を変更(例えば 2222 などに)することで解消される場合がある。
# サーバー側 vi /etc/ssh/sshd_config Port 2222
設定後に sshd をリスタートする。
sudo systemctl restart sshd
今回の場合はポート番号を変更することで事象が解消され、通信できるようになった。 通信経路上に存在していたセキュリティ機器がポート 22 番での ssh に対してパスワード認証を強制していたためのよう。*5
その他:最新版にアップデートする
Ubuntu のパッケージで導入できる OpenSSL は 1.1.1f となっているが、OpenSSL は 1.1.1j が最新版となっている。*6
特定環境で影響するバグが関係しているのであれば、最新版にアップデートすることで解消される可能性もあるが、別の事象に悩まされることになる可能性もある。 また、利用者と開発者とのやりとりが公開されている場合、ぴったり同じでなくても似た事象がバグ報告されていないかどうかも確認すると問題解決の糸口になるときも。
参考文献
SSH で正しく公開鍵認証設定しているのに接続先パスワードを聞かれるときの対処関連
openssh - ssh client not trying publickey authentication on port 22 - Unix & Linux Stack Exchange
https://unix.stackexchange.com/questions/594404/ssh-client-not-trying-publickey-authentication-on-port-22SSHできないときのトラブルシューティング - Qiita
https://qiita.com/ryuichi1208/items/4151110327584c971f11ssh key validation not working/ ssh: connect to host *** port 22: Connection refused - Ask Ubuntu
https://askubuntu.com/questions/1211887/ssh-key-validation-not-working-ssh-connect-to-host-port-22-connection-refserver - Can't SSH without password to default port of 22 using public/private key authentication - Ask Ubuntu
https://askubuntu.com/questions/1163931/cant-ssh-without-password-to-default-port-of-22-using-public-private-key-authenEDIT: I found the solution, actually the root cause, it turn out that there is a firewall/gateway enforcing the particular policy which only accept Password authentication for Port 22 in the front of the network. It has been applied on the company network which affect easier to reproduce here. It actually work as soon as the policy is taken out and by using the existing configuration.
その他
OpenSSL Newslog
https://www.openssl.org/news/newslog.htmlOpenSSL CHANGES
https://www.openssl.org/news/cl111.txtOpenSSL の脆弱性 (CVE-2020-1967) に関する注意喚起
https://www.jpcert.or.jp/at/2020/at200018.htmlOpenSSL の脆弱性対策について(CVE-2020-1967) :IPA 独立行政法人 情報処理推進機構
https://www.ipa.go.jp/security/ciadr/vul/alert20200423.htmlOpenSSL において、サービス運用妨害(DoS)の脆弱性が確認されています。
この脆弱性が悪用された場合、OpenSSL を実行しているサーバおよびクライアントアプリケーションがクラッシュさせられる可能性があります。
影響を受けるシステム
OpenSSL 1.1.1d、1.1.1e および 1.1.1f
更新履歴
- 2021/03/04 新規作成
- 2021/03/04 一部記載の加除修正。「SELinux が止めていないか確認する」を追記。
- 2021/03/04 暫定的に、通信経路上のセキュリティ機器による SSH 通信のスキャンが原因であったことを冒頭に追記。
- 2021/05/15 暫定的に記載していた内容を本文に反映。合わせて冒頭の記載も修正。