SSH接続の設定方法｜リモートアクセスの基本 - TsukuLab | ツクラボ

SSH接続とは何か

SSHはSecure Shellの略で、ネットワーク越しに離れたコンピューターへ安全に接続するためのプロトコルです。
単にログインするだけでなく、リモートでコマンドを実行したり、ファイルを転送したりできるのが特徴で、通信内容は暗号化されます。
平文でやり取りするTelnetと違って、途中で内容をのぞき見されたり、書き換えられたりしにくい構造になっているため、Linuxサーバー管理の基本として定着しています。

SSHサーバーは通常、TCP 22番ポートで待ち受けます。
ここでいう「ローカル」は今あなたが操作しているPC、「リモート」は接続先のLinuxサーバーやRaspberry Piです。
たとえば手元のWindowsやmacOSから、自宅の小型サーバーやクラウド上の仮想マシンへ入って設定を変える、ログを見る、再起動するといった作業は、SSHの守備範囲そのものです。
RDPやVNCのようなリモートデスクトップはGUIを遠隔操作する道具ですが、サーバー管理では文字ベースの操作で十分な場面が多く、SSHのほうが通信量も少なく、端末さえあれば扱える場面が多いです。
筆者の環境でも日常的にSFTPやポートフォワーディングを併用していて、SSHひとつで管理、転送、トンネリングまでまとめて扱える点に実用上の強みを感じています。

仕組みは、まず「あなたのPCが接続を申し込む」、次に「接続先サーバーが自分の身元を示す」、そのうえで「あなたが利用者として認証される」という順番で捉えると整理しやすくなります。
初心者が混同しやすいのは、ユーザー認証用の鍵とホスト鍵が別物だという点です。
ユーザー認証は「あなたがそのユーザー本人か」を確かめるもので、パスワード認証か公開鍵認証を使います。
一方のホスト鍵は「今つながっている相手が、本当にそのサーバーか」を確かめるための鍵です。
初回接続時に「この接続先を信頼しますか」といった確認が出るのは、このホスト鍵を登録する場面です。

図で表すと、関係は次のようになります。

[ローカルPC]
図の説明文を2文に分け、各要素（ローカル、リモート、公開鍵/ホスト鍵）の役割が読み取りやすくしました。
  └─ ssh コマンドで接続する
          │  暗号化された通信
          ▼
[リモートサーバー]
  ├─ ホスト鍵を持つ（サーバー自身の身元証明）
  └─ authorized_keys に公開鍵を登録する（利用者認証）

パスワード認証は、ユーザー名とパスワードだけで入れるので最初の確認には向いています。
ただし、継続運用では公開鍵認証のほうが堅実です。
公開鍵認証では、ローカル側に秘密鍵、サーバー側に公開鍵を置き、サーバーは authorized_keys に登録された公開鍵と照合して認証します。
LinuxやmacOSでは ssh-copy-id を使うと公開鍵の配布と authorized_keys 周りの設定をまとめて処理でき、権限ミスを減らせます。.ssh ディレクトリを700、authorized_keys を600にする手順がよく出てくるのは、そこが崩れると鍵を置いても認証が通らないからです。

公開鍵認証は「鍵ファイルを持っている人だけが署名できる」という前提で成り立つので、秘密鍵の管理が中心になります。
ここでパスフレーズ付きの秘密鍵を使うと、鍵ファイル単体が流出してもすぐには使えません。
筆者は普段、秘密鍵にパスフレーズを付けたうえでssh-agentに読み込ませる運用を取っています。
これなら作業のたびに毎回入力する必要がなく、ログインやGit操作が続く日でも負担が増えません。
安全性と作業速度のバランスが取りやすい組み合わせです。

TIP

SSHでは「サーバーの身元確認」と「利用者の本人確認」が別レイヤーで動いています。
初回接続時のホスト鍵確認と、公開鍵認証で使う秘密鍵は役割が違うと押さえると、警告メッセージの意味が読み取りやすくなります。

Windowsでもこの考え方は同じです。
Windows 10以降のクライアントOSやWindows Server 2019以降ではOpenSSH for Windowsが標準搭載系として扱われます。
Windows 用 OpenSSH Server の使い方を始めるWindows 用 OpenSSH Server の使い方を始めるでも基本の導入手順が整理されています。
いまは「SSHはLinuxだけのもの」という認識ではなく、WindowsからLinuxへ入る道具としても、Windows自身をSSHサーバーとして扱う手段としても現実的な選択肢です。

OpenSSHの最新事情

SSH入門で注意したいのは、古い記事の説明がそのまま現在のOpenSSHに当てはまらないことです。
近年は古いアルゴリズムの整理が進んでいて、2025年のOpenSSH Release NotesでもDSAサポート削除の流れが明確に示されています。
ひと昔前の解説ではRSAや ssh-rsa を前提にした例を多く見かけますが、今の入門ではその説明をそのまま信じるとつまずきます。

これから鍵を新規に作るなら、初学者は Ed25519を基本にする という整理で十分です。
Ed25519は近年の推奨鍵種として扱われることが多く、鍵の扱いも軽く、現在のOpenSSHとの相性も良好です。ssh-keygen -t ed25519 の形で生成でき、OpenSSH環境では自然な第一候補になります。
古いネットワーク機器やレガシーなサーバーを相手にしていて、Ed25519を受け付けない場合だけRSAを検討する、という順番のほうが実務に沿っています。
その場合も、昔の短い鍵長の説明ではなく、4096bitのRSA鍵を例にする記事が現在は主流です。
もうひとつ知っておくと役立つのが、鍵交換の内部も更新され続けていることです。
OpenSSH の最近のリリースでは、量子耐性を意識したアルゴリズムの試験的サポートや検討が報告されています（詳細は OpenSSH Release Notes を参照してください）。
実運用での採用状況はバージョンによるため、導入前にお使いの OpenSSH のバージョンと公式リリースノートを確認することを推奨します。

SSH接続に必要なもの

SSHで入る前に、手元でそろっている情報は意外と少数です。
最低限必要なのは、接続先のIPアドレスまたはホスト名、ログインに使うユーザー名、認証方法の3つです。
認証方法は、初回確認ならパスワード認証、継続運用なら公開鍵認証という並びで考えると整理できます。
公開鍵認証を使うなら、クライアント側に秘密鍵、サーバー側に公開鍵を置き、authorized_keys で受け入れる形になります。
Linux系では ssh-copy-id が使えると公開鍵配布と権限設定をまとめて進められるので、手作業で貼り付けたときに起きやすい authorized_keys まわりのミスを減らせます。

接続先の情報が合っていても、サーバー側の受け口が閉じているとSSHは始まりません。
接続先で sshd が動いていること、通常は TCP 22番ポート で待ち受けていること、そしてファイアウォールでそのポートが通ることが前提です。
自宅LANの外から入るなら、ルーター側のポート転送まで含めて通信経路が完成している必要があります。
筆者の経験では、最初のつまずきはコマンドの書き方より、ユーザー名の思い込みとクラウド側のポート未開放に集中します。ubuntu で入るつもりが実際は ec2-user だった、あるいはVMは起動しているのにセキュリティグループで22番が閉じたままだった、という流れは本当に多いです。
筆者の経験では、最初のつまずきはコマンドの書き方よりもユーザー名の思い込みとクラウド側のポート未開放に集中します。
例えば ubuntu で入るつもりが実際は ec2-user だったり、VMは起動中でもセキュリティグループで22番が閉じている場合が多く見られます。

クライアントOS別の準備

クライアント側は、いまの主要OSなら追加ソフトなしで始められることが増えました。
Windows 10以降ではOpenSSHクライアントが標準搭載系として扱われていて、『PowerShell』やWindows Terminalから ssh コマンドをそのまま実行できます。
macOSと多くのLinuxでも ssh は標準で入っているので、まずはターミナルを開いて ssh と打てるかを見るだけで準備状況が分かります。
Windowsで最新の扱いを確認したいときは、Microsoft LearnのWindows 用 OpenSSH Server の使い方を始めるMicrosoft LearnのWindows 用 OpenSSH Server の使い方を始めるがいちばん筋のよい確認先です。

公開鍵認証まで進める場合は、クライアント側で鍵ペアを用意します。
いま作るなら ssh-keygen -t ed25519 を基本にすると、古い説明を避けながら進められます。
さらに秘密鍵へパスフレーズを付けても、ssh-agentへ登録しておけば、作業を始めるたびに1回通すだけで、その後の接続で毎回入力せずに済みます。
筆者もこの形で使っていますが、鍵にパスフレーズを付けた運用は身構えるほど重くありません。
ログインのたびに入力する運用と比べると、普段の作業はだいぶ落ち着きます。

Windowsでは『PuTTY』や『Tera Term』を使う方法もありますが、これから覚えるならまず標準の ssh コマンドを基準にしたほうが、macOSやLinuxへ移ったときも知識がそのままつながります。
複数の鍵を持っている環境では、~/.ssh/config や %USERPROFILE%\.ssh\config に IdentityFile と IdentitiesOnly yes を書いておくと、関係ない鍵を順番に試して認証失敗回数を使い切る事故を避けやすくなります。

Windows 用 OpenSSH Server の使い方を始める

Windows 用 OpenSSH Client および Server を使用してリモートコンピューターをインストールしてリモートコンピューターに接続する方法について説明します。

learn.microsoft.com

サーバー側の稼働確認とポート開放

サーバー側では、まずSSHサーバーが起動しているかを確認します。
LinuxならOpenSSH Serverを入れて sshd を有効化する流れが基本です。
Debian系では sudo apt install -y openssh-server、RHEL系では sudo dnf install -y openssh-server で導入し、systemctl status ssh または systemctl status sshd で状態を見ます。
サービス名は系統で異なりますが、確認したいことは同じで、「SSHサーバーが起動中か」「OS起動時に自動起動するか」の2点です。

Windows Server 2025ではOpenSSHが既定でインストールされる構成になっているので、Linuxほど準備は長くありません。
Server Managerから有効化する方法に加えて、管理者権限の『PowerShell』で Start-Service sshd、Set-Service -Name sshd -StartupType Automatic として起動と自動起動を設定できます。
日本語環境ではGUI側で意図通り進まない事例もあるため、PowerShellの手順を知っていると切り分けが速くなります。

通信経路の確認も同じくらい大切です。
サーバーのローカルファイアウォール、クラウドのセキュリティグループやネットワークACL、インターネット越しならルーターのポート転送まで、22番へ到達できる必要があります。
ここが閉じていると、ユーザー名や鍵が正しくても接続できません。
Windowsクライアントなら Test-NetConnection -ComputerName <host> -Port 22、macOSやLinuxなら nc -vz <host> 22 で、そもそもTCP 22へ届くかを先に見ておくと、認証の問題なのかネットワークの問題なのかを切り分けやすくなります。

NOTE

SSHで入れないとき、先に確認したい順番は「22番ポートへ届くか」「sshd が起動しているか」「ユーザー名が合っているか」です。
認証設定を疑うのは、その3つが通ってからのほうが手戻りが減ります。

クラウド/VPSでの初期ユーザー名の例

クラウドやVPSでは、OSイメージごとに初期ユーザー名が決まっていることがあります。
ここを取り違えると、鍵もIPアドレスも正しいのに入れません。
よく見る例としては、Ubuntu系イメージなら ubuntu、Amazon EC2の一部Linuxイメージなら ec2-user、クラウド提供元やイメージによっては cloud-user が使われます。
SSH接続コマンドは ssh ユーザー名@ホスト名 なので、この1語が違うだけで最初から弾かれます。

筆者の現場感でも、初手で詰まる原因はこのユーザー名違いが本当に多いです。
クラウドの画面でインスタンスが「起動中」と見えていると、ついネットワークや鍵ばかり疑いたくなりますが、実際には root では入れず、用意された初期ユーザーで接続してから sudo を使う構成が普通です。
特にクラウドでは、公開鍵は投入済みなのにログイン名だけがずれていて、結果として「Permission denied」が続く場面をよく見ます。

この段階で手元に必要なのは次の情報です。IPアドレスまたはホスト名、正しい初期ユーザー名、そのイメージで使う認証方法です。
クラウドの多くは最初から公開鍵認証前提なので、秘密鍵の置き場所も合わせて把握しておくと流れが止まりません。
初回接続ではホスト鍵確認のプロンプトが出ることもありますが、それは接続先サーバーの身元確認の段階で、ユーザー認証とは別の確認です。
ここまで切り分けて見ると、SSH接続前の準備は「接続先情報」「ログイン情報」「通信経路」の3層に分けて整理できます。

まずはパスワード認証で接続する手順

基本コマンド例

SSHの最短ルートは、まずターミナルで1行打って接続してみることです。
基本構文は ssh ユーザー名@ホスト名 で、たとえばローカルネットワーク上のRaspberry Piに入るなら ssh pi@192.168.1.10 です。
接続先がIPアドレスでも、DNSで引けるホスト名でも書き方は同じです。

Windowsでは『PowerShell』やWindows Terminalを開いて、そのまま ssh user@host を実行できます。
macOSとLinuxでもターミナルで同じコマンドを使います。
ここはOSごとの差を意識しなくてよく、まず同じ形で試せるのがSSHのよいところです。
Microsoft LearnのWindows 用 OpenSSH Server の使い方を始めるMicrosoft LearnのWindows 用 OpenSSH Server の使い方を始めるでも、WindowsでOpenSSHをそのまま扱える流れが案内されています。

SSHサーバーが標準のTCP 22番ではなく別ポートで待ち受けているなら、-p を付けて ssh -p 2222 user@host のように指定します。-p はポート番号を明示するオプションで、ホスト名の後ろにコロンを書く形式ではありません。
WebのURLと混同しやすいところですが、SSHではこの書き方が基本です。

パスワード認証が有効なサーバーであれば、このあとパスワード入力が求められます。
入力中は画面に何も表示されませんが、止まっているわけではありません。
筆者もSSHを触り始めたころは、文字が出ないので入力できていないのかと戸惑いましたが、実際にはそのまま打ってEnterで通ります。
まずはここで1回ログインできると、接続先のIP、ユーザー名、ポート番号、認証方法のどこに問題があるのかが見えやすくなります。

初回のホスト鍵確認の意味

初めてそのサーバーへつなぐと、Are you sure you want to continue connecting (yes/no/[fingerprint])? と表示されることがあります。
これは「その接続先が本当に想定している相手か」をSSHクライアントが確認している場面です。
ここで見ているのはログイン用パスワードではなく、サーバー自身が持っている公開鍵の指紋です。

表示される fingerprint は、接続先サーバーのホスト鍵を短く識別するための値です。
運用中のサーバーなら、事前に控えてある指紋と一致するかを突き合わせてから yes を入力します。
一致していれば、そのサーバーの情報が known_hosts に保存され、次回以降は同じ鍵である限りこの確認は出ません。
DigitalOceanの『SSHを使用してリモートサーバーに接続する方法』でも、初回接続時にこの確認が入る流れが紹介されています。

この警告が出る理由をひと言でいえば、なりすまし対策です。
もしネットワークの途中で別の相手に誘導されていた場合、ここで想定外の指紋が見えるので気づけます。
筆者はこの初回表示のフィンガープリントを運用記録に残すようにしています。
あとからサーバーを再構築したときや、意図しない鍵変更が起きたときに差分を追いやすく、単なる初回確認で終わらせないほうが後々の切り分けが楽になります。

逆に、以前つないだことがある相手なのに突然ホスト鍵が変わったときは、SSHが警告を強く出します。
これは故障ではなく、過去に記録した相手と今見えている相手が違うという通知です。
再構築直後なら説明がつきますが、心当たりがない変更は、そのまま受け入れずに記録と照合して考えるのがSSHの正しい流れです。

SSHを使用してリモートサーバーに接続する方法｜ DigitalOcean

SSHは、リモートLinuxサーバーの管理に使用される重要なツールです。このガイドでは、このユーティリティの基本的な使用方法とSSH環境の設定方法ついて説明します。

digitalocean.com

切断と簡易トラブル確認

接続できたあとは、抜け方もセットで覚えておくと迷いません。
SSHセッションの終了は exit です。
リモート側のシェルで exit と入力してEnterを押せば、ローカルのターミナルへ戻ります。
ウィンドウを閉じても切断はできますが、今どこにいるのかを意識する意味でも、まずは exit を使うほうが混乱が少なくなります。

つながらないときは、いきなり設定ファイルを掘るより、接続のどこで止まっているかを短いコマンドで見たほうが早く進みます。
SSH自体の詳細を見たいなら ssh -v user@host として、-v でデバッグ出力を付けます。
名前解決で止まっているのか、ポートへ届いていないのか、認証で弾かれているのかが行単位で見えてきます。

ネットワーク到達性だけを先に切り分けるなら、Windowsでは Test-NetConnection host -Port 22、macOSやLinuxでは nc -vz host 22 が手早いです。
ここでポートへ届かなければ、パスワードやユーザー名を見直しても前に進みません。
反対にポートが開いていて ssh -v で認証段階まで進んでいるなら、問題は接続先情報ではなく認証側に寄っています。
SSHはエラー文が少し無愛想ですが、確認する順番を固定すると、詰まる場所は思ったより絞れます。

公開鍵認証を設定する手順

鍵ペアの作成

公開鍵認証では、クライアント側で「秘密鍵」と「公開鍵」のペアを作り、公開鍵だけをサーバーへ登録します。
サーバーに置くのは公開鍵で、秘密鍵は手元から出さないという役割分担が前提です。
パスワード認証より準備は増えますが、総当たり攻撃に強い運用へ切り替えられるのが公開鍵認証の大きな利点です。

いまから新規に作るなら、筆者は Ed25519 をまず選びます。Ed25519 は 256bit 相当の鍵として扱われることが多く、短い鍵長で扱いやすく、OpenSSHでも標準的な選択肢です。
古い接続先との互換性を優先する場面では RSA 4096bit も選べますが、特別な事情がなければ Ed25519 で困る場面は多くありません。

作成コマンドは次の形です。

ssh-keygen -t ed25519 -C "任意のラベル"

-t は鍵種の指定、-C は鍵に付けるコメントです。
コメントにはメールアドレスでも用途名でも構いません。
保存先を変えたいときは -f でファイル名を明示できます。

互換性の都合でRSAを使うなら、次のように鍵長を付けます。

ssh-keygen -t rsa -b 4096 -C "任意のラベル"

生成時にはパスフレーズの入力も求められます。
ここは空にせず、鍵そのものにロックを掛けるつもりで設定しておくと、秘密鍵ファイルが流出したときの踏み台になりにくくなります。
筆者も最初は「毎回入力するのは面倒では」と感じましたが、後述する ssh-agent を使うと作業セッション中の負担はぐっと軽くなります。
まずはパスフレーズ付きで作る前提で覚えるほうが、安全な運用に乗せやすいです。

ssh-copy-id の使い方

LinuxやmacOSなら、公開鍵の配布は ssh-copy-id が最短です。
次の1行で、ローカルの公開鍵をサーバー側の ~/.ssh/authorized_keys に追記し、必要な権限調整までまとめて進められます。

ssh-copy-id user@host

鍵ファイルを明示したいときは、-i を付けて公開鍵を指定できます。

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

このコマンドの便利なところは、単にファイルを送るだけでなく、サーバー側の authorized_keys へ追記する流れを自動化してくれる点です。
手作業だと追記位置や権限でつまずきやすいので、まずはこの方法を選ぶと失敗が減ります。
公開鍵を置いたあとは、実際にその秘密鍵で入れるかを次のように確かめます。

ssh -i ~/.ssh/id_ed25519 user@host

-i は使う秘密鍵の指定です。
複数鍵を持っている環境では、どの鍵で試しているのかを固定できるので切り分けが速くなります。
接続に成功したら、すぐにパスワード認証を切らず、今のログインを維持したまま別セッションで公開鍵ログインを試す流れが安全です。
筆者もサーバー設定を切り替えるときは、この「元のセッションを残したまま検証する」手順を崩さないようにしています。
1本しか入れない状態で設定を変えると、戻る手段を自分で消してしまうからです。

Windowsでの手動登録

WindowsではOpenSSHクライアントをそのまま使える環境が増えましたが、ssh-copy-id が手元にないことがあります。
その場合は、公開鍵ファイルをサーバーへ渡して、サーバー側で authorized_keys に追記します。
Microsoft LearnのWindows 用 OpenSSH Server の使い方を始めるMicrosoft LearnのWindows 用 OpenSSH Server の使い方を始めるでも、WindowsでOpenSSHを扱う前提が整理されています。

手元で作成した id_ed25519.pub をサーバーへコピーしたあと、サーバー側で次を実行します。

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat 公開鍵ファイル名.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

mkdir -p は .ssh ディレクトリがなければ作るためのものです。cat ... >> は公開鍵を authorized_keys の末尾へ追記しています。
上書きではなく追記なので、既存の鍵を消さずに追加できます。
複数端末から入る運用では、この「1鍵1行で足していく」形が基本です。

手動登録で意外と多いのが、authorized_keys の書式崩れです。
公開鍵は1行で完結する形式なので、改行が抜けたり、行頭や行末に余計な空白が入ったりすると認証が通りません。
筆者は追記前に公開鍵の末尾改行を確認し、複数の鍵を必ず行単位で管理しています。
見た目には些細でも、ここが崩れると Permission denied (publickey) だけが返ってきて、原因が見えにくくなります。

権限とauthorized_keysの役割

authorized_keys は、そのユーザーとしてログインを許可する公開鍵の一覧です。
SSHサーバーは接続時にここを見て、クライアントが持つ秘密鍵と対応する公開鍵が登録済みかを確認しています。
つまり、秘密鍵で署名し、サーバー側は authorized_keys にある公開鍵でそれを検証する、という流れです。

この仕組みが正しく働くには、ファイルの場所だけでなく権限も整っている必要があります。
実務でまず押さえる値は .ssh ディレクトリが 700、authorized_keys が 600 です。
これより緩い権限だと、OpenSSHが安全でないと判断して鍵を読まないことがあります。
つながらないときに設定内容ばかり見直して、実は権限が原因だったというのはよくある詰まり方です。

WARNING

公開鍵はサーバーへ置いて構いませんが、秘密鍵は手元だけで保持します。サーバーへ送る対象を取り違えると、公開鍵認証の前提そのものが崩れます。

接続確認では、公開鍵を置いた直後に ssh -i ~/.ssh/id_ed25519 user@host で試し、成功したらそのあとでサーバー側の認証設定を見直す順番が安定します。
公開鍵認証へ移行した直後は、パスワード認証を残したまま別セッションで再ログインできることを確認してから切り替えると、作業中の締め出しを避けられます。

ssh-agentの活用

パスフレーズ付きの秘密鍵は安全ですが、接続のたびに毎回入力するのは煩雑です。
ここで役立つのが ssh-agent と ssh-add です。
秘密鍵をメモリ上に保持して、署名処理を代理してくれるので、最初に登録したあとは同じ作業セッション内で入力を繰り返さずに済みます。

Unix系では次の流れで使えます。

eval "$(ssh-agent)"
ssh-add ~/.ssh/id_ed25519


鍵を複数持つ環境では、エージェントに載った鍵が多すぎて別の鍵から順に試され、認証失敗回数を消費してしまうことがあります。その場合は `-i` で接続鍵を明示するか、`~/.ssh/config` に `IdentityFile` と `IdentitiesOnly yes` を組み合わせて、対象ホストごとに使う鍵を絞ると挙動が安定します。公開鍵認証は「鍵を作って終わり」ではなく、どの鍵をどこに使うかを整理すると途端に扱いやすくなります。

## 接続を楽にするSSH設定ファイルの使い方

SSHの長いコマンドは、毎回その場で打つより `~/.ssh/config` に寄せたほうが安定します。`~/.ssh/config` はSSHクライアントのユーザー別設定ファイルで、接続先ごとの省略設定をまとめておく場所です。ここにホスト名、ユーザー名、ポート番号、使う秘密鍵を定義しておけば、毎回 `ssh -i 鍵ファイル -p ポート ユーザー名@ホスト名` と書かなくて済みます。筆者は普段、10台以上の接続先を別名で管理していますが、`Host` に短いエイリアスを付けてからは入力ミスと鍵の取り違えが目に見えて減りました。接続先が増えるほど、この差が効いてきます。

### 基本ディレクティブの例

最初に押さえたいのは、`Host` `HostName` `User` `Port` `IdentityFile` の5つです。`Host` は自分が呼び出すための別名、`HostName` は実際の接続先、`User` はログインユーザー、`Port` は接続ポート、`IdentityFile` は使う秘密鍵を指します。

たとえば次のように書けます。

```sshconfig
Host web
  HostName example.com # (設定1)
  User ubuntu
  Port 22
  IdentityFile ~/.ssh/id_ed25519 # (鍵1)

この設定を入れると、以後は ssh web だけで接続できます。
標準ポートはTCP 22なので、ポートを変えていないサーバーなら Port 22 を明示しておくと設定を見返したときに意図が残ります。
鍵を接続先ごとに分けているなら、IdentityFile を書いておくことで「このサーバーにはこの鍵」という対応関係が設定ファイル上で読める形になります。

鍵を複数扱う環境では、エージェントに載っている別の鍵まで順に試されてしまうことがあります。
そういう場面では IdentitiesOnly yes を併記すると、指定した鍵だけを使わせられます。

Host web
  HostName example.com # (設定2)
  User ubuntu
  Port 22
  IdentityFile ~/.ssh/id_ed25519 # (鍵2)
  IdentitiesOnly yes

config には接続先一覧だけでなく、運用上の迷いを消す役割もあります。
コマンド1本を短くするだけでなく、誰のアカウントで、どの鍵で、どの宛先へ入るのかを固定できる点が実務では効きます。

TIP

Unix系では ~/.ssh を 700 にし、config は必要最小限の権限にしておくことを推奨します。config は環境によって 600 または 644 の場合があるため、最小権限（例: 600）を基準に、動作確認のうえで緩めるかどうか判断してください。
秘密鍵は 600 に揃えるのが無難です。

複数ホスト・踏み台の指定

~/.ssh/config の真価が出るのは、接続先が1台ではなくなってからです。
Webサーバー、DBサーバー、検証機、Raspberry Pi というように複数ホストを持つと、毎回完全修飾の接続コマンドを打つ運用はすぐ破綻します。web-prod db-stg pi-lab のように別名を付けておくと、接続先の切り替えが速くなり、どの鍵を使うかも設定側で固定できます。

たとえば複数台をこう管理できます。

Host web-prod
  HostName web01.example.com
この設定を入れると、以後は `ssh web` だけで接続できます。ポートを変更していないサーバーでは `Port 22` を明示しておくと、設定を見返したときに意図が分かりやすくなります。
  IdentityFile ~/.ssh/id_ed25519_web
  IdentitiesOnly yes

Host db-stg
  HostName db-stg.example.com
  User ec2-user
  IdentityFile ~/.ssh/id_ed25519_db
  IdentitiesOnly yes

この形なら ssh web-prod や ssh db-stg で接続でき、鍵を手で切り替える必要もありません。
筆者の環境でも、接続先が増えるほど -i の打ち分けより Host のエイリアス管理のほうが事故が少なくなりました。
社内や自宅ラボでよくあるのが、外から直接入れず踏み台サーバーを経由する構成です。
OpenSSHでは ProxyJump が使え、コマンドラインの -J と同じ内容を設定ファイルに埋め込めます。
OpenSSH Release Notesで整理されている通り、ProxyJump はOpenSSH 7.3以降で使える機能です。

Host bastion HostName jump.example.com IdentityFile ~/.ssh/id_ed25519_jump IdentitiesOnly yes Host internal-app HostName 10.0.1.15 User ubuntu この設定では、internal-app に接続するときに踏み台 bastion 経由で内部ホストへ到達します。
踏み台が複数ある場合はカンマ区切りで指定でき、長い接続経路は設定ファイル上でエイリアス化すると管理が楽になります。
IdentitiesOnly yes ProxyJump bastion


これで `ssh internal-app` と打つだけで、実際には踏み台 `bastion` を経由して内部ホストへ接続します。CLIで毎回 `ssh -J ubuntu@jump.example.com ubuntu@10.0.1.15` と書くより、設定の見通しがよくなります。踏み台が複数段ある構成でも `ProxyJump` はカンマ区切りで指定できます。長い接続経路を覚えるのではなく、名前を付けて再利用するほうが、日常運用では手堅いです。

### Windowsでのconfig配置

Windowsでも考え方は同じです。OpenSSHクライアントは %USERPROFILE%\\.ssh\\config を読み込みます。Microsoft LearnのWindows 用 OpenSSH Server の使い方を始める[Microsoft LearnのWindows 用 OpenSSH Server の使い方を始める](https://learn.microsoft.com/ja-jp/windows-server/administration/openssh/openssh_install_firstuse)でも、Windows環境でOpenSSHを前提にした設定手順が整理されています。PowerShellやWindows Terminalから `ssh` を使っているなら、このファイルにUnix系とほぼ同じ書式で書けます。

たとえば保存先は次のイメージです。
保存先の例を示します。Windows環境では `C:\Users\ユーザー名\.ssh\config` のようなパスになりますが、ファイルの中身は Unix 系とほぼ同じ書式で記述できます。
```text
C:\Users\ユーザー名\.ssh\config

中身はUnix系と同じです。

Host web
  HostName example.com # (設定3)
  User ubuntu
  Port 22
  IdentityFile ~/.ssh/id_ed25519 # (鍵3)
  IdentitiesOnly yes

Windowsでは %USERPROFILE%\.ssh\config という表記で覚えておくと場所が分かりやすく、設定ファイル内では ~/.ssh/id_ed25519 のようなホーム基準の書き方もそのまま使えます。
普段は『PuTTY』や『Tera Term』を使っていても、OpenSSHベースに寄せるとLinuxやmacOSと設定の持ち方をそろえられます。
接続先の別名や鍵の対応関係をOSごとに頭で持ち替えなくて済むので、複数環境を行き来する運用ではこの統一感が効きます。

PuTTY: a free SSH and Telnet client

chiark.greenend.org.uk

よくあるエラーと対処法

Permission denied対処

Permission denied (publickey) や Permission denied (publickey,password) は、鍵そのものより先に接続先の前提がずれているケースが多いです。
筆者は切り分けの順番をいつも次のようにしています。
到達性 → サービス稼働 → 認証（鍵と権限）。
最初から鍵の中身を疑うより、まず本当にそのホスト、そのユーザー、そのポートに向かっているかを見るほうが早く詰められます。

公開鍵認証で詰まりやすいのは、ユーザー名の取り違えです。
たとえば ubuntu で入るサーバーに ec2-user や root で接続していると、正しい鍵を持っていても通りません。
クラウドやイメージごとに初期ユーザー名が違うため、接続コマンドや ~/.ssh/config の User を見直すだけで解消することがあります。-i を付け忘れて別の秘密鍵を試しているケースも定番で、複数鍵を持っている環境では特に起きやすいです。

サーバー側では authorized_keys の置き場所と内容も見ます。
公開鍵をコピーしたつもりでも、末尾の改行が崩れていたり、貼り付け途中で1行が分断されていたりすると認証に失敗します。
さらに権限が緩すぎると sshd が安全でないファイルとして無視します。
Linux 系ではホーム配下の ~/.ssh は 700、authorized_keys は 600 にそろえるのが基本です。
公開鍵の中身が正しくても、ここが崩れているだけで Permission denied になります。
公開鍵認証で詰まる典型的な原因は「ユーザー名の取り違え」です。
たとえば ubuntu で入る想定のサーバーに誤って ec2-user や root で接続しようとすると、正しい鍵を持っていても弾かれます。
まずは接続先の初期ユーザー名が何かを確認してください。
原因の特定には ssh -v user@host のログが役立ちます。
どの鍵を提示したか、サーバーがどの認証方式を受け付けたかがそのまま出るので、Offering public key の先に意図した鍵ファイルが見えているかを確認すると、鍵未指定なのか、鍵は出しているのにサーバー側で拒否されているのかを切り分けられます。
サーバー側では authorized_keys の設置場所と内容（1行で完結しているか、余計な改行や空白がないか）を確認します。
権限の不整合（ホームディレクトリや .ssh、authorized_keys の権限）が原因で読み込みが拒否されることも多いので、ここを最初に確認すると問題切り分けが速くなります。

Connection refused対処

Connection refused は、相手ホストまでは届いているのに、そのポートでSSHサーバーが待ち受けていない状態です。
認証の話ではなく、sshd が動いていないか、接続先ポートを間違えています。
SSH の標準ポートは TCP 22 なので、まず 22 番で待ち受けている前提が合っているかを見ます。
Linux サーバーなら sudo systemctl status ssh または sudo systemctl status sshd でサービス状態を確認できます。
ディストリによってサービス名が ssh と sshd で分かれるので、どちらで登録されているかを見るのが近道です。
Windows 側をSSHサーバーにしている場合は、Get-Service sshd で状態を確認できます。
Microsoft LearnのWindows 用 OpenSSH Server の使い方を始めるMicrosoft LearnのWindows 用 OpenSSH Server の使い方を始めるでも、sshd サービスの確認と起動手順が整理されています。
もうひとつ多いのがポート番号の不一致です。
サーバー側を 22 以外で待ち受ける設定にしているのに、クライアントが標準ポートへ接続して refused になっている形です。
その場合は ssh -p ポート番号 user@host で明示して試します。~/.ssh/config を使っているなら Port の値が古いまま残っていないかも見ておくと、設定ファイル由来の取り違えを拾えます。

タイムアウト対処

タイムアウトは Connection refused と違って、相手に届く前で止まっていることが多いです。
SSHサーバーが応答しないというより、ネットワークの経路、ファイアウォール、ルーターのNAT設定で途中遮断されています。
自宅のRaspberry Piへ外から入ろうとして、ポート転送だけ抜けていたというのは家庭内ラボでもよくあります。

ここではSSHコマンドだけで悩まず、まずポート到達性を単体で調べます。
Windows なら Test-NetConnection host -Port 22、Linux や macOS なら nc -vz host 22 で、対象ホストのSSHポートに到達できるか確認できます。ssh 本体だと認証や鍵の話も混ざりますが、この段階では「22番に届くか」だけ見たほうが詰まりません。

社内LAN内では通るのに外部回線からだけタイムアウトするなら、ファイアウォールかNATのどちらかです。
クラウドならセキュリティグループやOSファイアウォール、自宅回線ならルーターのポート転送設定が候補になります。
筆者はこの段階で ssh -v も併用しますが、タイムアウト時はSSH固有の認証情報より、そもそもTCP接続が張れていないことがログから見えてきます。
認証設定をいじり始める前に、まず到達性を固めるほうが遠回りになりません。

ホスト鍵警告への対処

REMOTE HOST IDENTIFICATION HAS CHANGED! は、接続先サーバーのホスト鍵が前回記録したものと変わったという警告です。
初回接続の確認プロンプトとは別で、過去に知っていた相手と別物になった可能性を示しています。
OSの再インストール、SSHサーバーの再構築、IPアドレスの再割り当てでも起きます。

ここでやってはいけないのは、理由を確認しないまま勢いで known_hosts を消して進むことです。
正当な変更なのか、中間者攻撃のような異常なのかを分ける必要があります。
クラウドのコンソール、仮想マシンの管理画面、現地端末など、SSH以外の経路でそのサーバーに入り、現在のホスト鍵指紋が合っているかを確認してから更新します。

正当な変更だと確認できたら、クライアント側で古い記録を消します。ssh-keygen -R ホスト名 を実行すると known_hosts の該当エントリを削除でき、その後の再接続で新しいホスト鍵を登録できます。
ホスト名ではなくIPで登録していたなら、IPアドレス側のエントリも対象です。
この警告は面倒でも、SSHが接続先のなりすましを防ぐための仕組みそのものなので、無視せず意味を理解して処理したほうが後の運用が安定します。

TIP

初回接続で出るホスト鍵確認と、既存ホストの鍵変更警告は意味が違います。前者は新規登録、後者は「以前と違う相手かもしれない」という通知です。

秘密鍵の権限・パス指定ミス

秘密鍵の権限が広すぎると ssh が読み込みを拒否します。chmod 600 ~/.ssh/id_* を試し、WSL の共有ディレクトリ等で権限判定に引っかかっていないかも確認しましょう。

「鍵が見つからない」系のエラーは、ファイル名やパスの勘違いが中心です。ssh -i ~/.ssh/id_ed25519 user@host のつもりが、実際には別名で保存していたり、拡張子付きファイルを参照していたりします。
Windowsでも IdentityFile ~/.ssh/id_ed25519 のようにホーム基準で揃えておくと、コマンドと設定ファイルの対応が見やすくなります。
複数鍵を扱うなら、Host ごとに IdentityFile を固定して、必要なら IdentitiesOnly yes を組み合わせると、意図しない鍵の自動試行を減らせます。

経験上、秘密鍵の権限エラーとパス指定ミスは、単発の打ち間違いというより「どのホストにどの鍵を使うか」を手元で整理しきれていないときに起きます。ssh -v を見ると、どの鍵ファイルを探し、どの鍵を実際に提示したかが追えるので、設定ファイルの IdentityFile とログ上の鍵名が一致しているかを照らすと、原因の位置がはっきりします。

SSHを安全に使うための基本設定

SSHを安全に使うなら、最初の基準は公開鍵認証を前提にすることです。
パスワード認証は導入直後の確認には便利ですが、継続運用では総当たり攻撃の対象になりやすく、守る側の負担も増えます。
鍵は ssh-keygen で作成でき、入門者なら Ed25519 を軸に考えると扱いやすく、実務でもよく選ばれます。
RSA を使うなら 4096bit の例が多いです。
秘密鍵はクライアント側に残し、公開鍵だけをサーバーへ置く構成にすると、サーバーに認証情報そのものを置きっぱなしにしません。

サーバー側では、管理用の一般ユーザーでログインし、必要な操作だけ sudo を使う形に寄せると事故の範囲を絞れます。
そのために sshd_config では PermitRootLogin no を設定して、root の直接ログインを止めるのが基本です。
Linux なら設定ファイルは /etc/ssh/sshd_config、Windows のOpenSSH Serverでは C:\\ProgramData\\ssh\\sshd_config を編集します。
変更後は Linux なら sudo systemctl reload ssh、Windows なら PowerShell で Restart-Service sshd で反映できます。
Microsoft LearnのWindows 用 OpenSSH Server の使い方を始めるMicrosoft LearnのWindows 用 OpenSSH Server の使い方を始めるでも、Windows 側のサービス操作手順が整理されています。

パスワード認証を止めるときは、順番を守るほうが安全です。
先に公開鍵ログインが通る状態を確認してから PasswordAuthentication no に進めば、自分で締め出される事故を避けやすくなります。
ここで怖いのは「設定は正しいはず」と思い込んだまま、今開いているセッション一本だけで作業してしまうことです。
筆者は本番サーバーの設定変更時、常に二本のセッションを開いたままにして、さらに自動で元設定へ戻す切断ジョブも用意し、戻れる道を残してから触ります。
認証設定の変更は成功すると地味ですが、失敗するとその場で入れなくなるので、この慎重さがそのまま復旧時間に効きます。

パスフレーズも外せません。
秘密鍵にパスフレーズを付けると、鍵ファイルが流出しても即座に使われる危険を一段下げられます。
毎回入力するのが面倒に見えても、ssh-agent と ssh-add を使えば、作業の最初に一度だけ解除して、その後の接続はエージェントに任せる流れにできます。
実際の運用では、手間を増やしすぎずに保護層を一枚足せる方法として収まりがよいです。

.ssh 配下の権限も初歩のうちに整えておきたいところです。
Linux では .ssh ディレクトリを 700、authorized_keys を 600 にそろえておくと、余計な権限が原因で認証に失敗する場面を減らせます。
安全性の話に見えて、実際には「設定どおりなのに通らない」を避ける意味もあります。

鍵の保管とローテーション

秘密鍵は、サーバーではなく手元の安全な領域に保管します。
ノートPCのローカルユーザープロファイル直下や暗号化されたストレージに置き、メール添付やチャットへの貼り付けで配る運用は避けます。
持ち歩く端末が増えるほど鍵の所在が曖昧になるので、どの端末にどの鍵があるのかを整理しておくと、紛失時の切り分けが早くなります。
外へ持ち出す機会が多いなら、FIDO2 対応のハードウェアキーで ed25519-sk のような鍵を使う構成も候補になります。
物理タッチを伴うので、秘密鍵ファイルだけをコピーして済む状態より一段堅くできます。

ローテーションは「漏えいしたら交換する」だけでは足りません。
担当者の入れ替わり、端末の廃棄、共有していた踏み台の整理といった節目で、古い公開鍵を authorized_keys から外し、新しい鍵へ差し替える運用にしておくと、不要な入口が残りません。
複数人で触るサーバーほど、使っていない鍵が残ったままになりやすいです。
鍵名やコメントに用途と所有者を入れておくと、削除対象を追いやすくなります。

サーバー本体の更新も同じくらい効きます。
認証方式だけ固めても、OpenSSHやOS自体が古いままだと守りが片手落ちです。
OpenSSH Release Notesでも更新履歴が継続して公開されていて、機能追加や修正が積み重なっています。
サーバーの更新を止めず、SSH サービスもそれに合わせて保つほうが、個別の小細工に頼るより素直です。

接続元が固定できる環境では、ファイアウォールで IP を絞ると入口をさらに狭められます。
たとえば ufw allow from YOUR_IP to any port 22 のように、22番ポートへ届く送信元を限定する方法です。
自宅回線や固定拠点からだけ管理するサーバーなら、認証の前段で不要なアクセスを落とせます。
公開鍵認証、root 直接ログインの抑制、パスワード認証の停止、更新、IP 制限はそれぞれ別の層を受け持つので、どれか一つではなく重ねて効かせる構成のほうが崩れにくくなります。

パスワード認証・公開鍵認証・リモートデスクトップの比較

パスワード認証の特徴

SSHを最短で体験するなら、最初はパスワード認証がいちばん入りやすいです。
ユーザー名とパスワードが分かっていれば、追加の鍵作成なしでそのまま接続できます。
SSHの標準ポートはTCP 22なので、接続先がそのポートで待ち受けていれば、まずは1本コマンドを打つだけで試せます。

Windows なら標準のOpenSSH Clientで PowerShell から ssh user@host、macOS や Linux でもターミナルで同じく ssh user@host です。
追加ソフトなしで始められる点は大きく、Windows でもMicrosoft LearnWindows でもMicrosoft Learnにある通りOpenSSHが使えるので、まずは標準機能で十分です。
GUIで接続先を保存しながら触りたいなら、『Tera Term』や『PuTTY』のようなクライアントも選べますが、記事の流れに沿って最短で体験するなら標準の ssh コマンドが早いです。

初回接続時には、Are you sure you want to continue connecting という確認が出ます。
これは「この接続先サーバーの公開鍵をまだ知らないが、信頼して登録しますか」という意味です。yes と入力すると、そのサーバーの情報が手元の known_hosts に保存され、次回以降は同じ鍵である限り確認が出ません。
見慣れない警告に見えますが、SSHが相手を覚える最初の確認画面だと捉えると理解しやすくなります。

接続できたら、Linuxサーバーのシェルがそのまま開きます。
作業を終えて抜けるときは exit です。
これはWindows、macOS、Linuxのどこから接続していても同じです。
最初の一回は「ログインできた」「コマンドが打てた」「exit で戻れた」という流れだけつかめれば十分です。

一方で、パスワード認証は総当たり攻撃の対象になりやすいという弱点があります。
導入が速い代わりに、日常運用の主役に据えるには心もとない方式です。
そのため、初回の疎通確認や一時的な利用には向いていますが、継続利用では次の公開鍵認証へ移る前提で考えると整理しやすくなります。

Tera Term - Windows用端末エミュレータ

Tera TermはWindowsで動作する端末エミュレータで、telnet/ssh/シリアル接続に対応しています

teratermproject.github.io

公開鍵認証の特徴

日常的にSSHを使うなら、公開鍵認証のほうが収まりがよいです。
最初に鍵ペアを作って、公開鍵だけをサーバーへ置き、秘密鍵は手元に残します。
この「秘密鍵をサーバーへ送らない」構成が、パスワード認証より強い理由です。
初期設定の手間はありますが、その一度を越えると、毎回パスワードを直接送る運用から離れられます。

鍵作成の基本は、Windows の PowerShell、macOS のターミナル、Linux のシェルのどれでも ssh-keygen -t ed25519 -C "your-email@example.com" です。ed25519 は一般に推奨されることが多い鍵種で、データシートでも 256bit 相当として整理されています。
RSA を使う場面では ssh-keygen -t rsa -b 4096 -C "your-email@example.com" のような形も見かけます。
生成した公開鍵をサーバーの authorized_keys に登録し、秘密鍵は ~/.ssh/ に保管します。
Linux では .ssh を 700、authorized_keys を 600 にそろえると、権限の不整合で詰まる場面を減らせます。

接続コマンド自体はシンプルで、秘密鍵が標準パスにあるなら ssh user@host のままです。
別名の鍵を使うなら、Windows/macOS/Linux 共通で ssh -i ~/.ssh/id_ed25519 user@host と書けます。
ここでも初回は Are you sure you want to continue connecting が出ますが、意味はパスワード認証のときと同じです。
認証方式の違いではなく、相手サーバーのホスト鍵を初めて記録する確認だからです。
セッションを閉じるときも exit で戻れます。

公開鍵認証は安全性だけでなく、作業の流れも軽くなります。
秘密鍵にパスフレーズを付けても、ssh-agent と ssh-add を使えば、作業の最初に一度だけ解除して、その後の接続はエージェントへ任せられます。
筆者も普段はこの形で使っていて、鍵の保護と作業速度の折り合いが取りやすいと感じています。
接続のたびに毎回入力する運用より、実務ではこちらのほうが自然です。

初心者がつまずきやすいのは、鍵そのものより「どの鍵を使っているか分からない」状態です。
そんなときは ~/.ssh/config や Windows の %USERPROFILE%\.ssh\config に IdentityFile を明示しておくと見通しがよくなります。
複数鍵を使い分ける環境では IdentitiesOnly yes を入れると、関係ない鍵まで順に試して失敗する流れを避けやすくなります。
公開鍵認証は設定項目が少し増えますが、毎日使う入口としては最も安定しています。

リモートデスクトップの特徴

RDPやVNCのようなリモートデスクトップは、画面をそのまま遠隔操作したいときに向いています。
設定画面を見ながら変更したい作業や、Windows サーバーのGUI管理ではこちらのほうが合います。
SSHは文字ベースのCUI、リモートデスクトップはGUIという違いがあるので、優劣というより担当範囲が違います。

ただ、Linuxサーバーの保守をCUI中心で進めるなら、SSHのほうが軽く、回線が細い場面でも扱いやすいです。
筆者は普段、ログ確認、設定ファイル編集、サービス再起動のような保守はSSHで進めて、Windows の設定変更や画面操作が要る作業だけRDPに切り替える住み分けにしています。
このほうが移動量が少なく、必要な操作にすぐ入れます。
サーバー管理で毎回GUIを開くより、SSHで ssh user@host と入って exit で閉じる流れのほうが、反復作業では手数が減ります。

最短でSSHを体験する、という目的だけで見ると、リモートデスクトップは少し回り道です。
RDPやVNCは対象側で別の設定が必要で、ネットワークやセッション周りも含めて準備項目が増えます。
対してSSHは、Windows の標準OpenSSH、macOS、Linuxのターミナルから同じ ssh user@host を打てば始められます。
最初に Are you sure you want to continue connecting が出たらホスト鍵の登録、ログイン後に exit で終了という流れも共通で、覚える要素が少ない点が初心者向きです。

GUIクライアントの選択肢が欲しい場合も、SSHを避ける必要はありません。
Windows では標準のOpenSSH Clientで足りますし、接続先一覧を画面で管理したいなら『Tera Term』や『PuTTY』を使う方法もあります。
つまり、CUIで軽く入るならSSH、画面ごと触るならRDPやVNCという整理にすると迷いません。
最初の接続体験だけを切り出すなら、SSHがいちばん短い道です。

SSHはログインできるようになった時点で終わりではなく、ここから日常の運用へ広げていく道具です。
なお、本サイトは現時点で関連記事がまだ存在しないため、公開後は次のような内部リンクを「次のステップ」欄に2本以上追加してください: (例) linux-ssh-advanced-config-guide, raspberry-pi-ssh-tips。
内部リンクは公開後に編集担当が差し込みください。

SSHはログインできるようになった時点で終わりではなく、ここから日常の運用へ広げていく道具です。
まずは安全に接続する、次に安全に運ぶ、そして設定を絞り込んで管理対象を増やす、という順番で育てると無理がありません。
自宅のRaspberry PiでもWindows Server 2025でもLinuxサーバーでも、入口を一度整えると、その後の保守作業は落ち着いて回るようになります。
次に触れるべきなのは、ファイル転送、トンネル、運用習慣、そして土台になるLinuxの基礎です。