===(追記:2021/03/04) ===
まだちゃんと確認までできていないものの、通信経路の途中の NW 機器で SSH に対するスキャンが有効になっていることが原因のようでした。
NW 機器がスキャンのために中間者として割り込んでいたのが、通常 SSH で利用されないポート番号に変えたことで検査の対象外となり直接サーバと SSH で接続することができて意図通りの通信ができようになったということのよう。
Twitter で言及していただいたおかげで気づくことができ、謎が解けてとてもうれしかったです。感謝しております。*1 *2
以下は上記に気付く前の記載の記事です。
============================
答え:ポート番号を 22 以外に設定する
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-22
手元の環境でもポート番号を変更したことで事象が解消されたように見えるものの、理屈まで確認できていないため実際には副次的に引き起こされた別の要因で解消されている可能性もありそう。 海外の掲示板では、何かがポート 22 番での ssh に対してパスワード認証を強制しているようだというコメントもあったものの、詳細までは触れられていなかった。
以下、そこに至るまでに確認した項目など。
環境
- クライアント・サーバ:共に 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 に対してパスワード認証を強制していることがあるらしい。 根本的な原因までは追い切れず。
その他:最新版にアップデートする
Ubuntu のパッケージで導入できる OpenSSL は 1.1.1f となっているが、OpenSSL は 1.1.1j が最新版となっている。*5
特定環境で影響するバグが関係しているのであれば、最新版にアップデートすることで解消される可能性もあるが、別の事象に悩まされることになる可能性もある。 また、利用者と開発者とのやりとりが公開されている場合、ぴったり同じでなくても似た事象がバグ報告されていないかどうかも確認すると問題解決の糸口になるときも。
参考文献
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 冒頭に追記。