まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:sftp

クラウドインスタンスだったり、VM だったりで RHEL9.x を使う機会が増えてきました。個人的にはどちらかというと最近は Debian/Ubuntu 派で、Ubuntu の選択肢がある場合は Ubuntu を使うことが多かったと思っています。CentOS 6 はヘビーユーザーでしたが、しばらく CentOS/RHEL を使っていなかったこともあり、久しぶりに使って戸惑うこともでてきています。まあググればなんとかなることが多いんですけど、

そんな中でも解決までに特に時間を要したというか、"RHEL9 からの変更点" の影響を受けて戸惑ったのが SSH 接続でした。SFTP も含めて RHEL9 に SSH 接続したり、RHEL9 から SSH 接続する際にうまく動かない(接続できない)ことが頻発して対処に手間取ったことを、その原因や対処法含めて以下にメモしておきました。


【そもそも何が起こったのか】
IBM Cloud を使って RHEL9.x(正確には 9.2)の VM を作りました。RHEL 8.8 を使うこともできて、8.8 では SSH 秘密鍵ファイルを指定して TeraTerm で接続していました(何も問題ありませんでした)。

そして RHEL 8.8 で使っていた時と全く同じ SSH 鍵ペアを使って RHEL 9.x の VM インスタンスを構成し、TeraTerm を使って SSH で VM に接続しようとして・・・ 接続できませんでした??
2024010401


あれ? 鍵ペアファイルは全く同じなのに、なんで RHEL8.x だと接続できて、RHEL9.x だと接続できないの?? ・・・という点に気付いたのが事の起こりでした。


【RHEL9.x で何が変わったのか】
挙動から考えると「RHEL8.x と RHEL9.x で、SSH 接続に関する何らかの仕様変更があった」と推測するのが自然だと思いました。そういうキーワードで調べているうちに以下の記事を見つけました:
Tera Term で Rocky9/RHEL9 にログインできない(2022/12/7)


キーワード的には自分の手元で起こっている現象に近いことが書かれているような気がして調べてみました。記事内の情報をまとめると、このようなことが書かれていました:
  • RHEL8.x までは OpenSSH の認証方式に RSA/SHA-1 をデフォルトとして使っていた
  • TeraTerm 4.x 以前も OpenSSH の認証方式は RSA/SHA-1 だった
  • RHEL9.x からは RSA/SHA-256 などのより強い認証方式がデフォルトとして採用された
  • TeraTerm 4.x 以前のものでは接続できないので、TeraTerm の対応を待つか、RSA/SHA-256 をサポートした別の SSH クライアントを使う必要がある
なるほど、とりあえず RHEL9.x で認証方式の変更があって、それが原因らしい、ということまではわかりました。

なお同じ理由で RHEL9.x から古い認証方式だけをサポートしたシステムへの SSH 接続もできなくなっています:
2024010402


【RHEL9.x への SSH ログイン】
さて原因が分かったところで、改めてどうすればよいか? を考えます。まずは「RHEL9.x への SSH ログイン」です。

こちらは実は上の記事の最後に追記があり、
  • TeraTerm 5.x では対応済み
になっています。したがって TeraTerm 5.x をダウンロード/インストールして使うことで RHEL9.x へも SSH ログインができるようになります。

TeraTerm のダウンロードはこちらから:
https://github.com/TeraTermProject/osdn-download/releases


【RHEL9.x からの SSH ログイン】
もう1つ、反対方向の SSH ログインについて、こちらは少し厄介な問題です。接続先からすると全く知らない(未対応の)認証方式でアクセスされるので接続先を RSA/SHA-256 対応するよう、アップグレードするしかないような気もします(それが可能な場合はその方法でも対応できます)。

ただそうはいかないケースが多いと思うので、対応策の1つとして「一時的に RSA/SHA-1 をデフォルトにするよう暗号化ポリシーを変更」する方法を紹介します。

RHEL9.x では "update-crypto-policies" という CLI コマンドで暗号化ポリシーの確認や変更ができます。まず root でログインしている状態から、以下のコマンドでデフォルトの暗号化ポリシーを確認してみます(青字が出力結果):
# update-crypto-policies --show
DEFAULT

"DEFAULT" とだけ表示されました。これは特に何も設定されていない(つまり初期値の暗号化ポリシーが使われている)ことを示しています。この状態から変更する必要があります。

では一時的に "SHA1" に変更してみます:
# update-crypto-policies --set DEFAULT:SHA1
Setting system policy to DEFAULT:SHA1
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

この状態で再度デフォルトの暗号化ポリシーを確認してみます:
# update-crypto-policies --show
DEFAULT:SHA1

今度は "DEFAULT:SHA1" と表示されました。これでデフォルトの暗号化ポリシーが "SHA1" に変更できました。この状態であれば古い Linux へも SSH 接続が可能になっています。

目的の SSH 接続が完了してログアウトまでしたら、最後にデフォルト暗号化ポリシーも元に戻しておくことにします:
# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT:SHA1
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

# update-crypto-policies --show
DEFAULT

これで元の暗号化ポリシーに戻すこともできました。

 

最近のクラウド環境では、初期状態で SSH(22) のみファイアウォールを通す設定になっているケースが一般的です。HTTP(80) を通したい場合は別途設定が必要ですが、SSH だけは無条件に使える設定になっている、という意味です。まあ HTTP サーバーを導入するにしても SSH が使えると便利ですよね。

この SSH サーバーの動作ポート番号を 22 番から別の番号へ変更したい場合の設定は /etc/ssh/sshd_config を変更します:
#Port=22
となっている箇所のコメントを外して、例えば
Port=10022
のように変更します。これで再起動すると SSH(SFTP) は 10022 番ポートで稼働します。










 

このページのトップヘ