Rocky Linux / rootアカウントでSSH接続可能に設定する方法

Rocky LinuxでrootアカウントのSSHログインを許可することは可能ですが、一般管理者アカウントとsudoを使用する方がより安全で監査も容易です。どうしてもroot直接接続が必要な場合は、パスワードログインは開かずに公開鍵認証のみを許可し、設定チェックと別セッションでのテストを経た上で適用してください。

まず推奨方式の確認

一般ユーザーでログインした後、必要なコマンドだけをsudoで実行することで、root認証情報の直接露出を減らし、ユーザーごとの作業記録を残すことができます。

sudo useradd adminuser
sudo usermod -aG wheel adminuser

adminuserは未使用の実際のアカウント名へ置き換え、存在する場合は作成を繰り返しません。公開鍵とホーム内の所有者・権限を整え、通常のwheel設定でsudoが本人のパスワードを求める場合はsudo passwd adminuserでその認証も準備します。公開鍵を登録しただけではsudo用パスワードは設定されません。新しいセッションでログインとsudo -vを確認するまで、既存の管理接続を閉じないでください。

現在のSSHおよびrootログイン設定の確認

設定ファイルの1行を見るよりも、sshd -Tでインクルードファイルとデフォルト値を合算した最終有効設定を確認する方が正確です。

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Match条件のある設定は、接続ユーザーや発信元アドレスによって結果が異なる場合があります。複雑な環境ではsshd -T -Cで実際の条件を指定して確認してください。

root公開鍵の準備

キー ファイルと権限設定

既存のauthorized_keysを属性を保ってバックアップし、信頼できる管理者の公開鍵だけを追加します。次のssh-ed25519 公開鍵のBase64文字列 管理者の識別名は例示用の置き換え位置であり、有効な鍵ではありません。実際の公開鍵1行全体に置き換えてください。暗号ポリシーに適合する鍵を選び、FIPS（連邦情報処理標準）環境などで拒否される場合に暗号制約を安易に緩めないでください。

sudo install -d -m 700 -o root -g root /root/.ssh
printf '%s\n' 'ssh-ed25519 公開鍵のBase64文字列 管理者の識別名' | sudo tee -a /root/.ssh/authorized_keys > /dev/null
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh

秘密キーはサーバーにアップロードしません。公開キーを追加する際には、改行が壊れていないか、既に登録されているキーと重複していないかを確認してください。

公開キー自体の制限

自動化専用キーであれば from=、command=、restrict のように authorized_keys オプションで接続元と実行機能を制限できます。ただし、間違った制限は作業を中断させる可能性があるため、別のキーでまずテストしてください。

root ログインを公開キーのみで許可

最初に設定一式をバックアップし、メイン設定のIncludeと既存のMatchを確認します。次の例は、グローバル設定より後の/etc/ssh/sshd_config末尾へ置くroot用ブロックです。既存のroot向けMatchがあれば重複追加せず有効なブロックを編集します。冒頭で読み込む90-root-key-login.confなどにMatchを安易に挿入せず、後続設定の解釈に影響しない配置を確認してください。

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

prohibit-passwordはrootのパスワードとキーボード対話型認証を禁止しますが、それだけで他の非パスワード方式まで禁止する意味ではありません。ここではAuthenticationMethods publickeyもrootブロックへ指定して、公開鍵を必須にします。設定は原則として先に得た値を使うため、後のファイル名が大きいだけで上書きできるとは限りません。rootと通常管理者の条件で、それぞれsshd -T -Cの結果を確認します。

構文検査・反映・別セッションでの試験

1. 現在の管理者セッションを開いたままにします。
2. sshd -tで文法をチェックします。出力がなく、終了ステータスが0である必要があります。
3. SSHサービスを再読み込みします。
4. 新しいターミナルでroot公開キーによるログインを試します。
5. パスワードログインが拒否され、既存の管理者アカウントが正常かどうかを確認します。

sudo sshd -t &&
sudo systemctl reload sshd &&
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods) '

構文検査が失敗したらreloadを実行せず、該当するファイルと行を修正します。例のclient.example.testと192.0.2.10は実際のクライアント名・送信元へ置き換え、他のMatch条件も必要に応じて指定します。公開鍵の試験は別端末からssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 root@ホストのように実際の鍵を指定して行います。認証設定の表示だけで成功とせず、新規接続を確認します。失敗時は残した管理接続から今回の設定や鍵の追加だけをバックアップに照らして戻し、再検査してreloadします。

接続範囲をさらに縮小する方法

ファイアウォールで管理ネットワークのみ許可

SSHをVPNや管理網の送信元へ絞る例です。public・192.0.2.0/24は実環境へ置き換えます。sshサービスの定義は通常22/tcpなので、ポートを変えた構成では実際の待ち受けに合わせます。まず既存許可を残してランタイムに規則を追加します。

sudo firewall-cmd --zone=public \
  --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'
sudo firewall-cmd --zone=public --list-rich-rules

コンソール復旧手段を確認し、許可元からの事前接続を試します。ただし広いssh許可が残る間は制限の検証にはなりません。規則を記録してからsudo firewall-cmd --zone=public --remove-service=sshで広い許可を取り除き、再び新規接続を試します。他のポート許可・ゾーン・IPv6経路も確認し、失敗時は今回取り除いた許可を管理セッションまたはコンソールから戻します。正常と確認してからsudo firewall-cmd --runtime-to-permanentで現在の構成全体を保存します。詳しくはfirewalldの管理を参照してください。

ユーザーとキーを分ける

• 個々の人ごとに異なるキーを発行し、退職・役割変更時にはそのキーだけを廃止します。
• 自動化キーと人の対話型管理キーを区別します。
• 秘密鍵にパスフレーズを設定し、エージェント転送は必要な場合だけ使います。
• SSHログと異常な認証試行を中央で収集し、警告します。

rootパスワードでのログインをどうしても開く必要がある場合

PermitRootLogin yesとパスワード認証を同時に有効にすると、ブルートフォース攻撃や資格情報漏洩の被害がすぐに最高権限に直結します。古い機器などやむを得ない理由がある場合は、インターネットに直接公開せず、VPN・管理ネットワーク、短い適用時間、強力な一時パスワード、集中モニタリングを併用してください。

PermitRootLogin yes
PasswordAuthentication yes
AuthenticationMethods any

この例は例外的な作業のため、前節の同じroot用Matchブロックの値を置き換える場合だけを示します。AuthenticationMethods publickeyが有効なままではパスワードだけの接続はできません。アカウントのロック状態やPAM（Pluggable Authentication Modules）など別の条件もあります。短い適用時間と管理網に限定し、終了後は公開鍵必須またはrootログイン禁止へ戻し、使った一時パスワードも適切に変更・失効させます。

root直接ログインを再度禁止

不要になったら、実際に有効なroot用MatchブロックのPermitRootLoginを次の値へ変更します。既に有効な値を残したまま別の場所へ追記するのではなく、構文・有効設定・新規接続を再検査します。

PermitRootLogin no

rootログインを禁止する前に、通常管理者アカウントの公開鍵ログインとsudoが正常かどうかをまず確認してください。

問題が発生したときに確認すべき項目

参考文書

OpenSSH sshd_config公式マニュアルで、PermitRootLogin、Matchおよび認証関連設定の正確な意味を確認できます。