SSHでPermission denied publickey 究極の対処法

SSHでPermission denied publickey 究極の対処法

　*BSD/PC-UNIX/Linuxと同じく、sshを使い始めて8年ほど、たぶん初めてお目にかかったsshでのPermission denied (publickey)の究極の対処法の話。

　誤解を恐れず、原因を簡単に言うと明示的にパスワード認証を無効、公開鍵認証を有効にしている環境下で新たにsshクライアントが増えた場合、既存・これから増える複数のsshクライアントを想定せず、最初から認証方法を鍵認証のみに設定したsshサーバが増えた場合に起こります。

　Raspberry Pi OS、Raspbian、Debian系だけでなく、どんなOSでも遭遇し得る話であり、遭遇した場合、そして、にっちもさっちもいかなくなった場合も後述の究極の解決策は有効なはずです。

　台数が多ければ多いほど、相互なら尚更、作業量が多くなりますけど。

　ここでは、主に超便利で爆速、時短にもなるRaspberry Pi Imagerの利用時に首題の件でハマる可能性について言及しようと思います。

原因

　原因は、次の2つに集約されるかと思います。

　1つめについては、例えば、Raspberry Pi Imagerでイメージを書き込む際の事前設定で[鍵認証のみ有効]にした際に起こり得ます。

　詳細についてはリンク先に譲りますが、Raspberry Pi Imagerはイメージを書き込むだけでなく、事前に認証方法の他、ホスト名やユーザー名の変更、Wi-Fiアクセスポイント設定等々、初期設定できるようになっている上、イメージ書き込みも爆速という超優秀ツールなのです。

　そんな超便利なRaspberry Pi Imagerですが、現時点での事前設定において認証方法については、パスワード認証と鍵認証の両方を有効にしておく選択肢はなく、何れか一方のみです。

　パスワード認証については、鍵認証よりは強度が落ちるものの、先方端末のパスワードさえ知っていれば、ssh接続できるという意味では何も不都合はありませんし、これが有効ならば、運用後に鍵認証を有効にすべく、ssh-copy-idもできます。

　鍵認証を選択した場合、便利なのは、Raspberry Pi OS起動後にssh-keygenしたり、ssh-copy-idしたりする必要なく、デフォルトではImagerを起動している端末からイメージを書き込む(または、付加できるホスト情報に該当する)端末には、後者起動後、即、鍵認証で自動ログインできることです。

　一見何の問題もなく最高な気がします、が、両方とも有効にしておく選択肢がないことが、むしろ、アダになることも。

　そうなんです、Raspberry Pi Imagerを起動した(または、付加できるホスト情報に該当する)デバイス以外のデバイスからイメージを書き込んだラズパイにsshしたい時です。

　つまり、sshクライアント＝Imagerを起動する(付加できるホスト情報に該当する)デバイスで、イメージを書き込むラズパイ全てsshサーバというシナリオでは完璧なのです。

　一方、そもそもsshクライアントが既にたくさんあったり、今後増える可能性があったり、ラズパイ内蔵キーボードRaspberry Pi 400に限らず、2Bでも3B+でも4Bでも何台でも用途問わず、余ったPCディスプレイや液晶テレビとワイヤレスキーボードやワイヤレスマウスをつなぐことがあるなど、これらの間でもsshクライアント、sshサーバ何れにもなり得る状況では、少し困ったことになります。

　なぜなら、Permission denied (publickey)に遭遇する原因の1つめの状況になるから。

　また、その認識があったはずなのにも関わらず、冷静さを欠き、やらかした自身のように、その際に対応にあぐね、慌てて、他のデバイスにも飛び火しつつ、あらゆる策を試し、全端末のauthorized_keysを削除してしまった結果、2つめのケースに至ることもなきにしもあらず。

　パスワード認証よりは鍵認証の方が遥かに安全という全く以て異論のない話から、とにもかくにもパスワード認証を無効にしようという思いが強いほどハマりがち！？

解決策

　1つめが原因の解決策は、root権限が必要となりますが、一時的にパスワード認証を有効にして事後、無効にすべく次のようにすれば対処できます。

　ちなみにRaspberry Pi Imagerで鍵認証のみ有効にした場合は、/etc/ssh/sshd_configの58行め付近のコメントアウトされている[#PasswordAuthentication yes]とは別に最終行に[PasswordAuthentication no]が追記されています。

　2つめが原因の場合の解決策、もしくは、何らかの事情で1つめのの解決策の選択肢がない場合は、

　このようにすることになる理由は、何らかの事情で公開鍵を渡す前からssh認証で鍵認証しか有効となっていないハジメマシテ端末同士の場合、公開鍵がないので肝心な鍵認証ができず、鍵認証を有効にすべく、ssh-copy-idしようにもssh接続しようにもパスワード認証が無効である場合、認証のしようがないからです。

　つまるところ、ハジメマシテな端末同士の場合、せめて初回は、パスワード認証も有効にしておきましょうということですかね。

　初回だけじゃなくて、ずっとそうしておけば、後から追加されるデバイスとsshしたい場合もssh-copy-idが使えるから、簡単に鍵認証に移行できるので楽なのです...が、それが許されないシステムもあるでしょうし、とは言え、セキュリティについて、あらゆる状況を想定し始めると何れにせよ微妙？

備考

　Raspberry Pi Imagerについては、こうした混乱の可能性を回避するためには、むしろ、鍵認証のみの選択肢は不要で、鍵認証を選択する場合、パスワード認証も有効にする選択肢に代え、簡潔にするのが無理ならリンクを設けて、状況に応じて後で後者を無効にしておいた方が良いケースがあるよなどと説明する方がベターかと思いますが...どうなんでしょう。

関連リンク