root のまま使い続けてはいけないのですか？

root で実行したものはすべて、タイプミスでさえシステム全体を壊しかねません。ボットはまず 'root' というユーザー名を試すので、root ログインを無効にすると最も狙われる標的が消えます。名前付きユーザーと sudo の組み合わせなら、特権コマンドの前に一呼吸置けて、実行内容の記録も残ります。

自分を締め出してしまったら？

ダッシュボードの Web コンソールを使ってください。SSH が壊れていてもファイアウォールに遮られていても動くので、ログインして sshd_config を直せます。root セッションを閉じる前に新しいユーザーをテストするのもそのためです。

パスワードなしの sudo を許可すべきですか？

人が使うアカウントならパスワード入力は残してください。SSH 鍵が漏れたときの最後の防衛線です。パスワードなしの sudo は、自動化用の専用デプロイユーザーに、本当に必要なコマンドだけに絞って与えるなら妥当です。

Debian サーバーに sudo コマンドがありません。なぜ？

最小構成の Debian イメージには入っていないことがあります。root で 'apt install -y sudo' を実行してインストールし、そのあとユーザーを sudo グループに追加してください。

どの SSH ポートを使えばいいですか？

ダッシュボードに表示されているポートです。専用 IP のプランは自分の IP の 22 番ポート、NAT プランは個別の SSH ポートを使います。

VPS で sudo ユーザーを作成し root をやめる方法

Ubuntu や Debian で root 以外の sudo ユーザーを作り、SSH 鍵を渡してテストしてから root ログインを止めます。締め出されない順番で進めます。

新しい VPS はほぼ例外なく同じように始まります。root でログインし、いくつかインストールして、1 か月後もまだ root のまま。貼り付けたスクリプトが間違ったディレクトリを消すまでは、それで回ってしまいます。sudo 付きの一般ユーザーの設定は 5 分で済みますが、コマンドより順番のほうが大事です。順番を間違えると締め出されます。

Ubuntu 22.04/24.04 と Debian 12 での安全な手順を紹介します。

1. ユーザーを作る

root で：

adduser deploy
usermod -aG sudo deploy

adduser はパスワードといくつかの任意項目を尋ねます（任意項目は Enter で飛ばして構いません）。パスワードはちゃんとしたものを。sudo のたびに入力します。最小構成の Debian イメージでコマンドがなければ、先に apt install -y sudo を実行してください。

2. SSH 鍵を渡す

いちばん簡単なのは、所有者を正しく保ったまま root の許可済み鍵をコピーする方法です。

rsync --archive --chown=deploy:deploy /root/.ssh /home/deploy

手作業でやるなら：

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

パーミッションの誤りは、鍵ログインが黙って失敗する典型的な原因です。他のユーザーが書き込める authorized_keys を SSH は無視します。

3. 何か変える前にテストする

root のセッションは開いたままにしておきます。新しいターミナルで：

ssh -p 22 deploy@203.0.113.10
sudo whoami

自分の IP とポートを使ってください。NAT プランならダッシュボードにある個別の SSH ポートです。sudo whoami が root と表示すれば成功。ログインに失敗しても、root のウィンドウが残っているので直せます。

4. root ログインを止める

いよいよ扉を閉めます。メインの設定を編集するのではなく、小さな drop-in ファイルを作ります。

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sshd -t && systemctl reload ssh

sshd -t が先に構文をチェックします。壊れた設定のまま reload するのが、コンソール頼みになる典型的なパターンです。PasswordAuthentication no は、新しいユーザーで鍵ログインが通ってはじめて意味があります。それは今テストしたとおりです。

もうひとつターミナルを開き、root が拒否され、deploy は入れることを確認します。それから古い root セッションを閉じます。

5. 任意：自動化用のパスワードなし sudo

デプロイスクリプトが確認なしで sudo を使う必要があるなら、ちょうどその分だけを許可し、それ以上は与えません。

visudo -f /etc/sudoers.d/deploy

deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

正直なところ NOPASSWD: ALL は魅力的ですが、それは盗まれた鍵がそのまま root になるという意味です。自動化が実行するコマンドだけに絞ってください。

うまくいかなかったら

ダッシュボードの Web コンソールは SSH にもファイアウォールにも依存しません。そこからログインし、/etc/ssh/sshd_config.d/ のファイルを直して reload すれば完了です。復旧の全手順は締め出された VPS に戻る方法にまとめています。

次にやること

鍵だけのログインにきちんと切り替える：SSH 鍵認証
総当たり攻撃のノイズを減らす：fail2ban
残りの基本は新しい VPS のセキュリティチェックリストで押さえる

各プランのアクセス方法はアクセスのドキュメントにあります。$3 の Nano でも root 以外のユーザーを用意する価値があります。これほど安いセキュリティ強化はありません。