こんにちは、かつコーチです。
「クラウドでサーバーを借りたけど、どうやって中に入ればいいの?」。
Linuxサーバーを扱い始めると、最初にぶつかるのがこの疑問です。
答えはSSHという仕組みを使ってリモートサーバーに接続することです。
この記事では、SSHの基本概念から、実際に安全に接続するための設定までを順番に解説します。
検証環境はUbuntu 26.04 LTSです。
SSHとは?
SSHの定義
SSH(Secure Shell)とは、ネットワーク越しに離れた場所にあるサーバーへ、通信を暗号化した状態で安全にログインするための仕組みです。
自分のPC(クライアント)から、クラウド上のサーバー(リモートサーバー)に対してコマンドを送り、その結果を受け取れるようになります。
似た仕組みに古いtelnetがありますが、telnetは通信内容が暗号化されないため、現在はほぼ使われていません。
サーバー管理の現場では、SSHが接続手段の標準です。
なぜSSHでの接続が必要なのか
多くのLinuxサーバーは、画面もキーボードも直接つながっていないリモートサーバーとして運用されています。
クラウド事業者のデータセンターに置かれたサーバーに、物理的に触れることはまずありません。
そこでSSHを使い、手元のPCから遠隔でログインし、コマンドを実行してサーバーを操作します。
パスワードやコマンドの内容が暗号化されるため、第三者に盗み見られる心配なく安全にサーバーを管理できます。
SSH接続の基本の書き方
手順1:パスワード認証で接続する
最もシンプルな接続方法は、ユーザー名とパスワードを使う方法です。
$ ssh user@203.0.113.10
user@203.0.113.10's password:
sshコマンドのあとに「ユーザー名@サーバーのIPアドレス」を指定し、パスワードを入力するとログインできます。
ただし、パスワード認証は総当たり攻撃(ブルートフォース攻撃、パスワードを機械的に試し続けてログインを突破する攻撃)を受けやすいため、本番サーバーでは次に紹介する鍵認証への切り替えが推奨されます。
手順2:SSH鍵ペアを作成する
鍵認証とは、パスワードの代わりに「秘密鍵」と「公開鍵」のペアを使ってログインする方式です。
# 手元のPCで鍵ペアを生成する
$ ssh-keygen -t ed25519 -C "my-server-key"
Enter file in which to save the key (/home/you/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
-t ed25519は鍵の暗号方式の指定で、現在はrsaより高速かつ安全なed25519が推奨されています。
生成すると、次の2つのファイルができます。
| ファイル | 役割 |
|---|---|
id_ed25519(秘密鍵) | 自分のPCだけに置く。絶対に他人に渡さない |
id_ed25519.pub(公開鍵) | 接続先サーバーに登録する |
手順3:公開鍵をサーバーに登録する
公開鍵をサーバーに登録するにはssh-copy-idが便利です。
$ ssh-copy-id user@203.0.113.10
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/you/.ssh/id_ed25519.pub"
Number of key(s) added: 1
これでサーバー側の~/.ssh/authorized_keysに公開鍵が追加され、次回以降はパスワードなしでログインできるようになります。
$ ssh user@203.0.113.10
Welcome to Ubuntu 26.04 LTS
user@web01:~$
手順4:configファイルで接続を簡略化する
サーバーが増えてくると、IPアドレスや鍵ファイルの指定が面倒になります。
~/.ssh/configに接続情報をまとめておくと、エイリアス名だけで接続できます。
# ~/.ssh/config
Host web01
HostName 203.0.113.10
User user
IdentityFile ~/.ssh/id_ed25519
Port 22
# エイリアス名で接続できる
$ ssh web01
つまずきやすい設定・注意点
パーミッションの設定を誤ると鍵が使われない
SSHは、鍵ファイルのパーミッション(アクセス権限)が緩いと、セキュリティ上の理由で使用を拒否します。
L12で紹介したchmodを使い、以下のように権限を設定してください。
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519
$ chmod 644 ~/.ssh/id_ed25519.pub
秘密鍵は「自分だけが読み書きできる」状態(600)にしておくのが基本です。
rootでの直接ログインは避ける
初期状態のクラウドサーバーではrootユーザーで直接ログインできることがありますが、これはセキュリティ上のリスクが高い設定です。
一般ユーザーでログインし、必要なときだけL14で紹介したsudoを使う運用にするのが安全です。
よくあるつまずきポイント・エラー対処
Permission denied (publickey)で接続できない
私が実際に検証環境で新しいサーバーに接続しようとしたとき、次のエラーに遭遇しました。
❌ Before
$ ssh user@203.0.113.10
user@203.0.113.10: Permission denied (publickey).
原因は、公開鍵をサーバー側のauthorized_keysに登録し忘れていたことでした。
パスワード認証が無効化されたサーバーだったため、鍵がなければ一切ログインできない状態だったのです。
✅ After
# コンソール(クラウド管理画面など)から一度ログインし、公開鍵を直接追記する
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... my-server-key" >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
サーバー提供元のWebコンソールなど、SSH以外の手段でログインする経路を必ず確保しておくと、この手のロックアウトを防げます。
Host key verification failedで接続を拒否される
サーバーを作り直した後に、同じIPアドレスへ再接続しようとして次のエラーに遭遇したこともあります。
❌ Before
$ ssh user@203.0.113.10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Host key verification failed.
これはSSHが「なりすましサーバーではないか」を検知するための正常な警告です。
以前に接続した同じIPのサーバー情報(ホスト鍵)と、今回接続したサーバーの鍵が一致しないために表示されます。
サーバーを作り直したことが原因だと分かっている場合のみ、古い記録を削除します。
✅ After
# 古いホスト鍵の記録を削除してから再接続する
$ ssh-keygen -R 203.0.113.10
$ ssh user@203.0.113.10
The authenticity of host '203.0.113.10' can't be established.
Are you sure you want to continue connecting (yes/no)?
このエラーが出るたびに理由を確認せず削除する癖をつけると、本当のなりすまし攻撃を見逃す危険があるため、必ず原因を把握してから対処してください。
応用・一歩先の使い方
パスワード認証自体を無効化する
鍵認証に切り替えたら、サーバー側の設定でパスワード認証そのものを無効化すると、ブルートフォース攻撃のリスクをさらに下げられます。
# /etc/ssh/sshd_config を編集
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
$ sudo systemctl restart ssh
設定変更後は、別の端末で新規接続を試して、鍵認証でログインできることを確認してから元の接続を切るのが安全です。
SSHのポート番号を変更する
デフォルトの22番ポートは自動スキャンの標的になりやすいため、別のポート番号に変更する運用もよく行われます。
Port 2222
L16で紹介したファイアウォール設定と合わせて、変更後のポートを許可することを忘れないようにしてください。
まとめ
この記事のポイント
- SSHはリモートサーバーへ暗号化通信で安全にログインする仕組み
- パスワード認証より鍵認証(公開鍵・秘密鍵のペア)が安全で推奨される
~/.ssh/configで接続情報をまとめると、エイリアス名で簡単に接続できる- 秘密鍵のパーミッションは600に設定する
- Webコンソールなど、SSH以外のログイン経路を必ず確保しておく
次に読むべき記事
- L21「scp・rsyncでファイルを転送する」でSSHを使ったファイル転送を学ぶ
- L14「sudoの仕組みと安全な使い方」で権限管理を深める
- L23「よくあるLinuxエラーとトラブルシューティング」でさらに幅広いエラー対処を確認する