SSH鍵認証と堅牢化
SSH はリモートのサーバへ安全に接続する仕組みです。パスワード認証は総当たり攻撃に弱いため、公開鍵認証への切り替えが推奨されます。手元で ssh-keygen により秘密鍵と公開鍵のペアを作り、公開鍵だけを ssh-copy-id でサーバに登録します。秘密鍵は絶対に渡さず手元で厳重に保管します。さらに /etc/ssh/sshd_config で root ログインの禁止やパスワード認証の無効化を行うと、入口が一段と堅牢になります。
SSH（Secure Shell）は、ネットワーク越しに別のコンピュータへ安全にログインし、コマンドを実行するための仕組みです。通信全体が暗号化されるため、途中の経路で盗み見られても中身が読まれません。基本の使い方は `ssh user01@192.0.2.10` のように「ユーザ名@接続先」を指定する形で、接続先で待ち受けている sshd というサービスが応答します。SSH は既定でポート（port）22番を使います。問題は認証方法です。初期状態ではパスワード認証が有効なことが多いのですが、インターネットに公開されたサーバには、ありがちなユーザ名とパスワードを片端から試す総当たり（ブルートフォース）攻撃が絶え間なく届きます。パスワードがどれだけ強くても「当てられる可能性がゼロではない」入口を開け続けることになります。そこで推奨されるのが、公開鍵認証（public key authentication）への切り替えです。
公開鍵認証のしくみ
公開鍵認証では、対になる2つの鍵を使います。秘密鍵（private key）は手元のPCに厳重に保管し、決して外へ出しません。公開鍵（public key）は接続先のサーバに登録します。認証のとき、サーバは「この公開鍵に対応する秘密鍵を本当に持っているか」を暗号的に確認し、持っていれば本人と認めてログインを許します。秘密鍵そのものはネットワークを流れないため、経路上で盗まれる心配がありません。鍵は十分に長く、パスワードのように人が推測したり総当たりしたりすることが現実的に不可能なため、パスワード認証より格段に堅牢です。公開鍵は他人に知られても、それ単体ではログインできないので問題ありません。守るべきはあくまで手元の秘密鍵だけ、という点が理解の要です。
鍵を作る ssh-keygen と登録する ssh-copy-id
鍵のペアは手元のPCで `ssh-keygen` を実行して作ります。アルゴリズムを指定して `ssh-keygen -t ed25519` とするのが今どきの推奨で、互換性を優先するなら `ssh-keygen -t rsa -b 4096` でも構いません。実行すると保存場所（既定は ~/.ssh/ 以下で、秘密鍵 id_ed25519 と公開鍵 id_ed25519.pub の2つ）と、パスフレーズを尋ねられます。パスフレーズは秘密鍵自体にかける追加の合言葉で、万一秘密鍵ファイルが盗まれても、これがあれば即座には悪用されません。空のまま進めることもできますが、安全のため設定するのが望ましいです。作った公開鍵をサーバへ登録するには `ssh-copy-id user01@192.0.2.10` を使うのが簡単です。これは公開鍵を接続先の ~/.ssh/authorized_keys に正しい権限で追記してくれるコマンドで、登録後は `ssh user01@192.0.2.10` でパスワードなしに（パスフレーズを設定していればその入力だけで）ログインできるようになります。
パーミッションのつまずきに注意
公開鍵認証でよくつまずくのが、~/.ssh ディレクトリや関連ファイルのパーミッションです。SSH は安全のため、これらの権限がゆるいと（他人に読み書きできる状態だと）鍵を無視してログインを拒否します。手で設定する場合は、~/.ssh は 700、authorized_keys は 600、秘密鍵も 600 にします（`chmod 700 ~/.ssh`、`chmod 600 ~/.ssh/authorized_keys`）。「鍵を登録したのにパスワードを聞かれる」ときは、まずこの権限と、サーバ側のログ /var/log/secure を確認するのが定石です。秘密鍵は絶対に他人へ渡したりメールに添付したりせず、もし漏れた疑いがあれば、その公開鍵をサーバの authorized_keys から削除して鍵を作り直します。
sshd_config による堅牢化
鍵認証に移行したら、サーバ側の設定ファイル /etc/ssh/sshd_config でさらに入口を固めます。代表的なのは、root での直接ログインを禁止する `PermitRootLogin no` と、パスワード認証そのものを無効化する `PasswordAuthentication no` です。後者を有効にすると総当たり攻撃は鍵を持たない限り成立しなくなり、効果が非常に大きいです。ただし設定変更の前に、必ず別の端末で鍵ログインが成功することを確かめてから行ってください。鍵が使えない状態でパスワード認証を切ると、自分も締め出されます。設定を書き換えたら `sshd -t` で文法を検査し、問題なければ `systemctl restart sshd` で反映します。必要なら待ち受けポートを22番から変更する（`Port 10022` など）ことで自動攻撃のノイズを減らせますが、その際は後述のファイアウォールで新しいポートを開け、SELinux にもポート変更を教える（`semanage port -a -t ssh_port_t -p tcp 10022`）必要がある点に注意します。
実務の使いどころ
実務では、SSH の堅牢化は他のセキュリティ対策と組み合わせて多層で効かせます。公開鍵認証でパスワードという弱点をなくし、root ログイン禁止で最も狙われる入口を塞ぎ、ファイアウォールで接続元を絞り、fail2ban で執拗な攻撃元を自動遮断する——これらは互いを補い合います。複数のサーバを行き来するなら、手元の ~/.ssh/config にホストごとの接続情報（ホスト名・ユーザ名・鍵ファイル・ポート）を書いておくと、`ssh web1` のような短い別名で接続でき、設定ミスも減ります。鍵は用途やマシンごとに分け、退職や端末入れ替えのときは古い公開鍵をサーバから外す——こうした鍵の棚卸しまで含めて、SSH の安全運用です。