Linuxサーバーへの安全なログインと不正アクセスの痕跡確認｜実務手順

Linuxサーバーへのアクセスには「コンソール接続」と「SSHリモートログイン」の2経路があります。現代の実務ではSSHが主流ですが、ネットワーク障害やSSHサービス停止の場面ではコンソールが頼りになります。ここでは両経路でのログイン手順から、ログイン後に必ず確認すべき不正アクセスの痕跡確認まで一気に片付けます。

まず実行：SSHでリモートログインする最短手順

リモートのLinuxサーバーへ接続するには ssh コマンドを使います。

# 基本形（ユーザー名@ホスト名またはIPアドレス）
ssh alice@192.168.1.100

# ポートを変更している場合
ssh -p 2222 alice@192.168.1.100

# 鍵ファイルを明示して接続する場合
ssh -i ~/.ssh/id_ed25519 alice@192.168.1.100

初回接続時は「ホスト鍵の確認」が表示されます。接続先のフィンガープリントが正しいことを確認してから yes と入力してください。確認せずに yes を打ち続けると中間者攻撃のリスクが生じます。

ログイン成功後には必ず Last login メッセージが表示されます。この内容は毎回確認する習慣をつけてください（詳細は後述）。

Last login: Mon Jul  7 09:15:22 2026 from 192.168.1.10
[alice@web01 ~]$

コンソールからのログイン（SSHが使えない場面の備え）

物理サーバーの画面・キーボード直結、またはKVM/VMwareなどのVMコンソールでは、OS起動後にテキストのログインプロンプトが表示されます。

AlmaLinux release 9.4 (Seafoam Ocelot)
Kernel 5.14.0-427.13.1.el9_4.x86_64 on an x86_64

web01 login: alice
Password:
Last login: Mon Jul  7 09:15:22 2026 from 192.168.1.10
[alice@web01 ~]$

ユーザー名を入力して Enter、続いてパスワードを入力します。パスワード入力中は画面に何も表示されませんが、正しく受け付けられています。

コンソールログインが必要になる主な場面は、ネットワーク障害・SSHサービス停止・SSH設定ミスによるロックアウトです。「SSHで入れなくなった」ときの最後の砦になるため、BMC/iDRAC/ILOやクラウドのシリアルコンソールなど、コンソールへのアクセス手段を事前に把握しておくことが重要です。

SSH鍵認証に移行してパスワード認証を廃止する

インターネットに公開しているサーバーでパスワード認証を有効にしたままにすると、SSH総当たり攻撃のターゲットになります。鍵認証への移行は実務上の必須作業です。

ステップ1：クライアント側で鍵ペアを生成する

# ed25519鍵を生成（RSA-2048より安全・高速）
ssh-keygen -t ed25519 -C "alice@workstation"

# 生成される鍵ファイル
# 秘密鍵: ~/.ssh/id_ed25519    ← 厳重に保管・外部に渡さない
# 公開鍵: ~/.ssh/id_ed25519.pub ← サーバーに登録する

ステップ2：公開鍵をサーバーへ登録する

# ssh-copy-id で公開鍵を自動登録（パスワード認証が有効な間に実行）
ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@192.168.1.100

# 鍵認証でログインできることを別ターミナルで確認してから次のステップへ
ssh alice@192.168.1.100

ステップ3：サーバー側でパスワード認証を無効にする

# /etc/ssh/sshd_config を編集（変更前に必ずバックアップを取る）
PasswordAuthentication no
PubkeyAuthentication yes

# 構文チェックを通過してから反映する
sudo sshd -t && sudo systemctl reload sshd

注意：パスワード認証を無効にする前に、必ず別ターミナルで鍵認証ログインが成功することを確認してください。確認前に無効化するとサーバーから締め出されます。その場合はコンソールから /etc/ssh/sshd_config を元に戻して復旧します。

ログイン後のLast loginメッセージと認証ログで不正アクセスを把握する

ログイン成功時に表示される Last login の行には「前回はいつ、どこから接続したか」が記録されています。身に覚えのないIPアドレスや日時が表示されていたら、すぐにパスワードを変更し、以下の手順で調査を進めてください。

過去のログイン履歴をまとめて確認するには last コマンドを使います。

# 直近20件のログイン履歴を表示
last -n 20

# 出力例：同一ユーザーが見知らぬIPから深夜に接続していた場合
alice    pts/0    203.0.113.45   Mon Jul  7 03:14 - 03:45  (00:31)
alice    pts/0    192.168.1.10   Mon Jul  7 09:23 - 11:05  (01:41)

ログイン失敗の記録は lastb で確認できます。外部から特定アカウントへの連続失敗が記録されていれば総当たり攻撃が来ている証拠です。

# ログイン失敗履歴（root権限が必要）
sudo lastb -n 20

# 外部から root への総当たり攻撃が来ていた場合の例
root     ssh:notty    198.51.100.22   Mon Jul  7 03:12 - 03:12  (00:00)
root     ssh:notty    198.51.100.22   Mon Jul  7 03:11 - 03:11  (00:00)

より詳細なSSH認証ログは journalctl で時刻指定して絞り込みます。

# RHEL系（AlmaLinux/Rocky Linux）の場合
journalctl -u sshd --since "2026-07-07" | grep -E "Accepted|Failed"

# Ubuntu/Debian ではユニット名が異なる場合がある
journalctl -u ssh --since "2026-07-07" | grep -E "Accepted|Failed"

不審なIPからの接続が確認できたら、firewalld や ufw で即座にブロックし、該当時間帯の ~/.bash_history や auditd のログと突き合わせて被害範囲を特定します。ある運用現場では Last login の異常を入口に調査したところ、深夜に数百回のSSH試行が来ていたことが発覚し、即時にポート変更と接続元IPのブロックで対処したケースがありました。

rootへの直接ログインを避ける運用上の理由

現代のLinux運用では、root権限が必要な操作でも「一般ユーザーでログインしてから sudo で昇格する」が標準です。rootへ直接ログインする運用には2つの問題があります。

1点目は操作追跡の困難さです。操作履歴がrootに集約されるため、複数人が管理するサーバーでは誰が何をしたかの特定が難しくなります。2点目はSSHへの攻撃耐性です。PermitRootLogin を yes にしているとrootへの総当たり攻撃が直撃します。/etc/ssh/sshd_config では no または prohibit-password（鍵認証のみ許可）を設定してください。

# 一般ユーザーでログイン後、管理作業は sudo で実行
sudo systemctl restart nginx

# rootシェルへの昇格が必要な場面では sudo -i を使う（操作記録が残る）
sudo -i

sudoによる操作記録は journalctl で確認できます。複数人が管理するサーバーでは、この記録が障害や誤操作が起きた際の原因調査の起点になります。

# sudo の操作ログを確認
journalctl --since "yesterday" | grep sudo

# RHEL系では /var/log/secure にも記録される
sudo grep sudo /var/log/secure | tail -20