情シス担当のためのBash入門:サーバー作業で必ず使うコマンドと基本構文
結論: SSH接続直後に必要なのは、pwd・ls・whoami の3コマンドで「今どこにいるか」を確認することです。これさえできれば、上司から頼まれたサーバー確認作業の大半は一人でこなせます。
SSHで接続した直後、こんな画面が出てきます。
user@server:~$
次に何を打てばいいか、分かりますか。
「ls は打てるけど、その先が分からない」「間違えてサーバーを壊すのが怖い」「vi を開いたら閉じられなくなった」——これは情シス担当のあいだで驚くほど共通する体験です。
この記事は、プログラミング未経験の情シス担当が、サーバー作業で実際に使うコマンドを体系化したものです。読み終えると、ファイル確認・ログ閲覧・権限変更・SSH接続エラーの対処が一人でできるようになります。
まず「今自分がどこにいるか」を確認する
SSH接続直後にやることは、場所の確認です。ファイル操作はすべて「今いる場所」を起点に行うため、これを外すと後続の操作が意味をなしません。
pwd — 現在地を表示する
pwd は Print Working Directory の略で、現在いるディレクトリの絶対パスを表示します。Windowsのエクスプローラー上部にあるアドレスバーに相当します。
pwd
# 出力例: /home/user
引数なしで実行するだけです。SSH接続後に迷ったときは、まず pwd を実行して現在地を確認します。
ls — ファイル一覧を見る
ls はディレクトリ内のファイルとフォルダを一覧表示します。ls -la とオプションを付けると、権限・所有者・サイズ・更新日時も確認できます。
ls -la
# -l: 詳細表示 -a: 隠しファイル(.で始まるファイル)も表示
出力例の読み方:
| 列 | 意味 | 例 |
|---|---|---|
| 先頭の文字 | d=ディレクトリ / -=ファイル | drwxr-xr-x |
| 権限 | 所有者/グループ/その他の読み書き実行 | rwxr-xr-x |
| 所有者 | ファイルの持ち主ユーザー名 | user |
| グループ | 所属グループ名 | www-data |
| サイズ | バイト数 | 4096 |
| 更新日時 | 最終変更日 | Jun 30 12:00 |
| ファイル名 | 名前 | nginx.conf |
.ssh/ のようにドットで始まるファイルは隠しファイルです。ls だけでは表示されず、-a オプションが必要です。SSH鍵の確認には ls -la ~/.ssh/ を使います。
whoami・hostname — 自分の権限とサーバーを確認する
whoami
# 出力例: user(一般ユーザー)または root(管理者)
hostname
# 出力例: web-server-01
複数台のサーバーを触るとき、作業対象を間違えるミスが起きやすくなります。hostname でサーバー名を確認する習慣は、この種のミスを防ぎます。
コマンドプロンプトの末尾が $ なら一般ユーザー、# なら root(管理者)での作業です。# のときはコマンドの影響が広範囲に及ぶため、特に慎重に操作します。
ファイルとディレクトリを操作する
cd — ディレクトリを移動する
cd /var/log # 絶対パスで移動
cd .. # 一つ上のディレクトリへ
cd # ホームディレクトリへ戻る
cd - # 直前にいたディレクトリへ戻る
Windowsとの重要な違いが2点あります。パス区切り文字がWindowsの \ に対してLinuxは / です。また、Linuxはファイル名の大文字と小文字を区別します。Config.txt と config.txt は別のファイルとして扱われます。
cp・mv — ファイルをコピー・移動する
cp nginx.conf nginx.conf.bak # バックアップコピーを作成
cp -i source.txt destination.txt # -i: 上書き前に確認を求める
mv -i oldname.txt newname.txt # ファイル名を変更(移動)
設定ファイルを変更する前は、必ず cp でバックアップを作成します。nginx.conf.bak のように .bak 拡張子を付けるのが一般的な慣習です。
-i オプション(interactive)は、同名ファイルが存在する場合に上書き確認を求めます。特に cp と mv には常に -i を付ける習慣をつけると、意図しない上書きを防げます。
mkdir — ディレクトリを作る
mkdir logs # ディレクトリを作成
mkdir -p /opt/app/logs/archive # -p: 中間ディレクトリも含めて一括作成
rm — ファイルを削除する
rm で削除したファイルはゴミ箱に入りません。即座に、かつ復元できない形で削除されます。Windowsの Delete キーとは根本的に違います。
rm file.txt # ファイルを削除
rm -i file.txt # -i: 削除前に確認を求める
rm -rf /path/to/directory # ディレクトリを中身ごと削除(復元不可)
rm -rf は削除確認なしにディレクトリ全体を消します。実行前に ls で対象を目視確認し、可能な限り絶対パス(/home/user/temp/ のように / から始まるパス)で指定します。相対パスのタイプミスで意図しない場所を削除するリスクを減らすためです。
ログとファイルの中身を確認する
サーバーの状態を把握するには、ログファイルを読む操作が不可欠です。
cat — ファイルの全文を表示する
cat /etc/hostname # ファイルの内容を表示
cat -n /etc/nginx/nginx.conf # -n: 行番号付きで表示
cat は短いファイルに向いています。ログファイルのように数千行あるファイルには、次の less を使います。
less — 長いファイルを安全に読む
less /var/log/syslog # ファイルをページ送りで閲覧
less 内の操作:
| キー | 動作 |
|---|---|
↑ / ↓ | 1行ずつ移動 |
Space | 1ページ次へ |
b | 1ページ前へ |
q | lessを終了 |
/キーワード | ファイル内検索 |
less はファイルを編集できないため、閲覧中に誤操作してファイルを壊す心配はありません。
ただし、less の中で v を押すと vi エディタが起動します。vi が開いてしまった場合は ESC キーを押してから :q! と入力して Enter を押すと終了できます(vi の終了方法は後述します)。
grep — テキストを検索する
grep "error" /var/log/nginx/error.log # ファイル内を検索
grep -i "error" /var/log/nginx/error.log # -i: 大文字小文字を区別しない
grep -n "error" /var/log/nginx/error.log # -n: 一致した行番号を表示
ls | grep config # パイプでコマンド出力を絞り込む
|(パイプ)は左のコマンドの出力を右のコマンドに渡す記号です。ls | grep config は「ファイル一覧のうち config という文字を含むものだけ表示する」意味になります。
tail -f — ログをリアルタイム監視する
tail -n 50 /var/log/nginx/access.log # 末尾50行を表示
tail -f /var/log/nginx/error.log # リアルタイムでログを追跡
tail -f /var/log/nginx/error.log | grep ERROR # エラー行だけをリアルタイムで表示
デプロイ後のエラー確認は tail -f が定番です。Ctrl+C で監視を停止します。
テキストファイルを編集する
nano — 情シス担当に推奨するエディタ
設定ファイルの変更が必要な場面では、nano を使います。モード切り替えが不要で、画面下部に操作方法が常時表示されるため、初めてでも直感的に操作できます。
nano /etc/nginx/nginx.conf # ファイルを開く
nano 内の操作:
| キー | 動作 |
|---|---|
Ctrl+O | ファイルを保存(O = Write Out) |
Enter | 保存先ファイル名を確定 |
Ctrl+X | nano を終了 |
編集前には必ず cp でバックアップを作成してから開始します。
vi(vim)の最低限 — 終了方法だけ覚える
vi または vim は多くのサーバーに標準でインストールされています。意図せず開いてしまったときのために、終了方法だけ覚えておきます。
# vi に入ってしまったとき
ESC # まずEscキーを押してコマンドモードに戻る
:q! # 保存せずに終了(変更を破棄)
:wq # 保存して終了
ESC → :q! → Enter の順で押せば、どんな状態からでも終了できます。
プロセスとリソースを確認する
「Webサービスが重い」「アプリが止まっている」という状況では、プロセスの確認が起点になります。プロセスとは、サーバー上で動いているプログラムの1つ1つのことです。各プロセスにはPID(プロセスID)という識別番号が割り当てられています。
ps aux — 動いているプロセスを一覧表示する
ps aux # 全プロセスを表示
ps aux | grep nginx # nginx に関するプロセスだけ絞り込む
主要な列の意味:
| 列 | 意味 |
|---|---|
PID | プロセスID(killコマンドで使う) |
USER | プロセスを実行しているユーザー |
%CPU | CPU使用率 |
%MEM | メモリ使用率 |
COMMAND | 実行中のコマンド名 |
top — リアルタイムでCPU・メモリを監視する
top
# q で終了
top を起動すると、CPU・メモリ使用率が高いプロセスが上位に表示され、数秒ごとに更新されます。サーバーが重い原因を特定するときに使います。q キーで終了します。
なお、htop はより見やすいインタラクティブな表示が可能ですが、標準ではインストールされていないため別途 sudo apt install htop が必要です。
kill — プロセスを止める
kill 1234 # PID 1234 のプロセスを通常停止
kill -9 1234 # PID 1234 のプロセスを強制停止
PIDは ps aux の出力から確認します。通常停止(シグナルなしの kill)は、プロセスに「終了してください」と伝えて後処理を待ちます。これで止まらない場合のみ kill -9(強制停止)を使います。強制停止は後処理をスキップするため、データ破損のリスクがあります。
権限を理解する
「Permission denied」というエラーは、権限不足を意味します。ファイルのアクセス権を正しく扱えると、このエラーを自分で解決できます。
sudo — 管理者権限でコマンドを実行する
sudo apt update # 管理者権限が必要なコマンドの前に付ける
sudo -i # rootシェルに切り替える(注意)
exit # rootシェルから一般ユーザーに戻る
sudo は必要なコマンドの前だけに付けます。sudo -i でrootシェルに入ると全コマンドが管理者権限で実行されるため、誤操作の影響が大きくなります。rootシェルに入った場合は、作業が終わったらすぐ exit で戻ります。
chmod — ファイルの権限を変更する
権限は3桁の数値で表します。
| 数値 | 権限の意味 |
|---|---|
4 | 読み取り(r) |
2 | 書き込み(w) |
1 | 実行(x) |
3桁の各桁が「所有者」「グループ」「その他」の権限を表します。
chmod 755 script.sh # 所有者: rwx / グループ: r-x / その他: r-x(実行可能スクリプト)
chmod 644 config.txt # 所有者: rw- / グループ: r-- / その他: r--(設定ファイル標準)
chmod 600 ~/.ssh/id_rsa # 所有者: rw- / グループ: --- / その他: ---(SSH秘密鍵に必須)
chmod u+x script.sh # 所有者(u)に実行権限(x)を追加
SSH秘密鍵のパーミッションが 600 でない場合、SSHクライアントはセキュリティ上の理由で接続を拒否します。「Permission denied」が出たときは秘密鍵のパーミッション確認が出発点です。
chown — ファイルの所有者を変更する
chown user:group file.txt # 所有者とグループを変更
chown -R www-data:www-data /var/www/html # -R: ディレクトリ内を再帰的に変更
Webサーバー(Nginx/Apache)が www-data ユーザーで動いている場合、Webコンテンツの所有者を www-data に合わせないと「Permission denied」でファイルが読めません。
パッケージを管理する
ツールを追加インストールするときは apt を使います(Ubuntu/Debian系の場合)。
sudo apt update # パッケージリストを最新に更新(必ず先に実行)
sudo apt install パッケージ名 # パッケージをインストール
sudo apt upgrade # インストール済みパッケージを更新
sudo apt remove パッケージ名 # パッケージを削除(設定ファイルは残る)
sudo apt purge パッケージ名 # パッケージを設定ファイルごと削除
sudo apt autoremove # 不要な依存パッケージを自動削除
apt update はインターネット上のパッケージリストを取得するだけで、実際のインストールは行いません。install の前に必ず update を実行する順序を守ります。
CentOS/RHEL系のサーバーでは apt の代わりに yum または dnf を使います。
WindowsユーザーがLinuxで詰まりやすい5つの違い
Windowsの感覚でLinuxを操作すると、予期しない動作に遭遇します。事前に理解しておくと、原因特定にかかる時間が大幅に減ります。
1. パス区切り文字
Windowsは \(バックスラッシュ)、Linuxは /(スラッシュ)です。
# Windows
C:\Users\user\Documents
# Linux
/home/user/documents
2. ファイル名の大文字・小文字
Linuxはファイル名の大文字と小文字を区別します。Config.txt・config.txt・CONFIG.TXT は3つの別ファイルです。コマンドも同様で、ls は動きますが LS はエラーになります。
3. 改行コード
Windowsの改行コードは CR+LF(\r\n)、Linuxは LF(\n)のみです。Windowsのメモ帳でシェルスクリプトを書いてLinuxに持ち込むと、改行コードの違いでスクリプトが正常に動作しないことがあります。
変換が必要な場合は dos2unix コマンドを使います(sudo apt install dos2unix で入手可能)。
dos2unix script.sh # WindowsのCR+LFをLinuxのLFに変換
この違いについては mekou.com の Linux Magazine で詳しく解説されています。
4. ゴミ箱がない
rm で削除したファイルはゴミ箱に入らず、即時かつ完全に削除されます。復元ツールも基本的には使えません。削除前に ls で対象を確認し、cp でバックアップを取る習慣が唯一の防衛策です。
5. テキストエディタのモード
Windowsのメモ帳は起動した瞬間から文字を打てますが、vi(vim)にはモードがあります。起動直後はコマンドモード(文字入力不可)で、i キーを押すと挿入モード(文字入力可)に切り替わります。この概念を知らないまま vi を開くと、操作不能に見える状態に陥ります。
情シス担当には nano を使うことを推奨します。vi(vim)を開いてしまったときは ESC → :q! → Enter で終了できます。
SSH接続で起きがちなエラーと対処法
Permission denied (publickey) が出たとき
SSH鍵認証に失敗しているときに表示されます。原因は大きく3つです。
原因1: 秘密鍵のパーミッションが正しくない
chmod 600 ~/.ssh/id_rsa # 秘密鍵のパーミッションを修正
ls -la ~/.ssh/ # 修正後に確認
SSH秘密鍵のパーミッションは 600(所有者のみ読み書き可)でなければなりません。これ以外の設定ではSSHクライアントが鍵を使用しません。phoenixnap.com のKB でも同様の手順が記載されています。
原因2: 公開鍵がサーバーに登録されていない
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server # 公開鍵をサーバーに登録
原因3: 鍵のペアが一致していない
ssh -v user@server # -v: 詳細ログを表示してデバッグ
ssh-keygen -lf ~/.ssh/id_rsa # 秘密鍵のフィンガープリントを確認
ssh -v を付けて実行すると接続のどのステップで失敗しているかが表示されます。
Connection timed out が出たとき
クライアントがSSHサーバーへのネットワーク接続を試みたが、サーバーが応答しなかった状態です。DigitalOcean の公式ドキュメント では以下の確認順を推奨しています。
# 1. IPアドレスとポートが正しいか確認
ssh [email protected] -p 22
# 2. ファイアウォールでポート22が許可されているか確認(サーバー上で)
sudo ufw status
# 3. SSHサービスが動いているか確認
sudo systemctl status sshd
ファイアウォールのデフォルトポリシーが DROP になっていてポート22が許可されていない場合、接続タイムアウトになります。VPSの管理コンソール(DigitalOcean・さくら・ConoHaなど)から直接ファイアウォール設定を確認します。
Connection refused が出たとき
SSHサービスが停止しているか、デフォルトのポート22以外で動いている場合に表示されます。
# SSHサービスの状態を確認(VPSコンソールから実行)
sudo systemctl status sshd
# デフォルトポートが変更されている場合
ssh user@server -p 2222 # -p でポート番号を指定
VPSのコントロールパネルのWebコンソールからサーバーに直接アクセスし、SSHサービスの状態を確認します。
作業前後のチェックコマンドセット
SSH接続直後に以下のコマンドを実行する習慣をつけると、作業環境の状態を把握した上で操作を始められます。
# SSH接続直後の定番確認セット(コピーして使用可)
whoami # 自分のユーザー名を確認
hostname # 接続先サーバー名を確認
pwd # 現在のディレクトリを確認
ls -la # ディレクトリ内容を確認
df -h # ディスク空き容量を確認(-h: 人間が読みやすい単位)
free -h # メモリ使用量を確認(-h: 人間が読みやすい単位)
sudo systemctl status sshd # SSHサービスが動いているか確認
ログ監視とエラー抽出の組み合わせ:
# Nginxのエラーログをリアルタイム監視しながらERRORだけ抽出
tail -f /var/log/nginx/error.log | grep "ERROR"
# 設定ファイルを変更する前のバックアップ作成
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
これだけ覚えれば、上司から頼まれたサーバー確認作業で止まることは大幅に減ります。
Bashの基本操作は習得できました。ただし、複数サービスが連携する構成になると、Bashの操作知識だけでは対処できない問題が出てきます。Nginxのバーチャルホスト設定ミス・cronの相対パス問題・UFWとCloudflareの組み合わせ設定など、構成全体の設計が絡む問題は、1箇所の設定ミスがサービス停止に直結します。設定ミスが起きてから復旧する工数と、事前に構成相談する工数を比較すると、後者の方が大幅に小さくなります。
InfraDBでは、VPS初期構築・セキュリティ設定(UFW・Fail2Ban・SSH鍵設定)・cron自動化設計などのサーバー構築と個別相談を受け付けています。