Ubuntu Weekly Recipe

第822回CLIだけでUbuntuを使いたい人向けのUbuntuサーバー講座2024

前々回の第820回では改めてUbuntuに入門したい人向けのUbuntuサーバー講座2024と題してUbuntu 24.04 LTSのサーバー版のインストール方法を紹介しました。もちろんUbuntuはインストールしただけで終わりではありません。豊富なパッケージ資産の利用や、自分なりの環境のカスタマイズなどを行って初めて、⁠Ubuntuを使う」状態になるのです。そこで今回は、Ubuntuサーバーを使い始めてまず実施するであろう定番の作業をいくつか紹介しましょう。

UbuntuのCLIを使えるようになると、他のLinuxディストリビューションやWSL、Raspberry Pi OSなど他の環境におけるハードルもぐっと下がります。その人の使い方に合うか合わないかは別にして、一度は経験しておくことをおすすめします。

図1 fastfetchでUbuntuの情報を表示した様子
図1

SSHサーバーの設定

インストール時にSSHサーバーを有効化していたのなら、Ubuntuサーバーにログインする方法は物理的にアクセスするコンソール接続とネットワーク越しにアクセスするSSH接続の2択になるでしょう。一般的なサーバーの用途においてコンソールを使うことは少ないため、日常的に使うのは「SSH接続」だけになるはずです。SSH接続するためにはSSHサーバーとSSHクライアントが必要になり、SSHサーバーはUbuntuそのもので、SSHクライアントはクライアントOSごとの任意のソフトウェアを使うことになります。

SSHクライアントについてはUbuntuだとデスクトップやサーバーにおいて最初からインストールされているsshコマンドを使うと良いでしょう。Windowsでも最近はOSの機能としてOpenSSHクライアントを提供していたりしますので、まずはより新しい情報にあたってみてください。一般的なsshコマンドの書式は次のとおりです。

$ ssh Ubuntuサーバーのアドレス

Ubuntuサーバー側のSSHサーバーの設定は次のようになっています。

  • 受け入れポート番号は22
  • パスワードでのrootログインは不可
  • インストール時に鍵を登録した場合はパスワードログイン不可
  • 起動後にSSHログインしない限りSSHサーバーは立ち上がらない

基本的にはこの設定を変える必要性はそこまで高くありません。もしそのサーバーがインターネットに公開されるのであれば、ポート番号ぐらいは変えておくと不正アクセスを試みようとするログが減って良い、ぐらいでしょうか。ただし個別の環境ごとに設定を変更したいことはあるでしょう。

ちなみに最後の項目ですが、これはここ数年以内の変更点のひとつです。従来のUbuntuではサーバーが起動すると常にSSHサーバーが起動し、常駐していました。しかしながらコンテナや組み込み環境でのUbuntuの利用が増えてきた結果、必ずしもSSHサーバーが必要とは言えない状況になってきています。

そこで最近のUbuntuではssh.socketを常駐させ、ssh.socketにアクセスがあった場合にのみSSHサーバーを起動する仕組みを取っています。基本的にユーザーはこれを意識することはなく、システム起動後の初回ログイン時にのみ若干時間がかかることがある程度の違いです。

SSHサーバーの設定ファイル

まず、SSHサーバーの設定は次の2箇所にわかれています。

  • /etc/ssh/sshd_config.d/*.conf
  • /etc/ssh/sshd_config

SSHサーバーの設定ファイルは「設定キーとその値」の組み合わせで設定します。Match文など一部に制御構造的なものはあるのですが、基本的には設定キーと値の組み合わせだと思っておけば大丈夫です。重要なのは最初に登場した設定キーのみが使われることです。つまり同じ設定キーに対して異なる値を2回書いても、一部の特殊な設定を除いて上書きされません。

PermitRootLogin prohibit-password  # この行の設定のみが採用される
PermitRootLogin yes                # この行の設定は無視される

/etc/ssh/sshd_configの設定キーはほとんどがコメントアウトされています。よってもし何か設定を変更したければ/etc/ssh/sshd_config.d/以下に適当な名前.confというファイルを作ってそこに設定値を書くことをおすすめします。ちなみに/etc/ssh/sshd_config.d/*.confは、/etc/ssh/sshd_configの冒頭で読み込んでいるため、/etc/ssh/sshd_config.d/*.confに記述した設定は常に/etc/ssh/sshd_configより優先されます。

たとえば「パスワードログイン不可PasswordAuthentication no⁠」の設定は、インストーラーが/etc/ssh/sshd_config.d/50-cloud-init.confを作って実現しています。

$ sudo cat /etc/ssh/sshd_config.d/50-cloud-init.conf
PasswordAuthentication no

公開鍵の追加方法

SSHでは一般的に公開鍵認証方式を用いてログインします。このときSSHサーバーにログインしようとするユーザーは手元に秘密鍵を持っておく必要があり、ログイン先のSSHサーバーには公開鍵が登録されていなくてはなりません。

このあたりの基本的な使い方は第40回のクライアント・サーバ環境の活用(1)や第53回のsshの活用などを参照してください。いずれも古い記事ではあるのですが、基本的な使い方はそこから大きくは変わっていません。最低限知っておくべきことは以下の2点です。

  • 秘密鍵・公開鍵のペアはssh-keygenコマンドで生成する
  • サーバーへの公開鍵のコピーはssh-copy-id -i 公開鍵ファイル サーバーのアドレスで行う

GitHubやLaunchpadに公開鍵を登録している場合は、サーバー側でssh-import-id プロトコル:ユーザー名を実行するとインターネット経由で公開鍵を取り込めます。⁠プロトコル」はGitHubならgh⁠、Launchpadならlpです。

ちなみに最新のUbuntuでは、FIDOなどに対応したセキュリティキーを用いたSSHログインも可能です。詳細は第620回のUbuntu 20.04 LTSでU2F/FIDOデバイスを使ったSSHの2要素認証を試すなどが参考になるでしょう。

シリアルコンソールログイン

SSHログインの最大の弱点は、⁠何らかのミスやトラブルによってサーバーがネットワークから切断されたらログインできなくなる」ことです。ご家庭用のサーバーであれば、マシンにディスプレイとキーボードを接続して復旧を試みることになるわけですが、遠隔地にあるサーバーだとそういうわけにも行きません。片道数時間をかけてLANケーブルをつなぎ直しに、もしくは設定を戻しに行ったなんて苦い経験のある読者も多いのではないでしょうか。

サーバー用に作られたマシンであれば、大抵の場合はIPMIなどを利用したシリアルコンソールが備わっています。いざという時のためにシリアルコンソールからもログインできるようになっていると安心です。Ubuntuにおけるシリアルコンソールに関しては第638回のiUbuntuに『普通に』ログインするいろいろな方法を参照してください。

ログイン時に表示されるあれやこれや

Ubuntuに初めてログインすると、次のようにさまざまな情報が表示されます。

図2 ログイン時に表示されるさまざまな情報
図2

これは初心者にとっては参考になる情報のポインタがありますし、ロードアベレージやストレージの使用量など注意すべき項目も多く存在します。しかしながらログインするたびにこれを表示されるのは若干面倒ですし、シリアルコンソールのような「遅い」環境だと、この表示だけでしばらく待たされてしまいます。

このあたりの情報は、管理者側の設定で個別に表示・非表示をコントロール可能です。詳細な設定については第755回のUbuntuにおけるMOTDの仕組みのすべてを参照してください。

管理者権限を取得する方法

Ubuntuでは昔からrootアカウントを「ロック」しています[1]。rootアカウントそのものは存在するものの、そのままではrootアカウントではログインできず、必ずsudoコマンドを経由して、特権を確保することが求められます。

これは主に「ユーザーが操作を誤ってシステムを壊してしまう」可能性をできるだけ排除し、特権ユーザーによる処理をログに残すことが目的です。また、サーバーのように複数のユーザーが管理者権限を持つ場合も、rootアカウントを共用するよりも、sudoを実行できるユーザーを設定するほうが安全です。

結果的にUbuntuでのCLI操作において、管理者権限が必要な処理を行う場合は。sudo コマンドを実行することになります。

基本的なコマンドフォーマット
$ sudo 管理者権限で実行したいコマンド
[sudo] password for shibata: 自分のパスワードを入力

sudoコマンドの挙動は/etc/sudoers/etc/sudoers.d/などで変更できます。たとえば特定のコマンドはsudoグループに所属していなくても実行可能とか、特定のコマンドはパスワードなしで実行できるといった挙動も可能です。sudoコマンドの基本的な使い方については第410回のあなたの人生を少しだけ豊かにするsudoの使い方にて紹介していますので、そちらを参照してください。

ネットワーク設定の基本

Ubuntuサーバーを十分に使いこなすためには、インターネットへの接続が必要です。最近のPCは、LANケーブルを繋ぐだけでネットワークに接続できますし、特に設定しなくてもインターネットに繋がっているはずです。ただし、サーバーの場合は固定IPアドレスを割り振らないといけないとか「特殊なネットワーク設定が必要」なんてこともままあります。

Ubuntuサーバーにおけるネットワーク設定はNetplanによって行います。Netplanはネットワーク設定のラッパーツールで、YAMLフォーマットで記述した設定内容をシステムに合わせてネットワーク設定に変更してくれます。Ubuntuサーバーをインストールした直後であれば、次のような設定が行われていることでしょう。

$ sudo cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp5s0:
            dhcp4: true
    version: 2

これはシンプルに「enp5s0」なネットワークインターフェースについて、DHCPv4だけが有効化されている状態です。これでシステム起動時に「enp5s0」に対してIPv4アドレスが割り当てられます。DHCPv6は有効化されていませんが、一般的な環境であればRAによってIPv6アドレスも割り振られることでしょう。

Netplanでは/etc/netplan/*.yamlなファイルが順番に読まれて設定として反映されます。ちなみに後で読まれたファイルで設定を上書きできる方式です。よって「enp5s0」に対してDHCPv4ではなく固定IPアドレスを設定したい場合は、インストール時に自動生成された/etc/netplan/50-cloud-init.yamlを直接編集するのではなく、/etc/netplan/70-fixed-ip-address.yamlのようなファイルを作って、そこに設定を記述することをおすすめします。

$ sudo cat /etc/netplan/70-fixed-ip-address.yaml
network:
    ethernets:
        enp5s0:
            dhcp4: false
            addresses:
                - 10.10.10.2/24
    version: 2
$ sudo chmod 600 /etc/netplan/70-fixed-ip-address.yaml

これで後者のファイルによって固定IPアドレスが設定できるというわけです。実際の適用には次の様なコマンドを行います。

お試しで適用する方法。tryを実行後に120秒以内にapplyしなければ自動でロールバックする
$ sudo netplan try

設定ファイルの内容を適用する
$ sudo netplan apply

ネットワーク設定を間違えると、リモートからログインできなくなることがあります。そこでまずは「netplan try」で設定を適用し、本当にログインできるかを確認します。問題なさそうなら「netplan apply」で設定を反映すると良いでしょう。ちなみにtryを実行後に120秒以上放置すると、自動的に元の設定にロールバックします。

ただしロールバック自体も完璧ではありません。うまく設定が元に戻らず、ネットワーク経由のログインができなくなった事態に備えて、シリアルコンソールなど別のログイン手段を用意しておくことを強くおすすめします。

Netplanの細かい設定例については、Netplan公式のサンプル集が参考になるでしょう。

パッケージ管理システムとセキュリティアップデートの方法

一度ログインできるようになり、インターネットにも接続できるようなったら、パッケージ管理システムの使い方とセキュリティアップデートの方法を学ぶことになるでしょう。Ubuntuの場合は、Debianと同じAPTシステムを採用しています。基本的な使い方は次のとおりです。

リポジトリのメタデータを最新に更新する
$ sudo apt update

インストール済みのパッケージを最新版に更新する
$ sudo apt upgrade

リポジトリからパッケージを検索する
$ sudo apt search 検索文字列

パッケージの情報を表示する
$ sudo apt show パッケージ名

パッケージをその依存関係も含めてインストールする
$ sudo apt install パッケージ名

パッケージを削除する
$ sudo apt remove パッケージ名

APTシステムではパッケージやそのメタデータを提供するサーバーを「リポジトリ」と呼びます。特に「archive.ubuntu.com」やそのミラーリポジトリはUbuntuにおいては「公式リポジトリ」と呼ばれ、Ubuntuにおける公式パッケージは基本的にこの公式リポジトリから提供されます。

ただし公式パッケージについては、次のような特徴があることに注意が必要です。

  • 一部を除いてリリース後にはバージョンが更新されることはない
  • セキュリティパッチの適用結果はバージョンだけでは判断できない

一般的なパッケージのバージョンは次のフォーマットになっています。

"パッケージの元になったバージョン"-"Debianリビジョン"ubuntu"Ubuntuリビジョン"

たとえばOpenSSHサーバーのバージョンなら次のとおりです。

$ apt policy openssh-server
openssh-server:
  インストールされているバージョン: 1:9.6p1-3ubuntu13.4
  候補:               1:9.6p1-3ubuntu13.4
  バージョンテーブル:
 *** 1:9.6p1-3ubuntu13.4 500
        500 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1:9.6p1-3ubuntu13 500
        500 http://jp.archive.ubuntu.com/ubuntu noble/main amd64 Packages

ここで言う1:9.6p1-3ubuntu13.4がパッケージのバージョンになります。1:はEpochと呼ばれるもので、オリジナルのソフトウェアのバージョンスキームが変わっても、パッケージのバージョン番号が単調増加になるよう調整する際に追加されます。

9.6p1がパッケージの元になったバージョンです。つまりOpenSSHそのもののバージョンになります。⁠リリース後はバージョンが更新されない」のはこの部分です。言い換えるとUbuntu 24.04 LTSがリリースされたときに、OpenSSHパッケージのベースバージョンが9.6p1の場合、これはUbuntu 24.04 LTSのサポートが切れるまでずっと同じままです。途中で9.7p1になったりすることはありません[2]

これはUbuntuをリリースしたあとのパッケージのバージョンアップは、他の依存ソフトウェアの影響が大きく、Ubuntuシステムの安定性に重要な問題を生じる可能性があるためです。よってセキュリティ対応や不具合修正は、⁠新しいバージョンの取り込み」ではなく、⁠パッケージの修正」というスタンスで個別に必要なパッチを適用していきます。その修正によって更新されるのが3ubuntu13.4の部分です。3がDebian側で修正した場合にインクリメントされ、ubuntu13.4がUbuntu側で修正した場合にインクリメントされます。

さて、OpenSSH 9.6p1に重大な不具合が見つかって、セキュリティパッチの適用が必要になったとします。OpenSSH側の公式アナウンスとしては「9.6p2で修正されました」となっています。しかしながらUbuntu側は正式リリースされたUbuntuに対して、新しいバージョンは取り込みません。そこで9.6p2で適用されたパッチのうち必要なものを取り出し、それをUbuntuのパッケージに適用します。この際に1:9.6p1-3ubuntu13.41:9.6p1-3ubuntu13.5に変更するというわけです[3]

かなりややこしい話ではありますが、Linuxディストリビューションを安定的に運用する上ではどうしてもこのようにパッチ単位で適用する対策を取らざるをえません。あるセキュリティインシデントがどのバージョンで修正されたかは、Ubuntu Security Noticeや、Ubuntu Weekly Topicsなどを参照することになるでしょう。

ちなみにUbuntuサーバーには、ユーザーが操作しなくても自動的にセキュリティアップデートを適用するunattended-upgradeが組み込まれています。自動アップデート機能については第671回のパッケージのアップデートとアップグレードを制御するなどを参照してください。デスクトップの話ではありますが、サーバーでも基本的な考え方は同じです。

またパッケージの更新後に再起動が必要になるかは、ターゲットとなるパッケージ次第です。基本的にはほとんどのケースで再起動は必要ないのですが、たまに再起動が必要なパッケージが複数回更新されるケースもあるので油断はできません。なお、カーネルの更新には再起動が必要になります。ただし、Ubuntu Proが提供するKernel Live Patch機能を使うとこのあたりも再起動不要になることがあります。Kernel Live Patchに関しては第443回の再起動なしにカーネルを更新する『Canonical Livepatch Service』を参照してください。

APTシステムに関する各種ノウハウや情報は、次の記事も参考になるでしょう。

snapパッケージについて

近年のUbuntuには「APTシステム」とは別のパッケージ管理システムとしてsnapパッケージシステムが導入されています。これはいわゆるユニバーサルパッケージの一種で、Linuxディストリビューションやそのバージョンを問わず単一のパッケージを使えるようにする仕組みです。

前述したようにUbuntuのパッケージは、そのリリースごとでバージョンが固定化されていました。そうせざるを得ない最大の理由が「パッケージ間の依存関係」です。あるソフトウェアをバージョンアップしようとした時、必要なライブラリ(依存ライブラリ)も最新版に更新しないといけないことは多々あります。そのライブラリを更新してしまうと、今度はそのライブラリに依存している他のパッケージが動かなくなってしまいます。APTシステムをはじめとする従来のパッケージ管理システムは、この依存関係の管理をリポジトリの管理者とパッケージのメンテナーががんばって協調することで、⁠問題なく動く環境」を実現してきました。

しかしながら近年はソフトウェア開発や品質評価の手段が進化し、セキュリティ対応の重要性も上がることで、リリース周期が短くなっています。さらにC言語がメインだった時代に比べて、多種多様なプログラミング言語が日常的に使われ、それぞれが独自のパッケージ管理システムと依存関係を持つようになってきました。

そんな現代においてパッケージ間の依存関係を「諦めて⁠⁠、ひとつのパッケージファイルの中に依存パッケージもまとめて取り込んでしまおうとしているのが「ユニバーサルパッケージ」です。この方法を取れば、ソフトウェアのバージョンはシステムのそれから独立できるため、理想的にはどのLinuxディストリビューション・どのリリースでも同じ最新のソフトウェアが使えるというわけです。さらにコンテナの仕組みも組み合わせることで、特定の機能しか使えないよりセキュアなソフトウェアになります。

このあたりはAndroidやiOSなどのスマートOSが既に実現しているパッケージと権限の関係をLinuxにも持ってこようとしていると考えれば良いでしょう。

Linuxディストリビューションでは、ユニバーサルパッケージとしてFedora等が開発しているFlatpakが有名です。ただしUbuntuでは、IoTやサーバーでも同じユニバーサルパッケージを提供したいという思いもあって、独自の「snapパッケージ」を採用しています。ここでは基本的な使い方だけお伝えしておきましょう。

パッケージを検索する
$ snap find 検索文字列

パッケージの情報を表示する
$ snap info パッケージ名

パッケージをインストールする
$ sudo snap install パッケージ名 --channel チャンネル名

パッケージを削除する
$ sudo snap remove --purge パッケージ名

インストール済みパッケージを更新する
$ sudo snap refresh

snapパッケージでは「チャンネル」という概念があり、チャンネルごとにリリース版・ベータ版などを提供できるようになっています。チャンネル未指定ならデフォルトのチャンネルが選ばれますが、指定したほうが便利なことも多々あります。

また削除時に--purgeを指定することで、インストール時のスナップショット等も削除されます。パッケージによってはスナップショットが大きい場合もあるので注意しましょう。snapパッケージについては、まだ未知数な部分が多々あります。とりあえずパッケージを作って理解を深めてみたければ、第654回のsnapパッケージング入門を参照してください。

とりあえず何かインストールしてみたいのであれば、⁠nextcloudパッケージ」をおすすめします。これはお手軽にNextcloud環境を構築する仕組みで、このパッケージをインストールするだけでWeb UIのついたオンラインストレージ環境を構築できます。また、ソフトウェアの更新は自動的に行ってくれますので、snapパッケージの利便性を一番感じられるソフトウェアでしょう。

ここまでUbuntuを使う上で最低限把握しておくとそのあとが楽になる情報をまとめてみました。より深く知るにはリンク先の情報などを参照していただく必要がありますが、軽く知っておけば良いならこの記事を流し読むだけでも大丈夫です。

おそらく実際にUbuntuサーバーを使って何かを実現するには、たとえばDockerやIncus/LXDなどのコンテナシステム・仮想マシンシステムの使い方も学んだほうが良いでしょう。公式リポジトリだけでなくサードパーティのリポジトリを使うこともあるかもしれません。Ubuntuサーバーの定番の作業については、Ubuntu Server documentationがよくまとまっているので、そちらも参照してみてください。

ぜひ何か機会があってUbuntuサーバーを触ることがあれば、まずは本記事の手順や、リンクされている記事を参考に作業を始めてみてはいかがでしょうか。

おすすめ記事

記事・ニュース一覧