本記事には広告(アフィリエイトリンク)が含まれます。

SSH接続とターミナル操作の基本テクニック

Linuxエンジニア養成講座 第5回|全36回・フェーズ2「Linux基礎」の2回目です。
前回までに学んだこと: Linuxの基本概念と検証環境の確認(第4回)。
今回学ぶこと: SSH接続の仕組み、Windows標準のOpenSSHクライアントからの接続手順、ターミナル操作の基本テクニック。

前回はVMコンソールからalma-mainにログインし、コマンドを手入力して環境を確認しました。今回はSSH接続を学び、以降の全演習をSSH経由で行えるようにします。この回を境に、VMコンソールを卒業してSSH経由の操作に切り替わります。

Linux養成講座全36回の4フェーズ構成図。フェーズ1「エンジニアのいろは」(第1〜3回)は完了、フェーズ2「Linux基礎」(第4〜15回)の第5回が現在地。フェーズ3「ネットワークとインフラ基盤」(第16〜27回)、フェーズ4「サーバー構築と運用」(第28〜36回)が続く。

図: 本講座の4フェーズ構成。フェーズ2「Linux基礎」の第5回が現在地です。

この回の学習目標

  • ホストPCからSSHでalma-mainに接続し、コマンドを実行できる
  • SSH configを設定し、短いコマンドで接続できる
  • コマンド履歴(↑↓)、タブ補完、Ctrl+Cの3つの基本操作を使える
  • SSHセッションを正しく終了できる

なぜSSHで接続するのか

もしすべてのサーバー操作を物理的にコンソールの前に座って行わなければならないとしたら、100台のサーバーを管理する現場はどうなるでしょうか。

現場ではリモート管理が必須

データセンターに設置されたサーバーや、クラウド上の仮想マシンに物理的にアクセスできる状況は限られています。サーバーの設定変更、ログの確認、トラブルシューティング ―― これらの日常業務は、自席のPCからリモートで接続して行うのが通常の作業スタイルです。つまり、サーバーは物理的に離れた場所にあることが前提であり、リモートから安全に管理する手段が必要です。SSHがその手段にあたるプロトコルです。

検証環境でのコンソールの限界を振り返る

この検証環境でも同じことが言えます。第4回ではVMコンソールからalma-mainにログインしました。コマンドを手入力して結果を確認する体験としては十分でしたが、実際に作業を続けていくと、以下の不便さに気付いたはずです。

  • ホストPC側でコピーしたテキストをVM側に貼り付けられない(クリップボード共有が制限される)
  • コマンドを1文字ずつ手入力する必要があり、入力ミスが起きやすい
  • 画面のスクロールバック(過去の出力を遡って確認する操作)が限られている
  • 複数のサーバーに同時接続するのが面倒(VMごとに別ウィンドウを開く必要がある)

これらの制約は、コンソールが「VMの直接操作用」であり、日常的なサーバー管理のためのツールではないことに起因しています。本番環境のサーバールームに毎回足を運んで操作するのが非現実的であるのと同じです。

SSHとは何か

SSH(Secure Shell)は、ネットワーク越しにリモートのサーバーへ安全に接続するためのプロトコル(通信の決まりごと)です。

SSHの最大の特徴は、通信内容がすべて暗号化されることです。入力するパスワード、実行するコマンド、その結果 ―― すべてが暗号化された状態でネットワーク上を流れるため、第三者に盗聴されるリスクがありません。

SSHが登場する前は、Telnetやrloginといったプロトコルがリモートログインに使われていました。これらは通信が平文(暗号化なし)であり、ネットワーク上を流れるパスワードやコマンドをそのまま傍受できてしまいます。現在、サーバーへのリモート接続にはSSHが事実上の標準です。Telnetを使う場面は、ネットワーク機器の初期設定など非常に限られています。

SSHのデフォルトポートはTCP 22番です。

SSHは現場の標準ツール

現場ではSSH接続が当たり前の作業手段です。SSHはリモートログインだけでなく、ファイル転送(SCP/SFTP)やポートフォワーディングにも使用されます。これらの機能は第27回「SSH応用」で扱います。

SSH接続の全体像

今回のゴール

今回は、ホストPC(Windows 11)からalma-main(192.168.1.121)へSSHで接続し、コマンドを実行できる状態を目指します。

SSH接続の全体像。左側にホストPC(Windows 11)、右側にalma-main(192.168.1.121)。ホストPCからSSH(TCP 22番ポート)でalma-mainへ接続する矢印が描かれている。通信経路は暗号化されていることを示す鍵アイコン付き。

図: SSH接続の全体像。ホストPCのSSHクライアントから、alma-mainのSSHサーバー(sshd、TCP 22番)へ暗号化された通信路で接続します。

第4回ip a コマンドを実行して確認したeth0のIPアドレス(192.168.1.121)を、SSH接続先として使用します。前回学んだ知識が早速役に立ちます。

パスワード認証と鍵認証

SSHでサーバーに接続する際、「このユーザーは本人か」を確認する認証方式が2種類あります。

パスワード認証は、ユーザー名とパスワードを入力してログインする方式です。仕組みが単純で分かりやすい反面、パスワードが弱いと総当たり攻撃(ブルートフォース)で突破されるリスクがあります。

鍵認証(公開鍵認証)は、「秘密鍵」と「公開鍵」のペアを使って認証する方式です。秘密鍵は自分のPC(クライアント側)に保管し、絶対に他人に渡しません。公開鍵はサーバー側に登録します。パスワードがネットワーク上を流れないため、パスワード認証より安全性が高い方式です。

パスワード認証と鍵認証の比較図。パスワード認証はユーザー名とパスワードで認証する方式。鍵認証は秘密鍵(クライアント側)と公開鍵(サーバー側)のペアで認証する方式。鍵認証のほうが安全性が高いことを示す。

図: パスワード認証と鍵認証の比較。鍵認証では秘密鍵をクライアント側に、公開鍵をサーバー側に配置します。

南京錠と鍵で例えると分かりやすいです。公開鍵が南京錠、秘密鍵がその鍵です。南京錠(公開鍵)は誰に見られても問題ありませんが、鍵(秘密鍵)を持っている本人だけがロックを解除できます。

鍵の生成手順や認証の仕組みの詳細は第27回「SSH応用」で扱います。今回は「パスワード認証と鍵認証の2種類がある。鍵認証のほうが安全」という概念だけ押さえておいてください。

この検証環境の認証設定

この検証環境では、以下のように認証が設定されています。

  • developerユーザー: ed25519方式の鍵認証が設定済み。パスワード認証も可
  • rootユーザー: 鍵認証のみ許可。パスワードでのSSHログインは不可

rootのパスワードログインが禁止されている理由は、rootは最高権限を持つユーザーであり、パスワードが突破されるとサーバー全体を制御されてしまうためです。これはAlmaLinuxのデフォルト設定(PermitRootLogin without-password)です。

この講座ではdeveloperユーザーでSSH接続します。developerには sudo の権限が付与されているため、管理者権限が必要なコマンドは sudo を付けて実行できます。第4回ではrootユーザーでVMコンソールにログインしましたが、今回からはdeveloperユーザーでの操作に切り替わります。

Windows標準のSSHクライアントで接続する

OpenSSHクライアントの確認

Windows 11にはOpenSSHクライアントが標準搭載されています。追加のインストールは不要です。PowerShellを開いて、バージョンを確認します。

ホストPCで実行します。

実行コマンド:

PS> ssh -V

実行結果:

OpenSSH_10.2p1, OpenSSL 3.5.5 27 Jan 2026

バージョン情報が表示されれば、SSHクライアントは利用可能です。もし「ssh: The term ‘ssh’ is not recognized」のようなエラーが出る場合は、Windowsの「設定」→「アプリ」→「オプション機能」から「OpenSSH クライアント」を追加してください。

SSH接続する

ホストPCのPowerShell(またはWindows Terminal)から、alma-mainにSSH接続します。

ホストPCで実行します。

実行コマンド:

PS> ssh developer@192.168.1.121

このコマンドの構成は以下のとおりです。

  • ssh: SSHクライアントのコマンド
  • developer: ログインするユーザー名
  • @: ユーザー名と接続先の区切り
  • 192.168.1.121: 接続先サーバーのIPアドレス(alma-mainのeth0)

初回接続時のフィンガープリント確認

初めてのサーバーに接続すると、以下のメッセージが表示されます。

The authenticity of host '192.168.1.121 (192.168.1.121)' can't be established.
ED25519 key fingerprint is SHA256:QEwViOxbFnMlqTTbyqaopqrPTnxgUPnQLRyr1G8sD5Q.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

これはサーバーの身元確認です。「このサーバーは本当に正しい接続先ですか」とSSHクライアントが確認しています。

SHA256:QEwViOxbFnMlqTTbyqaopqrPTnxgUPnQLRyr1G8sD5Q がサーバーのフィンガープリント(指紋)です。本番環境では、サーバー管理者にフィンガープリントの値を確認してから yes を入力するのが正式な手順です。検証環境では yes と入力してEnterを押してください。

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.121' (ED25519) to the list of known hosts.

yes と入力すると、サーバーの公開鍵がホストPC側の ~/.ssh/known_hosts ファイルに保存されます。2回目以降の接続ではこの確認は表示されません。

もし接続済みのサーバーに再接続した際に「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」という警告が表示された場合は、サーバーの鍵が変わったことを意味します。サーバーを再構築した場合に発生しますが、もし心当たりがなければ接続を中止して原因を調査してください。

ログイン成功 ―― コピー&ペーストを試す

鍵認証が成功すると、パスワードの入力なしでログインが完了し、以下のプロンプトが表示されます。

[developer@alma-main ~]$

第4回のVMコンソールでは [root@alma-main ~]# でしたが、今回は developer ユーザーでログインしているため、プロンプトの記号が $ になっています。# はroot、$ は一般ユーザーです。

ここでSSH接続の最大のメリットを体験します。以下のコマンドをホストPC側でコピーして、PowerShellのウィンドウで右クリック(またはCtrl+Shift+V)でペーストしてみてください。

alma-mainで実行します。

実行コマンド:

$ hostname

実行結果:

alma-main

VMコンソールでは手入力するしかなかったコマンドが、コピー&ペーストで実行できるようになりました。Webサイトのコマンドをそのままコピーして貼り付けられるため、入力ミスが減り、作業の効率が大きく向上します。

今後の全演習はこのSSH接続経由で行います。VMコンソールは「SSHが使えない緊急時のバックアップ手段」として覚えておいてください。

SSH config で接続を便利にする

毎回 ssh developer@192.168.1.121 と入力するのは手間がかかります。SSH config ファイルにエイリアス(別名)を登録すると、短いコマンドで接続できるようになります。

SSH config ファイルのパスは C:\Users\<ユーザー名>\.ssh\config です。このファイルをメモ帳やテキストエディタで開き、以下の内容を追記してください。ファイルが存在しない場合は新規に作成します。

ホストPCで実行します。

追記内容:

Host alma-main
    HostName 192.168.1.121
    User developer
    IdentityFile ~/.ssh/id_ed25519

各行の意味は以下のとおりです。

  • Host alma-main: エイリアス名。自由に決められる名前で、SSHコマンドに指定する
  • HostName 192.168.1.121: 接続先の実際のIPアドレス
  • User developer: ログインユーザー名
  • IdentityFile ~/.ssh/id_ed25519: 秘密鍵のファイルパス

保存したら、以下のコマンドで接続を試みてください。

ホストPCで実行します。

実行コマンド:

PS> ssh alma-main

IPアドレスやユーザー名を入力しなくても、ssh alma-main の一言で接続できるようになりました。検証環境にVMが複数ある場合は、同様に登録しておくと後の演習で便利です。

Host alma-sub
    HostName 192.168.1.122
    User developer
    IdentityFile ~/.ssh/id_ed25519

筆者の検証環境で alma-proxy を構築している場合は、以下も追加しておくと便利です。

Host alma-proxy
    HostName 192.168.1.123
    User developer
    IdentityFile ~/.ssh/id_ed25519

SSH config ファイルの注意点として、インデントにはスペースを使用してください(タブも可能ですがスペースが慣例です)。また、IdentityFile のパスに日本語やスペースが含まれているとエラーの原因になる場合があります。

ターミナル操作の基本テクニック

SSH接続ができたところで、ターミナル上での作業を効率化する基本テクニックを覚えます。どれもLinuxを扱う上で毎日使う操作です。

コマンド履歴(↑↓キー)

キーボードの↑キーを押すと、直前に実行したコマンドが表示されます。さらに↑キーを押すと、その前のコマンド、さらにその前のコマンド……と遡れます。↓キーで逆方向に進みます。

alma-mainで実行します。

実行コマンド:

$ hostname
$ whoami

この2つのコマンドを実行した後に↑キーを1回押すと whoami が、もう1回押すと hostname が表示されます。Enterを押せばそのまま実行できます。長いコマンドを何度も入力する手間が省けます。

過去に実行したコマンドの一覧を確認するには history コマンドを使います。

実行コマンド:

$ history

実行結果(例):

    1  hostname
    2  whoami
    3  history

タブ補完

コマンドやファイル名の一部を入力してTabキーを押すと、残りの部分が自動で補完されます。

alma-mainで実行します。

実行コマンド:

$ hostn[Tab]

hostn まで入力してTabキーを押すと、hostname に自動補完されます。同様に、ファイルパスの途中まで入力してTabキーを押すと、該当するファイル名やディレクトリ名が補完されます。

$ cat /etc/os-[Tab]

/etc/os- まで入力してTabキーを押すと、/etc/os-release に補完されます。候補が複数ある場合はTabキーを2回押すと、候補の一覧が表示されます。

タブ補完はスペルミスを防ぐだけでなく、「このディレクトリにどんなファイルがあるか」を探る手段としても使えます。

Ctrl+C で中断する

実行中のコマンドを途中で止めるには、Ctrl+Cを押します。

alma-mainで実行します。

実行コマンド:

$ ping 127.0.0.1

ping コマンドはLinuxでは停止指示があるまで実行を続けます(Windowsの ping は4回で自動停止しますが、Linuxでは止まりません)。画面に応答結果が流れ続けるので、Ctrl+Cを押して中断してください。

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 バイト応答 送信元 127.0.0.1: icmp_seq=1 ttl=64 時間=0.037ミリ秒
64 バイト応答 送信元 127.0.0.1: icmp_seq=2 ttl=64 時間=0.047ミリ秒
^C
--- 127.0.0.1 ping 統計 ---
送信パケット数 2, 受信パケット数 2, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.037/0.042/0.047/0.005 ms

^C はCtrl+Cを押したことを示す表示です。Ctrl+Cは「実行中のコマンドを強制的に止める」操作であり、ターミナルでの作業中に最も頻繁に使うキー操作の1つです。

なお、Ctrl+Cで止められるのは、現在のターミナルのフォアグラウンドで実行中のコマンドに限られます。バックグラウンドプロセスの制御については第12回「プロセス管理」で学びます。

画面クリアとログアウト

ターミナルの表示が混み合ってきたら、clear コマンドまたはCtrl+Lで画面をクリアできます。過去の出力はスクロールバックで確認できます。

alma-mainで実行します。

実行コマンド:

$ clear

SSHセッションを終了するには、exit コマンドを使います。

実行コマンド:

$ exit

実行結果:

Connection to 192.168.1.121 closed.

exit を実行するとSSH接続が切断され、ホストPCのプロンプトに戻ります。logout コマンドやCtrl+D(EOF送信)でも同じ結果になります。

現場では必ず exit で正しく切断する習慣をつけてください。ターミナルのウィンドウを閉じるだけだと、サーバー側にセッションが残る場合があります。

やってみよう — SSH経由で環境確認を再実行する

第4回でVMコンソールから実行した環境確認コマンドを、今度はSSH接続で再実行します。SSH config を設定済みであれば ssh alma-main で接続してください。

ホストPCで実行します。

実行コマンド:

PS> ssh alma-main

ログイン後、以下のコマンドを順番に実行してください。コマンドをこの記事からコピー&ペーストして構いません。むしろ、コピー&ペーストが使えることをこの演習で実感してください。

alma-mainで実行します。

実行コマンド:

$ hostname
$ cat /etc/os-release
$ ip a show eth0
$ df -h
$ free -h

free -h はメモリの使用状況を表示するコマンドです(第4回で実行済み)。

第4回で手入力した同じコマンドが、コピー&ペーストで実行できることを確認してください。結果もVMコンソールで実行したときと同じ内容が返ってくるはずです(ログインユーザーが異なるため、一部の表示が違う場合があります)。

さらに以下も試してみてください。

  1. ↑キーで直前のコマンドを呼び出して、もう一度実行する
  2. hostn まで入力してTabキーで hostname に補完する
  3. ping 127.0.0.1 を実行し、Ctrl+Cで中断する
  4. clear で画面をクリアする
  5. exit でSSHセッションを切断する

これで、SSH接続からログアウトまでの一連の流れを体験できました。

現場ヒヤリハット: SSH切断で作業が消えた

あるエンジニアがSSH経由でサーバー上のスクリプトを実行していました。処理に30分ほどかかる見込みでしたが、途中でノートPCのスリープが作動し、SSHセッションが切断されました。再接続すると、実行中だったスクリプトは途中で停止しており、処理をやり直す羽目になりました。

SSHセッションが切れると、そのセッション上で実行中のプロセスも停止します。長時間の処理を実行する場合は、tmuxscreen といったターミナルマルチプレクサを使い、セッションが切れても処理が継続する環境を用意します。これらのツールは第27回「SSH応用」で学びます。

理解度チェック

以下の文が正しければ○、間違っていれば×と答えてください。

Q1. SSHはTelnetと同様に、通信内容を暗号化せずにリモート接続するプロトコルである。

Q2. SSH接続時に初回だけ表示されるフィンガープリントの確認は、接続先サーバーの身元確認である。

Q3. この検証環境では、rootユーザーのパスワードを入力すればSSHでログインできる。

Q4. SSH config ファイルに設定を書くと、IPアドレスやユーザー名を省略して接続できる。

Q5. LinuxのpingコマンドはCtrl+Cを押さない限り、自動的に停止しない。

Q6. ↑キーを押すと、直前に実行したコマンドが表示される。

Q7. SSHセッションを終了するには、ターミナルのウィンドウを閉じればよい。

答え: Q1=×(SSHは通信を暗号化する。暗号化しないのはTelnet)、Q2=○、Q3=×(rootはパスワード認証でのSSHログインが禁止されている。鍵認証のみ許可)、Q4=○、Q5=○、Q6=○(コマンド履歴の基本操作。↓キーで逆方向に進める)、Q7=×(exitコマンドで正しく切断する。ウィンドウを閉じるだけだとサーバー側にセッションが残る場合がある)

まとめ

  • SSHはネットワーク越しにサーバーへ安全に接続するプロトコルで、通信はすべて暗号化される
  • 認証方式にはパスワード認証と鍵認証の2種類がある。鍵認証のほうが安全性が高い
  • Windows 11標準のOpenSSHクライアントで ssh ユーザー名@IPアドレス と入力すれば接続できる
  • SSH config ファイルにエイリアスを登録すると、短いコマンドで接続できる
  • ↑↓キーのコマンド履歴、Tabキーの補完、Ctrl+Cの中断は、毎日使う基本操作である
  • SSHセッションの終了には exit コマンドを使う

今回の内容で、VMコンソールからの卒業が完了しました。次回の第6回「ファイルシステムとディレクトリ構造」からは、SSH経由でalma-mainに接続した状態で進めます。

シリーズ一覧

フェーズ1: エンジニアのいろは

フェーズ2: Linux基礎

フェーズ3: ネットワークとインフラ基盤

フェーズ4: サーバー構築と運用