サーバ構築編#3
Ubuntu初期設定-ユーザ作成とSSH接続の強化

SSHでサーバへ接続して、Ubuntu Server 24.04.1LTSの主にユーザ作成とSSH接続の強化

初回公開日2025/6/20

最終更新日2025/6/23

サーバ構築編第3回からはWebサーバにSSHで接続して、初期設定を進めていきます。パッケージの更新、ユーザ作成、SSH接続の強化、SSH強化に伴うファイヤーウォールの設定を行います。

サーバ構築編第2回までで作成、設定した下記の内容を利用しますので、事前に用意してください。

秘密鍵ファイルとパスフレーズ
WebサーバのグローバルIP
デフォルトユーザはubuntuのパスワード

1.初期インストール済みパッケージの更新

SSHでWebサーバへ接続

まず、ローカルPCでWebサーバの公開鍵を作成した際にダウンロードした秘密鍵ファイルを用意します。秘密鍵ファイルのパーミッションを確認して、400でなければchmodコマンドでパーミションを変更します。秘密鍵ファイルがローカルPCのホームディレクトリにある場合は下記のコマンドになります。

bash

chmod 400 ~/filename.pem

ホームディレクトリ以外に秘密鍵ファイルがある場合は、パスの~部分を変更してご利用ください。秘密鍵を使ったsshコマンドは下記のようになります。

bash

ssh -i "~/filename.pem" ubuntu@xxx.xxxx.xxx.xxx

私の環境は「さくらのクラウド」なのでデフォルトユーザubuntuになります。「xxx.xxxx.xxx.xxx」の箇所はWebサーバのグローバルIPになります。初めて、SSHする際は下記のような警告が出る場合があります。

bash

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

上記のメッセージが表示された際は、「yes」と入力すると次回からは表示されなくなります。ちなみに上記のメッセージは「SSHクライアントが接続先のサーバのホスト鍵を初めて見るため、その真正性を確認できないという警告」になります。「yes」を入力すると、一旦コネクションを閉じましたという旨のメッセージが表示されてSSH接続は終了します。

再度、SSHコマンドを実行します。接続時に下記のようにパスフレーズの入力を求められますので、公開鍵作成時に設定したパスフレーズを入力します。 Enter passphrase for key '/xxxx/xxxxx/filename.pem':

すると、下記のようなWelcomeメッセージが表示されて、SSH接続が完了したことが確認できます。

bash

Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-55-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

パッケージリストの更新

Ubuntuの設定はリポジトリ内のパッケージリストの更新から始めます。

リポジトリやパッケージ、aptコマンドについては、別途下記にまとめていますので参考に...

リポジトリ？パッケージ？ aptコマンドって？へ

sudoコマンドでroot権限でaptコマンドを利用していきます。下記のコマンドでパッケージリストの更新ができます。

bash

sudo apt update

実行すると管理パスワードを求められるので、サーバ作成時に設定した管理者パスワードを入力します。すると、下記のようにパッケージリストが更新されます。まだubuntu serverだけしかインストールされていない状態なので、ubuntuのパッチ関連のリストだけが更新されます。

bash

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Get:3 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:4 http://archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:5 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Components [151 kB]
Get:6 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 Components [364 kB]
Get:7 http://security.ubuntu.com/ubuntu noble-security/main amd64 Components [8,980 B]
Get:8 http://archive.ubuntu.com/ubuntu noble-updates/restricted amd64 Components [212 B]                          
Get:9 http://archive.ubuntu.com/ubuntu noble-updates/multiverse amd64 Components [940 B]
Get:10 http://archive.ubuntu.com/ubuntu noble-backports/main amd64 Components [208 B]         
Get:11 http://archive.ubuntu.com/ubuntu noble-backports/universe amd64 Components [20.0 kB]
Get:12 http://archive.ubuntu.com/ubuntu noble-backports/restricted amd64 Components [216 B]      
Get:13 http://archive.ubuntu.com/ubuntu noble-backports/multiverse amd64 Components [212 B]
Get:14 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Components [51.9 kB]    
Get:15 http://security.ubuntu.com/ubuntu noble-security/restricted amd64 Components [212 B]
Get:16 http://security.ubuntu.com/ubuntu noble-security/multiverse amd64 Components [212 B]
Fetched 976 kB in 2s (431 kB/s)                          
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
138 packages can be upgraded. Run 'apt list --upgradable' to see them.

Run 'apt list --upgradable' to see them.の

bash

apt list --upgradable

を実行すると下記のように更新が可能なパッケージのリストが表示されます。実際には更新されません。

bash

Listing... Done
apparmor/noble-updates 4.0.1really4.0.1-0ubuntu0.24.04.3 amd64 [upgradable from: 4.0.1really4.0.0-beta3-0ubuntu0.1]
apport-core-dump-handler/noble-updates 2.28.1-0ubuntu3.3 all [upgradable from: 2.28.1-0ubuntu3.1]
apport/noble-updates 2.28.1-0ubuntu3.3 all [upgradable from: 2.28.1-0ubuntu3.1]
base-files/noble-updates 13ubuntu10.2 amd64 [upgradable from: 13ubuntu10.1]
bpftrace/noble-updates 0.20.2-1ubuntu4.3 amd64 [upgradable from: 0.20.2-1ubuntu4]
bsdextrautils/noble-updates 2.39.3-9ubuntu6.2 amd64 [upgradable from: 2.39.3-9ubuntu6.1]
bsdutils/noble-updates 1:2.39.3-9ubuntu6.2 amd64 [upgradable from: 1:2.39.3-9ubuntu6.1]
cloud-initramfs-copymods/noble-updates 0.49~24.04.1 all [upgradable from: 0.48]
cloud-initramfs-dyn-netconf/noble-updates 0.49~24.04.1 all [upgradable from: 0.48]
・・以下省略

インストール済みパッケージの更新

続いてパッケージの更新を行います。

bash

sudo apt upgrade -y

実行すると下記のようにログが展開されます。

bash

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  python3-boto3 python3-botocore python3-dateutil python3-jmespath python3-packaging python3-s3transfer

・・省略・・

Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart getty@tty1.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

User sessions running outdated binaries:
 ubuntu @ session #567: apt[29919], sshd[27332]
 ubuntu @ user manager service: systemd[27342]

No VM guests are running outdated hypervisor (qemu) binaries on this host.

再起動が保留されているサービスや古いバイナリで動いているユーザーセッションが表示されますので、サーバ自体を再起動してしまいます。本番運用中ですと、気軽に再起動はできないので、個別にサービスを再起動して、SSHの再接続することになります。

ここではサーバを再起動

bash

sudo reboot

しばらくしたら、SSHで再接続します。

2.ユーザ作成

「さくらのクラウド」はデフォルトubuntuになっているので、このまま運用すると危険です。そこで、SSH接続する管理者ユーザを作成します。

パスワードルールの強化

早速、ユーザを作成していきたいところですが、まずはパスワードルールを定めます。 SSHは秘密鍵を利用するのですが、管理者権限でコマンドを実行する時などを考慮すると最低限のルール強化を行なっておく方が安全です。

○pwquality.conf でポリシーを設定

パスワードの強度を上げたい場合、/etc/security/pwquality.conf を編集します。

bash

sudo vi /etc/security/pwquality.conf

設定例：

bash : pwquality.conf

minlen = 12        # 最低12文字
minclass = 4       # 4種類のうち最低4種類を含む（大文字・小文字・数字・記号）
dcredit = -1       # 最低1つの数字を含む
ucredit = -1       # 最低1つの大文字を含む
lcredit = -1       # 最低1つの小文字を含む
ocredit = -1       # 最低1つの特殊文字を含む
retry = 3          # adduserとpasswd実行時のリトライ数

設定例（３種類の文字種で構成する場合）：

bash : pwquality.conf

minlen = 12       # 最低12文字
minclass = 3      # 4種類のうち最低3種類を含む（大文字・小文字・数字・記号）
dcredit = 0       # 数字を任意
ucredit = 0       # 大文字を任意
lcredit = 0       # 小文字を任意
ocredit = 0       # 特殊文字を任意
retry = 3         # adduserとpasswd実行時のリトライ数

各設定値はデフォルトでは全てコメントアウトされている状態なので=0を設定する場合は、コメントアウト状態のままでも同じ意味となります。また、ocreditの特殊文字についてどんな記号が使えるのか調べてみたら、pwqualityはC言語の ispunct()で記号の判定していました。OS やロケール（LC_CTYPE）によって ispunct() の判定が変わる可能性はありますが、ほとんどの環境では ASCII 標準の下記の記号が使えると思われます。

bash

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

retryはユーザ作成時やパスワード変更時に使用されます。パスワードルールで弾かれた時にリトライ可能になるので設定しておくと便利です。もし、retry = 5などと設定した場合、/etc/pam.d/common-passwordのデフォルト値のretry = 3との重複が問題になります。 /etc/pam.d/common-passwordのretryはパスワード変更時に利用されるルールですが、/etc/security/pwquality.conf のretryよりも優先されます。したがって、基本的に/etc/security/pwquality.conf でretryを設定した場合は、/etc/pam.d/common-password側のretryは削除しておきます。

bash

sudo vi /etc/pam.d/common-password

diff : common-password

- password        requisite                       pam_pwquality.so retry=3
+ password        requisite                       pam_pwquality.so

○faillock.conf でログイン失敗制限

もう一点、ログイン失敗時の制限も付け加えます。多くのサーバーでは、パスワードの試行回数を制限するのがベスト。 /etc/security/faillock.confでその制限が行えます。

bash

sudo vi /etc/security/faillock.conf

設定例：ログインやsuコマンドのユーザ切り替えで、5回連続で間違えると、10分間ログインできなくなる！

bash : faillock.conf

deny = 5           # 5回失敗でアカウントをロック
unlock_time = 600  # 10分間ロック

○sudoコマンドにもパスワード失敗制限を適用

注意！この設定は管理者が一人だけの場合、ロックがかかり操作できなくなる可能性があります。複数の管理者がいるか、「さくらのクラウド」のように別途管理画面のコンソールでログインできる状態である場合にのみ、進めることをお勧めします

デフォルトの状態ですとsudoコマンド時のパスワードチェックには失敗制限は適用されません。 sudoにもfaillockを適用するには、下記のようにします。

/etc/pam.d/sudo に pam_faillock.so を追加

bash

sudo vi /etc/pam.d/sudo

下記の2行を@include common-authの直前に追加

bash : sudo

・・省略・・

# ここから追加！
auth required pam_faillock.so preauth
auth required pam_faillock.so authfail
# ここまで追加！

@include common-auth

○faillock.conf でログイン失敗時のロック状態を確認

bash

faillock   #自分がロック状態かを確認

sudo faillock  #ロック状態のユーザリストを表示

○faillock.conf でログイン失敗時のロック状態を解除

bash

sudo faillock --user <ロックされたユーザー名> --reset

管理ユーザの作成

ubuntuユーザはデフォルトユーザとして一般に知られているユーザです。このままでは、セキュリティ的にあまりに脆弱なので、別途管理者ユーザを作成して、最終的にubuntuではSSH接続できないようにしていきます。

あれ？ rootについては？という方はこちらも参考にしてください。ユーザubuntuとrootの違い

ユーザ名の規則は特に設けないのですが、区切りがある場合はアンダースコアを用いることにしています。シェルやコマンドラインでの使用が多い場合は、アンダースコアを使用する方が無難です。ハイフンだとエスケープしないといけない場面が出てくるので面倒です。

▼ユーザ作成のコマンド

bash

sudo adduser  --gecos "" username

usernameのところを任意のユーザ名に変えて利用してください。上記を実行するとパスワードを聞かれるので設定します。 --gecos ""は「Full Name」などのGECOSフィールドの入力をあらかじめスキップするためのオプションです。

▼作成したユーザをsudoが使える管理者にする

bash

sudo usermod -aG sudo username

3.SSH接続の強化

SSH接続を公開鍵認証のみにして、秘密鍵ファイルを持たないユーザは接続できないようにします。

公開鍵認証用のファイルを設置

ubuntuユーザのホームディレクトリにある認証ファイルをssh共通領域に持ってきます。

bash

sudo cp /home/ubuntu/.ssh/authorized_keys /etc/ssh/authorized_keys

cpすると下記のパーミッションと所有者となっていると思います。

bash

-rw-------   1 root root    382 Mar 11 16:47 authorized_keys

下記のコマンドでパーミッションを変更しましょう。

bash

sudo chmod 644 /etc/ssh/authorized_keys

SSH の公開鍵認証では、sshd（SSHサーバー）が authorized_keys を参照して認証を行います。各ユーザがSSH接続した際にそのユーザがauthorized_keysを読めないと秘密鍵での認証ができないので読み取り自体は誰でもできるようにしてしまいます。

`sshd_config`を変更

bash

sudo vi /etc/ssh/sshd_config

bash : sshd_config

AllowGroups sudo
AuthorizedKeysFile /etc/ssh/authorized_keys
PasswordAuthentication no
UseDNS no

sshd_configファイルは、初期状態では、ほとんどがコメントアウトされています。コメントアウトを外したり、追記したりして編集します。

AllowGroups sudo はsudoグループに所属するユーザだけにSSHを許可！特に制限を加えない場合は不要です。AllowUsersを利用すると、ユーザ単位で許可できますが、運用が大変なのでグループ単位での管理にしています。
AuthorizedKeysFile /etc/ssh/authorized_keys にすることで、すべてのユーザーがこの鍵を使う！
PasswordAuthentication no にすることで、秘密鍵なしではSSHログイン不可！これはコメントアウトを外すだけ。
UseDNS noにすることでSSHログインの高速化（DNSの逆引き処理がなくなる）これもコメントアウトを外すだけ。

下記のコマンドでsshサービスを再起動します。

bash

sudo systemctl restart ssh

再起動したら、実際に作成したユーザでSSH接続できるか試します。試す時はユーザubuntuでSSH接続しているコンソールはそのままで、別途コンソールを立ち上げて試すと、何かトラブルがあっても修正しやすいです。

bash

ssh  -i "~/filename.pem" username@xxx.xxx.xxx.xxx

xxxx.xxxx.xxx.xxxはサーバのグローバルIPです。ここまで

デフォルトユーザ`ubuntu`のSSH 接続を禁止して、SSHのポートも変更

再度、/etc/ssh/sshd_configを編集します。

bash

sudo vi /etc/ssh/sshd_config

下記を追加します。わかりやすくAllowGroups sudoの下にでも追加します。

bash : sshd_config

DenyUsers ubuntu

DenyUsersの設定はAllowGroupsよりも優先します。

また、接続ポート番号も変更しておきます。 1024番以下のポートは特権ポートなので、1024以上のポート番号を選ぶのが無難です。設定例：

bash : sshd_config

#Port 22  ← ここの `#` を外して変更！
Port 2222

まだ、SSHサービスの再起動はしません。

UFW（Uncomplicated Firewall）の有効化

UFW（ファイアウォール）でポートの開放や閉鎖が簡単にできます。デフォルトでインストールされてはいますが、有効化はされていないと思います。

まずはUFWを有効化する前に先に、既存の22と新しく設定したいポート番号(例：2222)を許可します。そうしないとUFWを有効化した時にSSH接続が切断されてしまいます。

bash

sudo ufw allow 22/tcp
sudo ufw allow 2222/tcp

その後に、下記でUFWを有効化します。

bash

sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? とSSHが切断される可能性を聞かれますが、すでにポートの解放を設定したので、yと回答します。

下記でUFWのステータスを確認します。

bash

sudo ufw status

ポートが有効になっていることが確認できます。

ここで、SSHサービスを再起動します。

bash

sudo systemctl restart ssh

sshのポート番号が変更されているか確認します。

bash

sudo ss -tlnp | grep ssh

私の環境ではここで問題が発生しました。

bash

LISTEN 0      4096               *:22              *:*    users:・・・・

上記のように22番ポートのまま。。色々と試したのですが、下記で解消しました。

bash

sudo systemctl daemon-reexec
sudo systemctl restart ssh

systemd のキャッシュが影響している可能性を疑い、systemctl daemon-reexecというsystemd 自体を再実行し、全ての管理プロセスを最新の状態にリロードするコマンドを実行して、再度SSHサービスを再起動させてみたところ、下記のようにSSHが2222番ポートで動くことが確認できました。

bash

sudo ss -tlnp | grep ssh
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    ・・・       
LISTEN 0      128             [::]:2222         [::]:*    ・・・ 

しっかりと新ポートに切り替わったことを確認しておくと安心です。

新しいユーザで新しいポートでSSH接続

別途コンソールを立ちげてSSH接続を試します。新しく設定したポートが2222の場合は下記のようなコマンドになります。

bash

ssh -p 2222  -i "~/filename.pem" username@xxx.xxx.xxx.xxx

-pでポートを指定、xxxx.xxxx.xxx.xxxはサーバのグローバルIPです。

新設したポートでSSH接続をして、問題なく接続できることを確認してください。

使用しなくなった22番ポートを閉じる

最後に不要になった22番ポートを閉じます。

bash

sudo ufw delete allow 22/tcp

bash

sudo ufw reload
sudo ufw status

これで、セキュリティレベルも少しは上がります。

以上で、ユーザ作成とSSHの強化は完了です。

4.まとめ

ここまで、Ubuntu初期設定の前半が終わった感じです。下記のように、新規の管理ユーザでSSH接続がしっかりできるようになりました。

パッケージの更新で最新パッチを当てる
ユーザパスワードのルール強化
新規の管理ユーザでデフォルトユーザubuntu利用ぜずに、サーバ運用管理を可能に
SSH接続のセキュリティを強化して安全に運用を開始

ここまでの設定は、サーバインスタンスを作成したら、早めにやった方がいい部分かなと思っています。

というのも、/var/log/auth.logを除いてみてください。あまりにたくさんのアタックがあるのではないしょうか？少なくても私の環境ですと非常に多くのアタックが記述されていました。ほとんどがrootでサーバに入ろうとしていて、Ubuntuではデフォルトでroot禁止状態なので良いのですが、初心者の私からすると、無差別にサーバに入り込もうするセッションの多さにすごく驚きました。

ですので、最低限の対策は先にやって、ゆっくり作業を進めていく方がよいかなと考えてこのような構成にしています。

次回は、Ubuntuの日本語かとロケール設定、ローカルスイッチへの接続設定、DBへの接続設定を進めていきます。

続きはこちら...

サーバ構築編#4 Ubuntu初期設定-日本語化へ

前回の確認はこちら...

サーバ構築編#2 さくらクラウドでPostgreSQLのアプライアンスDBを作るへ

この記事の執筆・編集担当

松本孝太郎

DELOGs編集部/中年新米プログラマー

ここ数年はReact&MUIのフロントエンドエンジニアって感じでしたが、Next.jsを学んで少しずつできることが広がりつつあります。その実践記録をできるだけ共有していければと思っています。

Webサーバのイーサネット設定を行いローカルスイッチとアプライアンスDBのPostgreSQL 13へのアクセスを可能に

2025/6/20公開