Ubuntuはマルチユーザーに対応したシステムです。つまりシステムを使用する際は、ログインシステムを介して使う人が「誰であるか」を識別し、「 本人であること」を認証する必要があります。今回はUbuntuに「普通に」ログインするさまざまな方法を紹介します。
一般的なログイン方法
おそらくUbuntuを日常的に使っている人で、「 Ubuntuにログインしたことがない人」はほぼ皆無でしょう[1] 。それくらい当たり前に使っているログインシステムですが、その仕組みは想像以上に複雑です。
[1] 恐るべきことに「Ubuntuをインストールしてみたけれども、設定したパスワードがわからなくなったため、初回起動でUbuntuの利用を諦めた」というケースを聞いたことがありますので、初心者を含めるとゼロではないようです。
歴史的経緯から、一般的にローカルユーザーの情報は/etc/passwd
ファイルに記載されてはいるものの、実際のログイン時にはその方法によって/etc/passwd
以外にもさまざまな「ユーザーに関する情報データベース」にアクセスすることになります。さらにLDAPのようなリモートのアカウントサービスまで加えると、その全容を把握するには命がいくつあっても足りません[2] 。
[2] 全容を把握しようとすると、よくわからない過去の遺産・古いスタイルのコード・唐突に行われた仕様変更の跡・いきなり現れた「これまでの古いシステムを一掃し、置き換え可能であるスマートでモダンなやり方」と自称するソフトウェア・心ないマサカリなどによって、どんどんライフが削られていきます。
ただし出来合いのものをそのまま使うのであればそこまで難しくはありません。特にデスクトップ版のUbuntuであれば、PCを起動したあとに目の前に現れるであろうログイン画面にパスワードを入力するだけです。
図1 Ubuntu 20.04 LTSのログイン画面。Ubuntu 17.10からGDMへと戻り、その後も少しずつデザインが変わっている
ログインに成功したらそのユーザーの「セッション」が開始します。ここから先の流れはユーザーのセッションタイプによって異なりますが、セッションスタートアップスクリプトにしたがってX Window SystemやWaylandが起動したり、デスクトップ環境が立ち上がったり、環境変数が設定されることで、ユーザー固有の環境がシステム上に構築されます。
Ubuntuサーバーであっても、大抵はsshコマンドを使ってログインします。こちらもサーバーマシンのアドレスを指定するだけですので、特に難しいことはないでしょう。
$ ssh ubuntu@nuc.local
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-48-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
0 updates can be installed immediately.
0 of these updates are security updates.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
SSHにおけるパスワード認証と公開鍵認証
sshログインする場合、パスワード認証も可能ではありますが、できるかぎりよりセキュアな公開鍵認証を使うようにしましょう。Ubuntuの場合、LaunchpadやGitHubに公開鍵を登録しておけば「ssh-import-id
」コマンドでかんたんにサーバーに公開鍵を登録できます。
(リモートマシン上)$ ssh-import-id lp:(LaunchpadのID)
2017-11-16 21:38:48,042 INFO Authorized key ['2048', 'SHA256:hthMPCKLGShIxYq57pxS/PXXJyRFGwmh4kdRtSDnr5c', 'shibata', '(RSA)']
2017-11-16 21:38:48,044 INFO Authorized key ['2048', 'SHA256:ZtuahRXGnK6gHb2/bwBoTM2bLERVpJs8dczzeY/qpdo', 'shibata@shibata-desktop', '(RSA)']
2017-11-16 21:38:48,047 INFO Authorized key ['2048', 'SHA256:C8EoTol3lbkWtXe8Q38GGRpPZQ6HBS/LDIZfghlzP9I', 'shibata@pomera', '(RSA)']
2017-11-16 21:38:48,048 INFO [3] SSH keys [Authorized]
引数は「lp:(LaunchpadのID) 」もしくは「gh:(GitHubのID) 」のいずれかまたは複数です。もしローカルマシンの公開鍵をリモートにコピーしたいのであれば、「 ssh-copy-id
」コマンドを利用できます。
(ローカルマシン上)$ ssh-copy-id (リモートマシンのアドレス)
公開鍵認証が使えるようになれば、そのホストに対するパスワード認証は不要になります。他のユーザーやサービスがパスワード認証を使っていないのであれば、無効化してしまうのもひとつの手です。
Ubuntuサーバーであれば、次のようにパスワード認証が有効化されています。
$ grep PasswordAuth /etc/ssh/sshd_config
#PasswordAuthentication yes
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication, then enable this but set PasswordAuthentication
重要なのは最初の行です。先頭の「#
」はコメントアウトであり、SSHの設定だとコメントに初期設定値が書かれているため、「 PasswordAuthenticationが有効化されている(yes)となっている」ことがわかります。
パスワード認証を無効化するには、最初の行の先頭の「#」を削除し、「 yes」を「no」に変更してください。設定ファイルを変更したらまずは正しく書けているかテストモードでチェックしましょう。
$ sudo sshd -t
/etc/ssh/sshd_config: line 124: Bad configuration option: BadConfigurationLine
/etc/ssh/sshd_config: terminating, 1 bad configuration options
上記のようにエラーメッセージが表示される場合は、何か設定を間違えています。何も表示されなくなるまでトライアンドエラーを繰り返してください。無事に設定が完了したら、SSHサーバーの設定を再読込させます。
$ sudo systemctl reload sshd.servie
ちなみにUbuntuのSSHサーバー向けのサービスファイルには、起動・再読込の前に「sshd -t
」を実行するようになっています。
なお、SSH接続でしか到達できない環境でSSHサーバーの設定に失敗すると、お手上げです。なるべく他の方法でもサーバーに接続できるような「プランB」を用意した上で再起動することをおすすめします[3] 。
[3] プランBの候補は環境により大きく異なります。商用のリモートサーバーであれば、シリアルコンソール接続をサポートしていることが一般的です。IPMI/BMCなどのリモート管理システムが搭載されている物理サーバーならipmitoolなどのコマンドを使うという手もあるでしょう。クラウドサービスなら、インスタンスを作り直して設定を再度流し込むのが一番の近道になりそうです。
異なるユーザーでログインする
Linuxはマルチユーザーに対応したシステムなので、当然のことながら他のユーザーとしてログインすることも可能です。たとえあなたが比類なきぼっちだったとしても、Ubuntuには最初からメインユーザー以外のアカウントがいくつか登録されています。
アカウントの追加方法
もちろんシステム設定から新規にユーザーアカウントを登録することも可能です。GUIなら設定(GNOMEコントロールセンター)の「ユーザー」を開きます。画面右上の「ロックを解除」ボタンで、ユーザー変更の権限を取得したら「ユーザーを追加」ボタンを押して、アカウント名・フルネーム・パスワードを入力してください。ちなみにパスワードに関しては「次回ログイン時に決める」といった設定も可能です。
図2 ユーザーの追加ダイアログ
CLIの場合はadduser
もしくはuseradd
コマンドを使います。
adduser
Debian系なら標準でインストールされているアカウント追加コマンド。必須のオプションが未指定の場合は対話的に問い合わせる。
useradd
Linuxシステムなら大抵インストールされているアカウント追加コマンド。オプション未指定の場合は既定の値が自動設定される。
たとえばuseradd
はオプションを指定せずに実行すると、ホームディレクトリすら作ってくれません。それに対してadduser
は、オプションをほぼ指定していなくても必要最低限の環境は構築されます。Debian系のマシンにおいて手作業でアカウントを作るのであればadduser
を、より汎用的な手順にしたり自動化したいならuseradd
を検討すると良いでしょう。
adduser
でアカウントを追加するには次のように実行します。
$ sudo adduser shibata
Adding user `shibata' ...
Adding new group `shibata' (1001) ...
Adding new user `shibata' (1001) with group `shibata' ...
Creating home directory `/home/shibata' ...
Copying files from `/etc/skel' ...
New password: (パスワードを入力)
Retype new password: (上と同じパスワードを入力)
passwd: password updated successfully
Changing the user information for shibata
Enter the new value, or press ENTER for the default
Full Name []: Mitsuya Shibata
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n]
最低限必要な引数はユーザー名です。上記だと「shibata」がそれに該当します。あとはパスワードと「Full Name」を入力しましょう。他はあまり使うことがないため、未設定でも問題ありません。
adduser
はホームディレクトリや基本的な設定ファイルを一通り作ってくれるため、すぐにでもログイン可能な状態でアカウントが作られます。
$ ls -la /home/shibata/
total 16
drwxr-xr-x 1 shibata shibata 80 Oct 17 09:16 .
drwxr-xr-x 1 root root 26 Oct 17 09:14 ..
-rw------- 1 shibata shibata 12 Oct 17 09:16 .bash_history
-rw-r--r-- 1 shibata shibata 220 Oct 17 09:14 .bash_logout
-rw-r--r-- 1 shibata shibata 3771 Oct 17 09:14 .bashrc
-rw-r--r-- 1 shibata shibata 807 Oct 17 09:14 .profile
ちなみに「あるユーザーを特定のグループに追加で所属させる」場合にもadduser
コマンドが使えます。たとえばユーザー「shibata」をlxdグループに所属させるには次のように実行します。
lxdグループには未所属
$ id shibata
uid=1001(shibata) gid=1001(shibata) groups=1001(shibata)
「ユーザー名 グループ名」の順で指定する
$ sudo adduser shibata lxd
Adding user `shibata' to group `lxd' ...
Adding user shibata to group lxd
Done.
ユーザー「shibata」のサブグループとしてlxdが追加された
$ id shibata
uid=1001(shibata) gid=1001(shibata) groups=1001(shibata),118(lxd)
同じことを実現できるusermod
と比べてオプションを思い出す必要のない点が便利です。
他のユーザーへ切り替わる方法
ログイン画面からは通常のユーザー登録したアカウントでしかログインできませんが、実は端末ソフトウェアからならログインしたユーザーとは別のユーザーに「切り替わる」ことが可能です。
$ sudo -i -u ユーザー名
「-i
」オプションで指定したユーザーのログインシェルを実行します。この「ログインシェル」とは/etc/passwd
ファイルの7番目のフィールドに記述されているコマンドを意味します。「 -u ユーザー名
」は「指定したユーザー」として実行することを意味します。まとめると「指定したユーザーの権限で指定したユーザー本人のログインシェルを実行する」≒「指定したユーザーとしてログインする」ですね[4] 。
[4] サービス用にアカウントを作成したものの、ログインの必要がないユーザーについては「/usr/sbin/nologin
」や「/bin/false
」など必ず失敗するコマンドがログインシェルとして設定されています。さらにログインシェルとして特定のスクリプトを指定することで、「 ログインすると定形作業を行うアカウント」の作成も可能になります。
$ whoami
ubuntu
$ sudo -i -u shibata
$ whoami
shibata
sudo
コマンドは「-u
」オプションを省略すると暗黙的にrootとして実行します。また「-i
」オプションの代わりに任意のコマンドを書けばログインシェルではなくそのコマンドを実行します。よってsudo
は管理者権限で実行するために必要なコマンドとして認識されていることが一般的です。
「-i
」コマンドを付けるとログインシェルを実行します。これはつまり「~/.profile
」のようなユーザー固有のログインスクリプトも読み込まれるということです。そのため「ほぼ」そのユーザーがログインした環境になります。ただし環境変数などは/etc/sudoers
の設定によって引き継がれるかどうか変わるため、完全に同じになるかどうかは設定に依存します。
環境変数はそのままにユーザーだけ切り替えたい場合は「-i
」の代わりに「-s
」オプションを使います。
管理者権限で実行するシェルを起動する
$ sudo -i
#
特定のユーザー権限で特定のコマンドを実行する
$ sudo -i -u ユーザー名 コマンド名
sudo
コマンド経由で実行したコマンドは/var/log/auth.log
に誰が・いつ・どこで・何を実行したかの情報が記録されます。意図せずシステムの状態を壊してしまったときに有力な情報源となりますので、なるべくなら管理者権限が必要なコマンドはsudo
経由で実行しましょう。
リモートからグラフィカルログインする
デスクトップユーザーであっても、遠隔からネットワーク経由でログインしたいという要望が出てくるでしょう。端末操作に慣れたユーザーであれば、sshでログインして操作するのが常道です。「 X転送 over SSH」の機能を使えば(sshコマンドに-X
オプションを付けてX forwardingの機能を有効にすれば)17.10から有効になったWaylandセッションであっても、リモートマシンのXクライアントを立ち上げることは可能です[5] 。しかしながら「デスクトップ環境」をそのまま使いたいというユーザーもいるかもしれません。
いわゆるリモートデスクトップやVDIと呼ばれる機能を使う方法はいくつか存在します。Ubuntuだとよく出てくるのが次のような用語です。
もっとも簡単かつ確実に動くのがVNCを使う方法です。リモート側にVNCサーバーを、ローカル側にVNCクライアントをインストールすることになります。VNCに対応したサーバー・クライアントは各OS毎にたくさんありますので、肌に合うものを使うと良いでしょう。デスクトップ版のUbuntuにはVNCサーバーとしてVinoが、VNCクライアントとしてRemminaが最初からインストールされています。よってシステム設定の「共有」から簡単にリモートからVNC経由でのアクセスを許可できます。
まずはサーバー側の設定です。システム設定から「共有」を開いてください。
図3 右上のスライドボタンをオンにし、「 画面共有」をダブルクリックする
図4 接続可能なネットワークをオンにする
「アクセスオプション」には2種類の方法が存在します。
「新規接続の場合はアクセス要求を必要とする」はクライアントがリモートサーバーにアクセスしようとした際、「 リモートサーバー側」でアクセスを許可するかどうかの通知が表示されます。リモート側にもクライアント側にもデスクトップの前にユーザーが存在することを想定した設定です。
「パスワードを要求する」はリモートサーバーにアクセスしようとした際にクライアント側でパスワードを入力する方法です。こちらはリモートサーバー側でユーザーが接続のたびに許可する必要がないため、一人で複数のデスクトップを使うことを想定した設定です。
これで指定したネットワーク経由でリモートデスクトップできるようになりました[6] 。
[6] 同じ設定画面にある「メディア共有」はいわゆるメディアサーバー機能です。有効化したPC上の音楽や動画をネットワーク越しに配信できます。メディアサーバーにはRygelが使われます。最近のUbuntuなら最初からインストールされているはずです。SSHサーバーがインストールされているマシンなら「リモートログイン」という項目も追加されます。
クライアントは「Remmina」がインストールされています。アクテビティからRemminaを起動し、左上のドロップダウンメニューから「VNC」を選択、上記画像のアドレス(上記の例だと「ubuntu-ax2.local」 )を入力して、エンターキーを押します。
図5 接続先のデスクトップで「許可するかどうか」の通知が表示されるので「許可」を押す
上記通知は、通知の上にマウスオーバーしないと「拒否」「 許可」のボタンが表示されないので注意してください。
図6 無事にリモート接続できた
ちなみに上記の流れは、リモート側もあらかじめログインしていることが前提となります。ログイン画面も含めて転送するとなると、さらに細かい設定が必要になります。
リモートデスクトップはそれだけでひとつの大きなカテゴリーになるので、詳しいことは次のRecipeなどを参照してください。
特にリモートデスクトップは、インターネット越しに接続しようとすると、セキュリティ周りや通信効率化の設定が重要になります。環境・用途によってベストな方法は異なるため、自分好みの設定を模索してみるのも楽しいでしょう。
仮想コンソールから直接ログインする
ローカルのPCからなら「Ctrl-Alt-Fx」を押すことで別の「仮想コンソール」に切り替えられます。たとえば何らかの理由でデスクトップの操作がうまくできなくなった場合でも「Ctrl-Alt-F3」で別のコンソールに切り替えてログインすれば、デスクトップを復旧できるかもしれません。
最近のUbuntuでは最初のコンソール(/dev/tty1
)をGDMが利用し、ユーザーがグラフィカルログインすると次の未使用のコンソール(大抵は/dev/tty2
)を使用します。つまり「Ctrl-Alt-F3」を押せば、誰も使っていない/dev/tty3
に切り替わり、CLIでログインできるというわけです。元のGUIに戻るためにはCtrl-Alt-F2を押します[7] 。
ちなみにCLIのログイン画面はsystemdがagettyコマンドを起動することで管理しています。一度でも使っていない仮想コンソールに切り替わって始めてsystemdがagettyを起動する仕組みになっているのです。
ログインした環境はただのCLI環境です。またそのままだと日本語は入力はもちろん表示もできないので注意してください。一般的には緊急避難的な使い方がメインになるでしょう。もちろんきちんと準備すれば常用することも可能です。デスクトップ環境なんて重いものは不要な人にとっては心強い仕組みとなります。
シリアルコンソールからログインする
仮想コンソールはディスプレイにLinuxのコンソールを表示するための仕組みです。しかしながらUbuntuが動くコンピューターはあるものの、ディスプレイはなく、無言で渡されたのはシリアルケーブルだけ、というのも「普通にある」話です。そうなるとシリアルコンソール経由でのログインが必要になります。
Ubuntuは、デスクトップ版もサーバー版もシリアルコンソールの設定は無効化されています。よってまずはGRUBやLinuxのメッセージをシリアルコンソールに出力するための設定が必要です。詳細はUbuntuの公式ドキュメント を参照してもらいたいところではあるのですが、若干内容が古いです。そこで簡単に手順を説明しましょう。
まず設定対象のルートファイルシステムを入手します。一般的なPCのシリアルコンソールを有効化するのであれば、PCをディスプレイにつないで起動して設定する、で良いでしょう。そもそもVGAがないデバイスであれば、先にストレージやその中身であるルートファイルシステムを何か別の方法で編集できるようにしておきます。
まずはGRUBの設定です。/etc/default/grub
に以下の行を追加します。
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
「console」が仮想コンソールへの出力、「 serial」がシリアルコンソールへの出力です。両方書くことで両方に同じ内容が出力されます。ちなみにサーバーマシン等にある「シリアルコンソールリダイレクト」を有効化していると、同じデータが二重に出力されてしまうので注意してください。その場合はconsoleだけ有効化しておけば良いでしょう。
「--speed=115200
」はシリアルコンソールの速度です。環境によって異なりますのでうまく出力できない場合は速度を下げると良いでしょう。おそらく「115200」「 38400」「 9600」のいずれかは動くはずです。
さらにLinux側の設定として、同じファイルのGRUB_CMDLINE_LINUX_DEFAULT
を次のように変更します。
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"
これはLinuxのメッセージを出力する先の設定です。「 tty0」がコンソール側で「ttyS0」がシリアルコンソール側です。GRUBと同じようにコンソールとシリアルコンソールの双方に出力しています。
ちなみにUbuntuの初期設定だとこの変数には「quiet splash」が設定されているはずです。「 quiet」はカーネルの起動ログを抑制するオプションです。シリアルコンソール出力の際も有効化したい場合は、上記設定の末尾にでも追加しておいてください。「 splash」は起動時のスプラッシュスクリーンを表示するオプションです。シリアルコンソールだと動かないので、外しておいて良いでしょう。
/etc/default/grub
の設定を次のコマンドで反映します。
$ sudo update-grub
もし別システムのルートファイルシステムをマウントして作成したいなら、何か適当な仮想マシンで実行するか、chrootして「grub-mkconfig」で出力した結果を、「 /boot/grub/grub.cfg
」に保存してください。
システム側のシリアルコンソールの出力設定が完了したら、今度はクライアント側を準備します。といってもシリアルコンソールケーブルを接続したマシン上でシリアル接続ソフトウェアを動かすだけです。
まずデバイス側とPC側をシリアルコンソールケーブルで接続します。最近はシリアルポートがあるPCも少なくなってきたので、いわゆる「USBシリアルケーブル」みたいなケーブルを使うことになるでしょう。シリアルケーブルには、クロスだストレートだ、ジェンダーがどうとかいろいろやっかいな話がありますので、「 最終的にうまくつながる」までには何度も抜き差ししたり、入れ替えたりすることになります。
ソフトウェアはWindowsならTeraTermが鉄板です。Ubuntuならminicom、gkermit、screenあたりがよく使われているようです。screenなら次のように接続することになります。
$ sudo adduser $USER dialout
(設定を反映するために一度ログインし直す)
$ screen /dev/ttyUSB0 115200
シリアルコンソールデバイスは接続形態によって「/dev/ttySx
」もしくは「/dev/ttyUSBx
」「 /dev/ttyACMx
」などの名前で作られます。これらのデバイスはrootユーザーかdialoutグループでのみ読み書き可能な設定になっているので、まずはdialoutグループに所属しておくようにしておきましょう。そうしたらあとはscreenコマンドで上記のように接続できます。速度(ボーレート)が異なる場合は、最後の引数を変更してください。
ちなみにscreenを終了させるには「Ctrl-a k」を入力します。
このように「ログイン」ひとつとっても、Ubuntuには様々な選択肢が用意されています。普段のログイン生活に不満があるなら、自分にとって最良のログイン方法を模索してみるのはいかがでしょうか。