気の向くままに辿るIT/ICT/IoT
webzoit.net
ハードウェア

SSHでPermission denied publickey 究極の対処法

ウェブ造ホーム前へ次へ
サイト内検索
カスタム検索
Raspberry Piって?

SSHでPermission denied publickey 究極の対処法

SSHでPermission denied publickey 究極の対処法

2022/02/23

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

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

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

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

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

原因

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

  1. ハジメマシテの端末におけるssh時の認証方法が(一方、または、何れも)鍵認証のみでパスワード認証が無効
  2. 何らかの事情で(一方、または、何れも)相手の公開鍵情報を持った有効な~/.ssh/authorized_keysがない

 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]が追記されています。

  1. 一方通行でsshしたいならsshサーバ側(sshされる側)、相互にsshしたいなら各端末の/etc/ssh/sshd_config 58行め付近の[#PasswordAuthentication yes]の他に明示的に[PasswordAuthentication no]となっている行があれば、一時的にyesに変更して保存、systemctl daemon-realod、systemctl restart sshd
  2. SSHクライアント(sshする方)からssh-copy-id -i ~/.ssh/公開鍵 ユーザー名@sshサーバ.local(IPアドレスでも可)後、ssh接続、パスワード認証後、ログイン、exit、再ログイン時、(鍵認証により)自動ログインできることを確認。
  3. 必要なら/etc/ssh/sshd_configの最終行の設定を元(no)に戻し、systemctl daemon-realod、systemctl restart sshd

*相互にssh接続したい場合は、それぞれ行う。

*/etc/ssh/sshd_configでは、現時点では、初期状態でコメントアウトされている項目の設定値が現在の設定値であり、noが明示されていなければ、58行め付近のコメントアウトされているyesが有効となり、パスワード認証は有効。

*一方で/etc/ssh/sshd_configは、同じ項目の設定がある場合、現時点では、より前にある設定が有効になるようなので最終行でnoが明示されていても58行め付近のコメントアウトされている[#PasswordAuthentication yes]の#を取るという方法もあります。

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

  1. 公開鍵をSSHではなく、Warpinator、NAS、FTPやUSBメモリ経由などでsshサーバ側(sshされる側)の端末にコピーし、中身を、なければ新規作成・chmod 600とした~/.ssh/authorized_keysファイルに追加。
  2. Debian GNU/LinuxでClamTk/ClamAV
  3. Debianリポジトリとは別にsnapを使ってアプリをインストール
  4. Debian bullseye/Wine 7.0/Kindle for PC 1.38.0で電子書籍を読む
  5. KVMでDebian bullseye amd64上にWindows 10 x86_64インストール
  6. sshクライアントから接続、ログイン時、(鍵認証により)自動ログインできることを確認。

*相互にssh接続したい場合は、それぞれ行う。

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

 1つめの原因であっても、2つめの原因の解決策でも対処できますが、root権限があるなら、1つめに対する解決策の方が早いでしょう。

*何れにせよ、パスワード認証を無効にしておく場合、接続すべき、sshサーバが増える度、既存のsshサーバに接続すべきsshクライアントが増える度に毎回これらを行うことになるでしょう。

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

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

備考

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

ウェブ造ホーム前へ次へ