SSH接続の5方式を7軸比較（4方式実測）

遠くのLinux機に入る方法は、パスワードで入るか鍵で入るかの二択ではありません。鍵をどこに置くか、そもそも22番をインターネットに晒すか、辞めた人の権限をどこで切るか。同じ「SSHで入る」でも、到達性・公開面・失効・監査を並べると性格がはっきり割れます。5方式を7軸で比較して、自分の環境ならどれを選ぶかまで絞ります。4方式はコンテナと実tailnetで動かして確認済み、残る1方式は一次資料からの評価です。

読み終えるとできること

• 自分の状況から第一候補を選べます。機械にグローバルIPがあるなら公開鍵認証、NATの内側なら Tailscale 越し、入る人が複数いて出入りがあり、サーバーが Linux なら Tailscale SSH です (Tailscale SSH だけは一次資料での評価)
• ssh -vv の出力を5段階に分けて読めます。どこで止まったかが分かると、鍵の問題とネットワークの問題を取り違えなくなります
• scp と rsync を転送量で使い分けられます。実測では無変更時の再同期が 94 バイトで済みました
• 踏み台を ~/.ssh/config で組めます。ssh -J が踏み台側に -i を渡さないという実測済みの落とし穴も避けられます

シリーズ目次全 7 章

1. 0 SSH接続の5方式を7軸比較（4方式実測） Pillar (現在のページ)
2. 1 ssh -vv で読む接続の5段階を実測 ssh の接続は5段階に分かれます。OpenSSH 10.0p2 同士の実際のログを段階ごとに読み、止まった位置から原因を鍵かネットワークかに切り分けます。
3. 2 SSHの鍵認証でパスワードを消す4手順 SSHの鍵認証は4手順です。ed25519を作り、置き、疎通を確かめ、パスワード認証を止める。順番を間違えたときの締め出しまで実測で示します。
4. 3 scp と rsync を実測で使い分ける 同じ1.2MBを scp と rsync で3回ずつ送って比較。無変更の再同期は94バイト、1ファイル変更時は200,185バイトでした。
5. 4 ssh -J と config の差を踏み台で実測 同じ鍵で踏み台に入れるのに ssh -J だと拒否されます。-i が踏み台へ渡らないためで、~/.ssh/config なら通る。実測ログで示します。
6. 5 Tailscale越しのSSHとMTU 1280 Tailscaleが解くのは到達性だけです。実tailnetの経路MTUは1280ちょうど。post-quantum鍵交換がこの境界に当たる条件を示します。
7. 6 Tailscale SSHと鍵ゼロ運用の3制約 Tailscale SSH は authorized_keys を持ちません。代わりに対応OS・ポリシー必須・tailnet内限定の3制約が付きます。

手元のノートPCから、別の場所にあるLinux機に入って作業したい。やることは決まっています。ssh で入り、ファイルを送り、コマンドを流すだけです。

それでも方法は1つに決まりません。パスワードで入るのか鍵で入るのか、22番をインターネットに晒すのか踏み台を1台だけ晒すのかそもそも晒さないのか、そして人が辞めたときにどこを触れば入れなくなるのか。決めることが3つあって、どれも後から変えると全台に手を入れる羽目になります。

機械にグローバルIPがあって、入る人が自分1人なら、公開鍵認証で足ります。 インターネットに22番を晒すことになりますが、パスワード認証を止めておけばパスワードの総当たりは効きません。

そこから外れる理由は3つあり、それぞれ行き先が決まっています。機械がNATの内側に居て外から届かないなら、経路だけを VPN に任せる Tailscale 越し (D) へ進みます。22番をインターネットに出すこと自体が許されない場合も D で、サーバーが全部 Linux なら Tailscale SSH (E) も候補に残ります。入る人が複数いて出入りがあるなら、人を外す操作が1箇所で済む E が第一候補です。混ざった Windows や Synology は D で、Tailscale を入れられない機械は踏み台経由 (C) で受けます。

揃える課題

比較が成立するように、5方式に同じ仕事をさせます。

• 手元のクライアントから、別のLinux機に ssh で入って1コマンド実行する
• 1.2MB (2ファイル) のディレクトリをその機械に送る
• 同じ操作を、人が増えても台数が増えても回せるようにする

同じ仕事を基準に置かないと、到達性が優れている方式と鍵の管理が楽な方式を同じ物差しで並べられず、比較が「どちらが好みか」に化けてしまいます。

ただし実際に動かした範囲は方式ごとに違います。入って1コマンド実行するところは A〜C をラボで実行し、D は実際のtailnet (Tailscale でつないだ自分の端末の集まり) 越しに、接続が認証の段階まで届くことを確かめました。ファイル転送はラボの踏み台経由、つまり鍵認証の B と踏み台の C を組み合わせた経路で測っていて、D の経路では転送量を測っていません。E は一次資料からの評価です。3つ目の「人と台数が増えたとき」は、どの方式も各方式の仕組みから評価しています。

5つの方式

D と E は名前が似ていますが、やっていることは別です。D は経路だけを変えた B か C で、authorized_keys は今までどおり自分で配り続けます。 E ではその authorized_keys 自体を持たなくなり、認可 (誰がどの機械にどのユーザー名で入ってよいかの決定) がtailnet側のポリシーに移ります。人を足す操作も外す操作も、機械に触らずポリシーだけで終わります。

7軸で見ると

記号は ◎ が強い、○ が条件付き、△ が手間が残る、✗ が弱いか不可です。性格が割れるのは到達性・鍵の配布・失効の3列です。残りの4列は方式間の差が小さく、効くのは特定の状況に当たったときです。公開面は22番を外へ出せないとき、対応環境は Windows や Synology が混ざるときに、選択を左右します。

軸の定義

表の列に並べた7つが、その物差しです。

• 到達性 — 機械がNATの内側や動的IPに居ても届くか。グローバルIPを前提にする方式はここで落ちます
• 公開面 — インターネットに向けて22番を開けるか。開けた数がそのまま攻撃対象になります
• 鍵の配布 — 人数 × 台数が増えたときに、秘密鍵と公開鍵をどう行き渡らせるか
• 失効 — 端末を失くした、人が抜けた。そのときどこを1箇所触れば入れなくなるか
• 監査 — 誰がいつどの機械に入ったかの記録が、機械の外に残るか
• 対応環境 — サーバー側のOSに制約があるか
• 既存sshdへの侵襲 — 今動いている sshd_config や authorized_keys を書き換える必要があるか

失効と監査は、人が1人のうちは差が出ません。効いてくるのは2人目が増えた日で、しかもそのときには既に鍵が何台にも配られているので、後から方式を変える手間はそこから増え続けます。

自分ならどれか

表を問いの順に並べ直すと、次の流れになります。

A を選ぶ理由は、実質「今すぐ1回だけ入りたい」しかありません。パスワードは共有した瞬間に誰が入ったのか区別できなくなり、変更するには全員に配り直す必要があるので、入った最初の日に B へ上げるのが前提の方式として扱っています。

検証状態

2026-09-26 の時点で動かしたのは4方式です。コンテナ3台で組んだラボと、実際に運用しているtailnetの2ノード間を使いました。

E が一次資料どまりなのは権限の話で、tailnetのポリシーを書き換えられる立場でないと有効化まで到達できません。実行でき次第、この表のセルを上げます。

読む順

1章と3章は方式によらず共通する土台で、2章と4〜6章が方式 B〜E を1つずつ扱います。急いでいるなら2章と5章だけでも実用になりますが、ssh が途中で固まったときに何を疑えばいいかは1章にしか書いていないので、詰まったら戻ってきてください。

1. ssh -vv で読む接続の5段階を実測 — 全方式に共通する土台。どこで止まったかを読めるようにします
2. SSHの鍵認証でパスワードを消す4手順 — 方式AからBへ
3. scp と rsync を実測で使い分ける — どの方式でも同じように乗るファイル転送
4. ssh -J と config の差を踏み台で実測 — 方式C
5. Tailscale越しのSSHとMTU 1280 — 方式D
6. Tailscale SSHと鍵ゼロ運用の3制約 — 方式E