なぜSSHが「玄関」か
前章で、デスクトップの無いサーバーができた。ここから先、このサーバーには二度とモニタを繋がない。 キーボードも外す。全ての操作は、手元のPC——本編で作ったDebian機でもいいし、会社のWindowsでも、家のMacでもいい——から、ネットワーク越しに行う。
その出入り口がSSH（Secure Shell）だ。離れた場所のサーバーに、暗号化された通路でログインし、コマンドを打ち、ファイルを送る。サーバー管理は、ほぼ全てこの一本の通路の上で行われる。
だから玄関の作りが、そのままサーバーのセキュリティの大半を決める。 インターネットに少しでも面したサーバーは、立ち上げた直後から、世界中の自動化された侵入試行に晒される。ログを見れば、見ず知らずのIPが「root / password」「admin / 123456」と総当たりを仕掛けてくる様子が並ぶ。玄関が弱ければ、いつか開く。逆に、玄関さえ堅ければ、守りの土台はほぼできる。
この章でやるのは二つだけだ。鍵を作ること。そしてパスワードでの出入りを閉じること。 たったこれだけで、総当たり攻撃は事実上無力になる。
第一節 鍵をつくる
パスワードと鍵の違い
総当たり攻撃に対して、パスワードと鍵は強さがまるで違う。
パスワードは「記憶」だ。人が覚えられる長さには限りがあり、短ければ総当たりで破れる。サーバーに「正しい文字列か？」と何度でも試せる以上、いつかは当てられる危険が残る。
鍵は「持ち物」だ。SSH鍵は、対になる二つのファイル——手元に秘匿する秘密鍵と、サーバーに置く公開鍵——でできている。公開鍵で錠前を作り、秘密鍵だけがそれを開ける。秘密鍵は天文学的に長く、総当たりは現実的に不可能だ。「正しい持ち物を持っているか」を問うので、推測では突破できない。 これがパスワードと鍵の決定的な差だ。
鍵を作る
手元のPC（サーバーではなく、操作する側のPC）で、次を実行する。
ssh-keygen -t ed25519 -C "taro@home-server"
-t ed25519 は鍵の方式。今のDebianで標準的に推奨される、短くて強い方式だ。-C の後ろはコメントで、「どの鍵か」を後で見分けるための覚え書きにすぎない（メールアドレスや用途を入れる人が多い）。
保存先を聞かれたらEnterで標準（~/.ssh/id_ed25519）でよい。パスフレーズを聞かれる。ここでは空にせず、必ずパスフレーズを設定する。 これは秘密鍵そのものを暗号化する錠で、万一秘密鍵ファイルを盗まれても、パスフレーズが分からなければ使えない。
できあがるのは二つのファイルだ。
~/.ssh/id_ed25519——秘密鍵。絶対に誰にも渡さない。 サーバーにもアップロードしない~/.ssh/id_ed25519.pub—— 公開鍵。これはサーバーに置く。人に見せても問題ない
公開鍵をサーバーに置く
公開鍵をサーバーに登録する。一発でやってくれるコマンドがある。
ssh-copy-id taro@192.168.1.50
taro は前章で作ったユーザー名、192.168.1.50 は前章で固定したサーバーのIPだ。この一回だけはパスワードを聞かれる。 正しく打つと、公開鍵がサーバーの ~/.ssh/authorized_keys に追記される。次からは鍵で入れる。
初回接続のフィンガープリント
初めて繋ぐとき、こう聞かれる。
The authenticity of host '192.168.1.50' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxx...
Are you sure you want to continue connecting (yes/no)?
これは「この相手は本当に目的のサーバーか」の確認だ。一度 yes と答えると、その指紋（フィンガープリント）が手元の ~/.ssh/known_hosts に記録され、次回から無言で繋がる。家庭内LANの自分のサーバーなら yes でよいが、後日「指紋が変わった」と警告が出たら、それは経路上の改ざんかサーバー再構築のどちらかを意味する。意味を知らずに通すべきではない。
Claudeに聞いてみよう①：接続できないときの診断
サーバーにSSHで繋がりません。手元のPCで
ssh -v taro@192.168.1.50を実行した出力が次です： 〔-v を付けた詳細出力をそのまま貼る〕どこで失敗していますか。鍵・ネットワーク・サーバー側設定のどれが原因か、切り分けの順に教えてください。
接続トラブルは、-v（verbose）を付けた詳細出力を貼るのが最短だ。「鍵を試したが拒否された」「そもそも接続が届いていない」など、出力にはどこで止まったかが必ず書いてある。Claudeはその行を読んで原因を絞り込む。
第二節 玄関を狭める
鍵で入れるようになった。だが今はまだ、パスワードでも入れる状態だ。攻撃者が狙うのもそこだ。パスワードでの出入りを閉じ、root の直接ログインも禁じる。 これで玄関は鍵専用になる。
設定ファイルを置く流儀
サーバーのSSH設定は /etc/ssh/sshd_config にある。本体を直接書き換えるより、今のDebianでは /etc/ssh/sshd_config.d/ に断片ファイルを置く流儀 が推奨される。本体は触らず、自分の変更だけを別ファイルにまとめておけば、後で見返しやすく、消すのも簡単だ。
サーバー側で次を作る。
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PermitRootLogin no
PasswordAuthentication no でパスワード認証を禁止し、鍵だけにする。PermitRootLogin no で root の直接ログインを禁じる（前章で root を空欄にしているなら二重の保険になる）。
締め出し防止の作法
ここが本章で最も大事な一節だ。 設定を間違えると、自分が締め出される。鍵で入れるつもりが、設定ミスで鍵も効かず、パスワードも閉じた——となると、もうSSHでは入れない。次の三つを必ず守る。
一、別のセッションを開いたまま作業する。 設定を変える前に、SSHのウィンドウをもう一枚、繋ぎっぱなしで開いておく。新しい設定で入れなくなっても、この開いたままのセッションから設定を戻せる。これが命綱だ。
二、反映の前に構文チェックする。
sudo sshd -t
何も出なければ構文は正しい。エラーが出たら、反映せずに直す。タイプミス一つでSSHが起動しなくなることがある。
三、再起動ではなくreloadする。
sudo systemctl reload ssh
reload は既存の接続を切らずに設定だけ読み直す。今開いているセッションは生きたまま、新しいルールが効く。反映できたら、別のウィンドウから新規に鍵でログインできるか試す。 入れることを確認してから、最初のセッションを閉じる。
退路を一本残す
それでも締め出された時のために、退路を一本だけ残しておく。自宅のサーバーなら、いざとなればモニタとキーボードを繋いで物理コンソールから直せる。 VPSなら、事業者の管理画面に必ず「Webコンソール」「VNCコンソール」といったネットワーク経由でない入口がある。SSHを閉める前に、自分のサーバーにこの退路があることを確認しておく。鍵を失くしても、ここから入って再登録できる。
Claudeに聞いてみよう②：sshd_config をレビューさせる
SSHを堅くするため、サーバーの
/etc/ssh/sshd_config.d/99-hardening.confに次を書こうとしています： 〔自分が書いた設定をそのまま貼る〕この内容で、私が自分自身を締め出してしまうリスクはありますか。反映前に確認すべきこと、安全な反映手順、もし入れなくなった時の戻し方を教えてください。私は〔自宅サーバー／VPS〕です。
設定変更を**反映する前に**Claudeにレビューさせるのが、この章の肝だ。「締め出しリスクは無いか」を具体的に聞く。自宅かVPSかを伝えると、退路の作り方まで自分の環境に即した答えが返る。
第三節 日々の出入りを快適にする
玄関は堅くなった。次は、毎日の出入りを楽にする。
~/.ssh/config でエイリアスを作る
毎回 ssh taro@192.168.1.50 と打つのは面倒だ。手元のPCの ~/.ssh/config に書いておけば、短い名前で繋げる。
nano ~/.ssh/config
Host home
HostName 192.168.1.50
User taro
IdentityFile ~/.ssh/id_ed25519
これで ssh home だけで繋がる。scp も rsync もこの home という名前を使える。サーバーが複数台、鍵が複数本になっても、ここに並べておけば取り違えない。
ファイルを送り受けする
手元とサーバーの間でファイルをやりとりする方法は二つ覚えておけば足りる。
# 一個のファイルを手元からサーバーへ
scp ./backup.sql home:~/
# ディレクトリごと、差分だけ効率よく同期する
rsync -av ./website/ home:~/website/
scp は単発のコピーに、rsync -av はディレクトリ同期に向く。-a は属性を保ったまま再帰的に、-v は何をしているか表示する、の意味だ。rsync は二度目以降は変わったファイルだけ送るので、大きなディレクトリの更新が速い。
エラーはそのままClaudeへ
接続が切れる、やたら遅い、Permission denied で弾かれる——SSH周りのエラーメッセージは、解釈しようとせずそのままClaudeに貼る。 これは本編第8章「最初のトラブルシューティング」で身につけた作法そのままだ。エラー文には原因の手がかりが必ず含まれる。前章で英語ロケールにしておいたのも、この瞬間のためだ。
Claudeに聞いてみよう③：自分の構成に合った config を書かせる
私の環境を伝えます。SSHで繋ぐサーバーは次の通りです：
- 自宅サーバー：192.168.1.50、ユーザー taro、鍵 ~/.ssh/id_ed25519
- 借りているVPS：〔IP〕、ユーザー〔名〕、鍵〔別の鍵ファイル〕
この構成に合った
~/.ssh/configを書いてください。それぞれに短い別名を付け、どの鍵を使うか明示してください。VPSはポートを〔22以外なら番号〕にしています。
複数台・複数鍵になると、config の手書きは間違いやすい。構成を伝えれば、Claudeが取り違えのない config を組み立てる。返ってきたものを貼り、ssh 別名 で繋がるか一つずつ確かめる。
まとめ
この章でやったこと：
- 手元のPCで
ssh-keygen -t ed25519によりSSH鍵を作った ssh-copy-idで公開鍵をサーバーに登録し、鍵でログインできるようにしたsshd_config.d/にファイルを置き、パスワード認証とroot直接ログインを禁止した- 別セッション・
sshd -t・reloadの三点で、締め出されずに反映した ~/.ssh/configでエイリアスを作り、scp/rsyncでのファイル転送を覚えた
手元に残ったもの：
- 鍵だけで入れる、堅くなったSSHの玄関
- 短い別名で繋げる
~/.ssh/config - いざという時の退路（物理コンソールまたはWebコンソール）の確認
これでサーバーからモニタを外せる。画面の無い、ネットワーク越しに使うサーバー が、ここに完成した。次の第5章「守りの基本」では、玄関の次の層——ファイアウォール、不要なサービスの停止、自動更新、そして総当たりを仕掛けてくる相手をどう遮断するか——を、Claudeと一緒に固めていく。
シリーズ全体はClaudeと一緒に学ぶDebian サーバー編 一覧から辿れる。本編（デスクトップ編）は全章一覧へ。コメント・議論は Facebook グループへ：AISeed — 生物多様性・食料・AIと暮らし