AlmaLinux 9 SSH設定・鍵認証リファレンス

企業のサーバー運用において、SSH はリモート管理の基盤です。パスワード認証のままで運用を続けると、ブルートフォース攻撃や認証情報の漏洩によるリスクが残ります。本記事では、AlmaLinux 9 での SSH 鍵認証の導入から、sshd_config の設定、ポート変更と SELinux 連携、暗号化ポリシー（crypto-policies）、踏み台サーバー経由の接続（ProxyJump）まで、企業のセキュリティ要件を踏まえた設定手順を網羅しています。設定変更のたびに切り戻し方法を併記しているため、本番環境でも安心して作業を進められます。

SSH 設定 早見表

やりたいこと	コマンド / 設定
鍵ペア生成（Ed25519）	ssh-keygen -t ed25519 -C “user@example.corp”
鍵ペア生成（RSA 4096bit）	ssh-keygen -t rsa -b 4096
公開鍵をサーバーへ転送	ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
sshd 構文チェック	sshd -t
sshd 再起動	systemctl restart sshd
SSH ポートの SELinux 許可	semanage port -a -t ssh_port_t -p tcp 10022
暗号化ポリシー確認	update-crypto-policies –show
踏み台経由の接続	ssh -J bastion.example.corp user@target
ssh-agent に鍵を登録	eval $(ssh-agent) && ssh-add ~/.ssh/id_ed25519
SSH ログのリアルタイム監視	journalctl -u sshd -f
known_hosts から古い鍵を削除	ssh-keygen -R hostname

前提条件

項目	値
OS	AlmaLinux 9.6（Sage Margay）
OpenSSH	8.7p1
OpenSSL	3.5.1
暗号化ポリシー	DEFAULT
SELinux	Enforcing
実行ユーザー	サーバー側: root 権限、クライアント側: 一般ユーザー

SSH のバージョンを確認するコマンドは以下の通りです。

$ ssh -V

OpenSSH_8.7p1, OpenSSL 3.5.1 1 Jul 2025

1. SSH 鍵の種類と推奨アルゴリズム

SSH 鍵認証で使用するアルゴリズムは複数ありますが、AlmaLinux 9 の環境では Ed25519 を第一候補として選択します。レガシー機器との接続が必要な場合に限り RSA を使用してください。

アルゴリズム	鍵長	特徴	推奨度
Ed25519	固定 256bit	高速、鍵が短い、OpenSSH 6.5 以降対応	第一推奨
RSA	3072bit 以上	レガシー機器との互換性が高い。RHEL 9 の DEFAULT ポリシーで SHA-1 署名が無効のため注意	レガシー用
ECDSA	256 / 384 / 521bit	NIST 曲線への暗号学的懸念あり。Ed25519 で代替可能	非推奨

ECDSA は NIST（米国国立標準技術研究所）が定義した楕円曲線を使用しています。この曲線のパラメータ選定過程に不透明さがあるとする指摘があり、暗号学の研究者の間でも議論が続いています。Ed25519 は Daniel J. Bernstein が設計した Curve25519 をベースとしており、パラメータが公開された数学的根拠に基づいて選定されています。新規構築では Ed25519 を選択してください。

2. 鍵ペアの生成と公開鍵の配置

Ed25519 鍵ペアの生成（推奨）

クライアント側で鍵ペアを生成します。-C オプションでコメントを付けておくと、サーバーの authorized_keys で鍵の所有者を識別できます。

$ ssh-keygen -t ed25519 -C "user@example.corp"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc user@example.corp
The key's randomart image is:
+--[ED25519 256]--+
|        .o=+o    |
|       . o.+     |
|        o.o .    |
|       +.+ .     |
|      o S.o      |
|     . =.+.o     |
|      +.=o*..    |
|     ..+oB+*.    |
|      .oEBB+o    |
+----[SHA256]-----+

パスフレーズの入力を求められます。企業の運用ではパスフレーズの設定が必須とされることが多いため、空のまま Enter を押すことは避けてください。パスフレーズを設定しておけば、秘密鍵ファイルが漏洩した場合でも、パスフレーズなしでは鍵を使用できません。

RSA 鍵ペアの生成（レガシー用）

接続先の機器が Ed25519 に対応していない場合は、RSA 4096bit で生成します。RHEL 9 の DEFAULT 暗号化ポリシーでは RSA 鍵の最小サイズが 2048bit に設定されていますが、安全マージンを考慮して 4096bit を指定します。

$ ssh-keygen -t rsa -b 4096

公開鍵のサーバーへの転送

ssh-copy-id コマンドを使うと、公開鍵の配置とパーミッション設定を自動で行えます。

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is by the remote host
user@server's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@server'"
and check to make sure that only the key(s) you wanted were added.

手動で公開鍵を配置する場合

ssh-copy-id が使用できない環境では、手動で公開鍵を配置します。サーバー側で以下の操作を行います。

$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ cat >> ~/.ssh/authorized_keys << 'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPEf4JupM+ZgPm9KTXc8Fl6OgzvNC44EGAXECztUkd0s user@example.corp
EOF
$ chmod 600 ~/.ssh/authorized_keys

パーミッション一覧

SSH 鍵認証はパーミッションが正しくないと動作しません。以下の値を守ってください。

対象	パーミッション	設定コマンド
~/.ssh/	700	chmod 700 ~/.ssh
~/.ssh/authorized_keys	600	chmod 600 ~/.ssh/authorized_keys
秘密鍵（id_ed25519）	600	chmod 600 ~/.ssh/id_ed25519
公開鍵（id_ed25519.pub）	644	chmod 644 ~/.ssh/id_ed25519.pub

鍵認証の動作確認

-v オプションを付けて接続し、鍵認証が使用されていることを確認します。

$ ssh -v user@server

出力の中に以下のような行が表示されれば、鍵認証で接続が成功しています。

debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
debug1: Authentication succeeded (publickey).

3. sshd_config の主要設定

sshd の設定ファイルは /etc/ssh/sshd_config です。AlmaLinux 9 では、ドロップイン設定ファイル（/etc/ssh/sshd_config.d/*.conf）が推奨されていますが、まず主要なディレクティブの意味と推奨値を把握しておきます。

ディレクティブ	推奨値	目的
PermitRootLogin	no	root での直接ログインを禁止し、権限昇格の経路を限定する
PasswordAuthentication	no	鍵認証を強制し、パスワード総当たり攻撃を防ぐ（鍵認証確認後に変更）
PubkeyAuthentication	yes	公開鍵認証を有効にする
AllowGroups	ssh-users	SSH 接続を許可するグループをホワイトリスト方式で制限する
MaxAuthTries	3	認証試行回数を制限し、ブルートフォース攻撃の効率を下げる
LoginGraceTime	30	認証完了までの猶予時間を 30 秒に短縮し、接続を占有されることを防ぐ
ClientAliveInterval	300	5 分ごとにキープアライブを送信し、放置セッションを検出する
ClientAliveCountMax	2	キープアライブに 2 回応答がなければ切断する（最大 10 分で切断）
MaxSessions	3	1 つの接続で多重化できるセッション数を制限する
X11Forwarding	no	X11 転送を無効にし、不要な攻撃面を減らす
PermitEmptyPasswords	no	空パスワードでのログインを禁止する

AlmaLinux 9 のデフォルト値（sshd -T の出力）では、PermitRootLogin without-password（鍵認証のみ root ログイン許可）、PasswordAuthentication yes、MaxAuthTries 6、LoginGraceTime 120 となっています。企業の運用基準に合わせて上記の推奨値に変更してください。AllowGroups で指定するグループの作成手順は ユーザー管理編 を参照してください。

# sshd -t

何も出力されなければ構文に問題はありません。エラーがある場合はファイル名と行番号が表示されます。

構文チェックを通過したら、別のターミナルで現在の SSH 接続を維持したまま再起動します。

# systemctl restart sshd

4. sshd_config.d/ ドロップイン設定

AlmaLinux 9 の sshd_config には、先頭に Include /etc/ssh/sshd_config.d/*.conf という行があります。この仕組みにより、/etc/ssh/sshd_config.d/ ディレクトリ内の .conf ファイルが名前順に読み込まれます。

50-redhat.conf の内容

AlmaLinux 9 にはデフォルトで /etc/ssh/sshd_config.d/50-redhat.conf が配置されています。

Include /etc/crypto-policies/back-ends/opensshserver.config
SyslogFacility AUTHPRIV
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
PrintMotd no

1 行目の Include で暗号化ポリシー（crypto-policies）の設定を読み込んでいます。暗号スイートの変更は、このファイルを直接編集するのではなく、crypto-policies のコマンドで行います（第 7 章で解説）。

カスタム設定ファイルの作成

sshd は同じディレクティブが複数回定義されている場合、最初に読み込んだ値を採用します（先勝ちルール）。ファイルはアルファベット順に読み込まれるため、50-redhat.conf より先に読み込まれるように 01- で始まるファイル名を使用します。

# vi /etc/ssh/sshd_config.d/01-custom.conf

設定内容の例：

PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 3
X11Forwarding no
PermitEmptyPasswords no

# sshd -T | grep -i permitrootlogin

permitrootlogin no

5. パスワード認証の無効化（安全な手順）

手順 1: 鍵認証で接続できることを確認します。

$ ssh -v user@server

出力に Authentication succeeded (publickey). が含まれていることを確認します。

手順 2: ドロップイン設定ファイルに PasswordAuthentication no を追加します。

# vi /etc/ssh/sshd_config.d/01-custom.conf

追加する行：

PasswordAuthentication no

手順 3: 構文チェックを実行します。

# sshd -t

手順 4: 現在の SSH 接続を維持したまま、別のターミナルで sshd を再起動します。

# systemctl restart sshd

手順 5: 新しいターミナルを開き、鍵認証で接続できることを確認します。

$ ssh user@server

手順 6: パスワード認証が無効になっていることを確認します。

$ ssh -o PubkeyAuthentication=no user@server

user@server: Permission denied (publickey).

上記のように Permission denied (publickey). と表示されれば、パスワード認証は無効になっています。

切り戻し方法

鍵認証で接続できない場合は、既存のセッションから以下の手順で切り戻します。

# sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config.d/01-custom.conf
# sshd -t && systemctl restart sshd

6. SSH ポート変更と SELinux 連携

SSH のデフォルトポート（22）を変更すると、ポートスキャンによる自動攻撃を軽減できます。ポート変更には sshd_config の修正に加えて、SELinux と firewalld の設定変更が必要です。3 つすべてを正しく設定しないと接続できなくなります。

手順 1: semanage コマンドで、カスタムポートを SELinux に登録します。semanage は policycoreutils-python-utils パッケージに含まれています。

# dnf install -y policycoreutils-python-utils

現在 SELinux で許可されている SSH ポートを確認します。

# semanage port -l | grep ssh

ssh_port_t                     tcp      22

カスタムポート 10022 を追加します。

# semanage port -a -t ssh_port_t -p tcp 10022

手順 2: ドロップイン設定ファイルにポートを指定します。

# vi /etc/ssh/sshd_config.d/01-custom.conf

追加する行：

Port 10022

手順 3: firewalld でカスタムポートを許可します。firewalld の詳細な操作方法は ファイアウォール編 を参照してください。

# firewall-cmd --permanent --add-port=10022/tcp
# firewall-cmd --reload

手順 4: 構文チェック後に sshd を再起動します。

# sshd -t && systemctl restart sshd

手順 5: 新しいターミナルからカスタムポートで接続を確認します。

$ ssh -p 10022 user@server

切り戻し方法

カスタムポートで接続できない場合は、既存セッションから以下の手順で元に戻します。

# sed -i '/^Port 10022/d' /etc/ssh/sshd_config.d/01-custom.conf
# sshd -t && systemctl restart sshd
# semanage port -d -t ssh_port_t -p tcp 10022
# firewall-cmd --permanent --remove-port=10022/tcp
# firewall-cmd --reload

7. RHEL 9 の暗号化ポリシー（crypto-policies）

RHEL 9 系（AlmaLinux 9 を含む）では、システム全体の暗号化設定を crypto-policies で一元管理しています。SSH だけでなく、TLS、DNSSEC、Kerberos なども同じポリシーの影響を受けます。

現在のポリシーを確認します。

# update-crypto-policies --show

DEFAULT

ポリシーレベルの比較

ポリシー	特徴	用途
LEGACY	SHA-1、RSA 1024bit など旧式アルゴリズムを許可	古いシステムとの互換性が必要な場合
DEFAULT	RSA-SHA1 署名を無効化。RSA 最小 2048bit	通常の運用（AlmaLinux 9 の初期値）
FUTURE	128bit セキュリティ未満のアルゴリズムを無効化	長期運用で高い暗号強度が求められる場合
FIPS	FIPS 140-2 / 140-3 準拠のアルゴリズムのみ許可	政府機関・金融機関の規制要件

DEFAULT ポリシーで RSA-SHA1 が無効になる影響

AlmaLinux 9 の DEFAULT ポリシーでは、RSA-SHA1 署名が無効化されています。そのため、CentOS 7 など古い OS が稼働するサーバーへ SSH 接続すると、以下のエラーが発生する場合があります。

Unable to negotiate with 192.168.1.200 port 22: no matching host key type found. Their offer: ssh-rsa

このエラーは、接続先サーバーが提示するホスト鍵のアルゴリズム（ssh-rsa = RSA-SHA1）が、クライアント側の暗号化ポリシーで許可されていないことを意味します。

レガシー対応: SHA1 サブポリシーの適用

システム全体を LEGACY ポリシーに下げると、SSH 以外のサービス（TLS など）も旧式アルゴリズムを許可してしまいます。SHA-1 のみを追加で許可するサブポリシーを使用してください。

# update-crypto-policies --set DEFAULT:SHA1

変更後、SSH の暗号化設定がどのように反映されているかは、バックエンドファイルで確認できます。

# cat /etc/crypto-policies/back-ends/opensshserver.config

Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
RequiredRSASize 2048

切り戻し方法

# update-crypto-policies --set DEFAULT

8. クライアント側設定（~/.ssh/config）

クライアント側の SSH 設定ファイル ~/.ssh/config を活用すると、接続先ごとにホスト名・ユーザー名・ポート・鍵ファイルを事前に定義でき、毎回のオプション指定が不要になります。

基本構文

Host web-prod
    HostName 192.168.10.11
    User deploy
    Port 10022
    IdentityFile ~/.ssh/id_ed25519_prod

Host db-prod
    HostName 192.168.10.21
    User dbadmin
    Port 10022
    IdentityFile ~/.ssh/id_ed25519_prod

Host *.dev.example.corp
    User developer
    IdentityFile ~/.ssh/id_ed25519_dev
    ServerAliveInterval 60

この設定を記述すると、ssh web-prod と入力するだけで、指定したホスト・ユーザー・ポート・鍵で接続できます。

$ ssh web-prod

主要ディレクティブ

ディレクティブ	説明
Host	接続名（ワイルドカード使用可: *.prod.example.corp）
HostName	接続先の IP アドレスまたは FQDN
User	接続ユーザー名
Port	接続先ポート番号
IdentityFile	使用する秘密鍵のパス
ServerAliveInterval	キープアライブ送信間隔（秒）。NAT 環境でのセッション切断防止に有効

ServerAliveInterval 60 を設定すると、クライアントが 60 秒ごとにキープアライブパケットを送信します。NAT やファイアウォールがアイドル状態の TCP セッションを切断する環境で、接続の維持に役立ちます。

9. 踏み台サーバー経由の接続（ProxyJump）

企業ネットワークでは、インターネットから直接本番サーバーへ SSH 接続することは許可されていないケースが一般的です。踏み台サーバー（Bastion Host）を経由してアクセスする構成が広く採用されています。

接続の流れ：ローカル PC → 踏み台サーバー（bastion.example.corp）→ 本番サーバー（target.example.corp）

ProxyJump（推奨）

OpenSSH 7.3 以降で使用できる ProxyJump（-J オプション）は、踏み台経由の接続を 1 行で記述できます。ProxyJump では秘密鍵がローカル PC 上にのみ存在し、踏み台サーバーには転送されません。

$ ssh -J bastion.example.corp user@target.example.corp

~/.ssh/config での設定例

Host bastion
    HostName bastion.example.corp
    User operator
    IdentityFile ~/.ssh/id_ed25519

Host target-prod
    HostName 10.0.1.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastion

この設定により、ssh target-prod と入力するだけで踏み台経由の接続が行われます。

$ ssh target-prod

ProxyCommand（レガシー）

OpenSSH 7.3 より前の環境では ProxyCommand を使用します。

Host target-prod
    HostName 10.0.1.10
    User deploy
    ProxyCommand ssh -W %h:%p bastion

踏み台経由のファイル転送（SCP）

$ scp -o ProxyJump=bastion.example.corp localfile.tar.gz user@target.example.corp:/tmp/

~/.ssh/config に ProxyJump を設定済みの場合は、通常の SCP と同じ記法で転送できます。

$ scp localfile.tar.gz target-prod:/tmp/

10. ssh-agent の活用とエージェント転送の注意

ssh-agent は秘密鍵をメモリ上に保持し、SSH 接続時にパスフレーズの再入力を不要にするプログラムです。パスフレーズ付き鍵を使用する運用では、作業効率の向上に役立ちます。

ssh-agent の起動と鍵の登録

$ eval $(ssh-agent)

Agent pid 12345

$ ssh-add ~/.ssh/id_ed25519

Enter passphrase for /home/user/.ssh/id_ed25519:
Identity added: /home/user/.ssh/id_ed25519 (user@example.corp)

登録済みの鍵を確認します。

$ ssh-add -l

256 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc user@example.corp (ED25519)

エージェント転送のリスク

エージェント転送（ssh -A または ForwardAgent yes）を使用すると、踏み台サーバーから本番サーバーへ接続する際にローカルの ssh-agent を利用できます。ただし、踏み台サーバーの root 権限を持つユーザーが、転送されたエージェントのソケットを悪用して、あなたの秘密鍵で別のサーバーへ接続できてしまいます。

11. SSH バナー設定

SSH バナーは、ユーザーが認証を行う前に表示されるメッセージです。企業では、不正アクセスを抑止するための法的警告文を表示する目的で設定します。コンプライアンス監査でバナーの設定有無を確認されることがあります。

バナーファイルの作成

# vi /etc/ssh/banner.txt

企業で使用される法的警告文の例：

**********************************************************************
WARNING: This system is for authorized use only.
All activities on this system are monitored and recorded.
Unauthorized access to this system is prohibited and may result
in criminal prosecution or other legal action.
**********************************************************************

sshd への設定

/etc/ssh/sshd_config.d/01-custom.conf に以下を追加します。

Banner /etc/ssh/banner.txt

# sshd -t && systemctl restart sshd

12. ログの確認と監査

SSH の認証ログは、不正アクセスの検出やインシデント調査に不可欠です。AlmaLinux 9 では、journald と rsyslog の両方で SSH ログを確認できます。

journalctl によるリアルタイム監視

# journalctl -u sshd -f

-f オプションで、新しいログが出力されるたびにリアルタイムで表示されます。

認証ログの読み方

認証成功のログ：

Mar 24 23:36:38 alma-main sshd[6609]: Accepted publickey for developer from 192.168.1.100 port 52393 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc

このログから読み取れる情報は以下の通りです。

• Accepted publickey：公開鍵認証で接続が成功した
• for developer：接続ユーザー名
• from 192.168.1.100 port 52393：接続元 IP アドレスとポート
• ED25519 SHA256:W2DB...：使用された鍵のアルゴリズムとフィンガープリント

認証失敗のログ例：

Mar 24 23:40:15 alma-main sshd[6650]: Failed password for invalid user admin from 203.0.113.50 port 44821 ssh2

Failed password for invalid user は、存在しないユーザー名でパスワード認証を試行したことを示します。外部からのブルートフォース攻撃の兆候です。

rsyslog によるログ確認

50-redhat.conf で SyslogFacility AUTHPRIV が設定されているため、rsyslog 経由では /var/log/secure にログが記録されます。

# tail -20 /var/log/secure

LogLevel VERBOSE の設定（監査要件）

企業のセキュリティ監査では、接続に使用された鍵のフィンガープリントをログに記録することが求められる場合があります。LogLevel VERBOSE を設定すると、認証に使用された鍵のフィンガープリントがログに出力されます。

/etc/ssh/sshd_config.d/01-custom.conf に追加する行：

LogLevel VERBOSE

ログイン履歴の確認

# last -i

-i オプションを付けると、接続元の IP アドレスが数値で表示されます。ホスト名の逆引きに依存しないため、ログの読み取りが安定します。

# lastlog

lastlog は、各ユーザーの最終ログイン日時を一覧表示します。長期間ログインがないアカウントは、退職者のアカウントが残っている可能性があるため、定期的に確認してください。

13. トラブルシューティング

鍵認証が通らない

鍵認証が失敗する原因の多くはパーミッションの設定ミスです。以下の値を確認してください。

• ~/.ssh ディレクトリ: 700
• ~/.ssh/authorized_keys: 600
• ホームディレクトリ: 755 以下（グループやその他に書き込み権限がないこと）

パーミッションが正しい場合は、ssh -vvv で詳細なデバッグ情報を確認します。

$ ssh -vvv user@server

サーバー側でも、SELinux がホームディレクトリのラベルを正しく設定しているか確認します。

# restorecon -Rv ~/.ssh

sshd 再起動後にログインできない

sshd_config の構文エラーにより sshd が起動できなくなるケースです。設定変更時は必ず以下の手順を守ってください。

1. 別のターミナルで SSH 接続を維持する
2. sshd -t で構文チェックを実行する
3. エラーがないことを確認してから systemctl restart sshd を実行する
4. 新しいターミナルで接続を確認してから、古いセッションを閉じる

既存セッションが残っている場合は、そのセッションから設定ファイルを修正して復旧できます。

"no matching host key type found" エラー

AlmaLinux 9 の DEFAULT 暗号化ポリシーで RSA-SHA1 が無効化されていることが原因です。

Unable to negotiate with 192.168.1.200 port 22: no matching host key type found. Their offer: ssh-rsa

一時的な対処として、接続時にアルゴリズムを明示的に指定できます。

$ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@old-server

恒久的な対処として、SHA1 サブポリシーを適用します（第 7 章参照）。

# update-crypto-policies --set DEFAULT:SHA1

"WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" エラー

サーバーの再構築や IP アドレスの再割り当てにより、known_hosts に保存されているホスト鍵と実際のホスト鍵が一致しない場合に発生します。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

サーバーの再構築や OS 再インストールなど、ホスト鍵が変わる正当な理由が確認できている場合は、古い鍵を削除します。

$ ssh-keygen -R hostname

SSH ポート変更後に接続できない

ポート変更時は、以下の 3 箇所すべてを確認してください。

1. SELinux: semanage port -l | grep ssh でカスタムポートが ssh_port_t に登録されているか
2. firewalld: firewall-cmd --list-ports でカスタムポートが許可されているか
3. sshd_config: sshd -T | grep port で設定が反映されているか

# semanage port -l | grep ssh
# firewall-cmd --list-ports
# sshd -T | grep port

踏み台経由で接続できない

ProxyJump が失敗する場合は、以下を確認してください。

• 踏み台サーバー自体に SSH 接続できるか: ssh bastion.example.corp
• 踏み台サーバーで AllowTcpForwarding yes が設定されているか（sshd -T | grep allowtcpforwarding）
• 踏み台サーバーから本番サーバーへの TCP 接続がファイアウォールで許可されているか
• ~/.ssh/config の ProxyJump 設定にホスト名やユーザー名の記述ミスがないか

14. 企業運用チェックリスト

企業の SSH 運用で確認すべき項目を一覧にまとめます。定期監査やサーバー構築時のチェックリストとして活用してください。SSH 以外のセキュリティ強化策については セキュリティ強化編 も併せて確認してください。

カテゴリ	チェック項目	確認コマンド / 対象
鍵管理	パスフレーズが設定されている	運用ルールで規定
鍵管理	退職者の公開鍵が authorized_keys から削除されている	authorized_keys の棚卸し
鍵管理	鍵の定期ローテーションが実施されている	鍵生成日の記録と照合
接続制限	AllowGroups で SSH 接続可能なグループが制限されている	sshd -T | grep allowgroups
接続制限	PermitRootLogin no が設定されている	sshd -T | grep permitrootlogin
認証	パスワード認証が無効化されている	sshd -T | grep passwordauthentication
監査	LogLevel VERBOSE が設定されている	sshd -T | grep loglevel
監査	ログが定期的に確認されている	journalctl -u sshd / /var/log/secure
ネットワーク	踏み台経由のアクセスが強制されている	firewalld / ネットワーク ACL
暗号化	crypto-policies が DEFAULT 以上に設定されている	update-crypto-policies --show
通知	SSH バナーが設定されている	sshd -T | grep banner
運用	設定変更時に sshd -t を実行している	手順書に記載
運用	設定変更時に別セッションを維持している	手順書に記載

AlmaLinux 9 総合リファレンスガイド シリーズ一覧

1. システム基本情報の確認
2. 初期設定
3. ネットワーク設定（nmcli）
4. パッケージ管理（dnf）
5. ユーザー・グループ管理
6. ファイアウォール（firewalld）
7. SSH設定・鍵認証（この記事）
8. systemd / サービス管理
9. ストレージ・LVM
10. ログ管理（journalctl / rsyslog）
11. cron / systemd timer
12. セキュリティ強化
13. パフォーマンス監視
14. コンテナ管理（Podman）
15. バックアップ・リストア