先日リリースされた macOS Ventura 13.0 が、我が家にもやってきました。普段からお世話になっているアプリケーションたち…各種Webブラウザ、JetBrains製品、Adobe製品、Docker、VS Code、MS Office、Sourcetree などなど、健全に動作しております。
ところが、どうしても さくらインターネット さんのレンタルサーバ へのssh接続の鍵ログインがエラーになっていたのでした。この記事は、その対処法のメモです。
エラーの状況と、その調査
手元の ~/.ssh/config に適切な設定 および 接続先サーバ側の ~/.ssh/authorized_keys に公開鍵を登録することによって、鍵ペアを使ったログインをできるようにしていました。ところが、Venturaな環境ではssh接続しようとすると鍵ペアでのログインは成功せずに、パスワードの入力を求められました。パスワードを入力すればログインできるのですが、これはとても不便です。
原因を調査するにあたって、まずsshコマンドのデバッグ出力を有効にしようとしました。sshのconfigに「LogLevel DEBUG3」などと書くのも良いですが、sshコマンド実行時に ssh -vvvv {設定名} みたいにするのが便利でしょう。
すると、以下のようなメッセージが出てきました。
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/{ユーザ名}/.ssh/{鍵ファイル名} RSA SHA256:{ヒミツ❤️} explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: passwordポイントは debug1: send_pubkey_test: no mutual signature algorithm の行です。直訳すると、共通の署名アルゴリズムが無い、といったところでしょうか。
これにより鍵ペアを使ったログイン（ログ中での言い方は publickey）は断念されてしまい、次の優先度の認証方式であるパスワード認証へと処理が流れていった、という状況です。
もしも、パスワードでの認証が有効でなかったとしたら、この時点で Permission denied(publickey) みたいなエラーメッセージが出されていたのだろうと推測します。（本当はパスワード認証を切るのが正しいのでしょうけども、この鯖では切っていませんでした😇）
対処
さて、send_pubkey_test: no mutual signature algorithm のようなキーワードで検索をかけたところ、どうやらOpenSSHのバージョンが上がったことで古いアルゴリズムが廃止された…的な話がいくつかヒットします。一つの例として、次のサイトが挙げられます。
superuser.com
さて、対処法なのですが、残念なことに、廃止されたアルゴリズムを有効化するという方針になります。手元の環境では ~/.ssh/config の当該ホストのところに PubkeyAcceptedAlgorithms +ssh-rsa という設定を加えることで、鍵ペアを使ったsshログインに成功しました。
当然のことですが、将来この記事に辿り着いた皆さんの環境においては、有効化するべきものは ssh-rsa ではなくて別のアルゴリズムである可能性が結構あります。どの設定を有効にするべきなのかは、接続先サーバのOS等のバージョンと PubkeyAcceptedAlgorithms といったキーワードの組み合わせで検索すれば答えに辿り着くのではないかと思われます。
PubkeyAcceptedAlgorithms とは？
OpenSSHの設定項目の名前です。元々は PubkeyAcceptedKeyTypes という名前で、バージョン6.8で導入されたようです。受付可能な公開鍵を指定するもの、という位置付けですね。
* sshd(8): add sshd_config HostbasedAcceptedKeyTypes and
https://www.openssh.com/txt/release-6.8
PubkeyAcceptedKeyTypes options to allow sshd to control what
public key types will be accepted. Currently defaults to all.
ところが実際には「受付可能な公開鍵」にとどまらず、署名アルゴリズムについても設定可能なものとなっていました。そうすると設定項目の名前が正しくないよね、ということで名称が PubkeyAcceptedAlgorithms に変更されたそうです。
* ssh(1), sshd(8): rename the PubkeyAcceptedKeyTypes keyword to
https://www.openssh.com/txt/release-8.5
PubkeyAcceptedAlgorithms. The previous name incorrectly suggested
that it control allowed key algorithms, when this option actually
specifies the signature algorithms that are accepted. The previous
name remains available as an alias. bz#3253
（おまけ１）なぜクラウド全盛の時代にレンタルサーバを？
仕事で新しいWebアプリを作る時は、Next.js の static site generation で作ったWebアプリケーションのモックを作ることがよくあります。最終成果物がいわゆるモノリシックな Web Application Framework*1 のものであったとしても Next.js のSSGです。つまり、ビルドしたものを置くだけでモックを提供できる構成です。
作ってビルドしたモックを顧客企業内*2で回覧してもらう際、ファイルをお渡しして先方の社内のサーバに置いてもらえるとちょうど良いのですが、それが難しくてこちらでサーバを用意することも多々あります。そうすると何かしらの認証機構およびHTTPS環境が必要です。
他にも、趣味で音楽活動をやっていますが、動画ファイル等を仲間内に配布することも結構あります。そこでも似たような技術要件がかかってきます。
技術要件を列挙すると…
- 静的ファイルが置けたらOK
- HTTPS 必須
- 何かしらの認証機構が必須
- 自分以外がアップロードすることはほとんど無い
…となります。真っ先に思いつく編成としては、AWSで S3 + CloudFront + Lambda@EdgeやCloudFrontFunctionsで認証…というものですが、ちょっっとだけ面倒です😅 構成図は以下に詳しいです。
aws.amazon.com
dev.classmethod.jp
そこで、レンタルサーバの出番です。我々インターネット老人にとっては、Apacheの .htaccess を書いてBASIC認証を仕込むのは朝メシ前であり、数分ほどもあれば終わる作業です。そしてファイルは置くだけです。HTTPSの証明書は最初のセットアップ時に用意する必要がありますが、これは中では Let's Encrypt が動いており、AWSのACM程度には簡単な作業です。…といったことから、レン鯖というのは私および弊社にとって都合の良いサービスなのでした。
それはさておき、古くて弱い方式でしかsshの鍵認証ができないのなら、あまり長く使えるものではないよなぁ、とは認識しております。まだ詳しく調べることはできておりませんが、今年 新サーバ提供開始 されているので、もしかしたら新サーバでは何の問題も無く安心して＆余計な設定無しにssh接続できるかもしれませんね。後日、移行したいと思います。
