LoginSignup
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kokonutscookie

Ubuntu Server の管理でよく使うコマンドや設定のメモ

Last updated at Posted at 2024-06-26


Ubuntu Server 22.04での管理でよく使う設定やコマンドです。途中で24.04に変わっています。
1. キーボードの変更
2. DNSサーバの設定/確認
3. 固定IPの設定
4. SSH Serverの有効化
5. sshの公開鍵認証の設定
6. Timezoneの設定
7. NTPの設定
8. ホスト名について
9. bashプロンプトの設定
10. rootのパスワード
11.Active Directory ユーザとの連携
12.Desktop環境とXRDPのインストール

1.キーボードの変更

$ sudo dpkg-reconfigure keyboard-configuration

2.DNSサーバの設定/確認

Ubuntu 22.04 では、ローカル(127.0.0.53)のポート53(DNS)をsystemd-resolved.service がフックしています。

$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2024-06-26 05:38:01 UTC; 1h 6min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 837 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 2220)
     Memory: 8.9M
        CPU: 158ms
     CGroup: /system.slice/systemd-resolved.service
             └─837 /lib/systemd/systemd-resolved

Jun 26 05:38:01 ubuntu systemd[1]: Starting Network Name Resolution...
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Positive Trust Anchors:
Jun 26 05:38:01 ubuntu systemd-resolved[837]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa>
Jun 26 05:38:01 ubuntu systemd-resolved[837]: Using system hostname 'ubuntu'.
Jun 26 05:38:01 ubuntu systemd[1]: Started Network Name Resolution.
Jun 26 05:37:40 ubuntu systemd-resolved[837]: Clock change detected. Flushing caches.

また昔ながらの、/etc/resolver.conf では以下の通り、nsameserverとしてローカルの127.0.0.53を指しています。

$ more /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search example.com

それではsystemd-resolvedはがDNS query行うサーバのアドレスはどこで設定されているのでしょうか？
それは、/run/systemd/resolve/resolv.conf です。

$ more /run/systemd/resolve/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 172.24.0.11
search example.com

この例では、172.24.0.11がName Server として指定されています。このサーバでは、この段階で DHCPサーバからIPアドレスを取得する設定になっておりnameserver 172.24.0.11 はDHCPサーバのDNS情報から設定されています。
Serverなので、基本は固定IPになるので、固定IPの場合のDNSサーバの設定は、次の固定IPの設定で説明します。
<一番上>

3.固定IPの設定

まず現在のIPアドレス設定を確認します。ifconfigはサポートしていません。
かわりにip addrを使用します。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:95:9f:63 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.24.201.1/16 metric 100 brd 172.24.255.255 scope global dynamic ens160
       valid_lft 2762sec preferred_lft 2762sec

ipコマンドは他にip routeなどでルーティング情報の設定なども可能ですのでぜひ覚えましょう。
まずは、/etc/netplan/99_config.yaml を作成して設定を書き込みます。

$ sudo vi /etc/netplan/99_config.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:                              ← インターフェース名
      dhcp4: false
      dhcp6: false
      addresses: [172.24.35.16/16]      ← 固定したいIPアドレス
      routes:                            
        - to: default
          via: 172.24.1.1               ← デフォルトゲートウェイのアドレス
      nameservers:
        addresses: [172.24.0.11, 172.24.0.10]    ← DNSサーバー
        search: [share.example.com, lab.example.com, example.com]
                                                 ← DNSサーチリスト

この設定を適用するのですが、間違えていると、ネットワーク経由でアクセスできなくなったりして不都合があるので、sudo netplan tryで必ず設定を確認します。

$ sudo netplan try

** (process:13354): WARNING **: 07:50:37.690: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (generate:13356): WARNING **: 07:50:37.696: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.
WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.

** (process:13354): WARNING **: 07:50:38.148: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (process:13354): WARNING **: 07:50:38.478: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.

** (process:13354): WARNING **: 07:50:38.479: Permissions for /etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others.
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in  71 seconds
Configuration accepted.

この例では、Changes will revert in が表示されている時にエンターキーをおすとConfiguration accepted. となって設定を完了しています。
/etc/netplan/99_config.yaml are too open. Netplan configuration should NOT be accessible by others. の警告が出ていますのでこれを解決します。

sudo chmod 600 /etc/netplan/99_config.yaml

WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running. ←この警告は無視して構いません。
無視するのは気持ち悪いという場合は、sudo apt install openvswitch-switchで、(使用しない)Open vSwitchをインストールしてください。

$ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:95:9f:63 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.24.35.16/16 brd 172.24.255.255 scope global ens160
       valid_lft forever preferred_lft forever

DNSの設定も確認します。

<一番上>

4.SSH Serverの有効化

Ubuntu Server なので不要ですが、Ubuntu Desktopの場合、OSインストール後の既定ではsshdは起動していません。これを有効にします。

$ sudo systemctl enable sshd
$ sudo systemctl start sshd

<一番上>

5.sshの公開鍵認証の設定

ここでは、UbuntuのOpenSSHでの設定を説明します。

sshクライアントの設定

ユーザ毎に実行します。ここでは、userというユーザ名で実行しています。

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):   # パスフレーズを入力 
Enter same passphrase again:                  # もう一度パスフレーズを入力 
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:iLe4NIBlxVpnevX5QVBId2JpT/H167msiWDQ/Ecl55c user@ubuntu
The key's randomart image is:
+---[RSA 3072]----+
|   ..    .o+=.o..|
|   .o o . .o+o..o|
|  oo + . . + + oo|
| +. ....o o . * o|
|. . ..o.So . o E.|
|   . o .. . o . o|
|    + .  o . . o |
|   . o  . . o o .|
|    .      . o.o |
+----[SHA256]-----+

ユーザのホームディレクトリ(/home/user)の.sshディレクトリにid_rsa(秘密鍵）とid_rsa.pub（公開鍵）が作成されます。
サーバの同じユーザ(ここではuser)の~/.ssh/にクライアントで作成した公開鍵をコピーします。

クライアントからサーバにコピーする場合
$ scp ~/.ssh/id_rsa.pub serveｒ:~/.ssh/   #serverはサーバのIPもしくは名前

サーバ(sshd)側の設定

サーバ側は、クライアントで作成した公開鍵（.pub)をサーバの~/.ssh/authorized_keysに追加する作業が必要です。~/.ssh/authorized_keysは既定で存在しない（もしくは空）ファイルなのでパーミッションも適切に設定する必要があります。以前は、手動でのサーバ側設定に書いた通り一つひとつ手入力でやる方法が色々な解説で扱われていますが、今は、クライアントがopensshの場合、ssh-copy-idコマンド一発で完了します。

ssh-copy-idでのサーバ設定

クライアント上で作業します。繰り返しになりますが、クライアントがopensshの場合の方法です。

% ssh-copy-id  user@host01.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/user/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@host01.example.com's password: 

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'user@host01.example.com'"
and check to make sure that only the key(s) you wanted were added.

コマンドの結果に記載された、 ssh user@host01.example.comで結果を確認して下さい。パスワードなしで、ログインが完了すれば成功です。手動でのサーバ側設定は読み飛ばして構いません。
<一番上>

手動でのサーバ側設定

(1) 公開鍵(.pub)をサーバにコピー
サーバの同じユーザ(ここではuser)の~/.ssh/にクライアントで作成した公開鍵をコピーします。

クライアントからサーバにコピーする場合
$ scp ~/.ssh/id_rsa.pub serveｒ:~/.ssh/   #serverはサーバのIPもしくは名前

(2) authorized_keyに公開鍵をコピー
クライアントからコピーした、id_rsa.pubをauthorized_keysに追加します。

cd ~/.ssh
cat ./id_rsa.pub >>./authorized_keys

元々、authorized_keys は空のファイルですので、単純にコピーでもいいのですが、他のクライアントでも同じようにキーを作成して公開鍵認証をする場合には、公開鍵がそれぞれ違いますので、authorized_keysに追加していきます。
(3) authrized_keyの権限の設定
念の為、以下のとおりauthorized_keysのパーミッションを設定します。

$ chown user ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

これで用意は完了したので、公開鍵認証でクライアントからサーバにsshで接続します

全てのユーザ全てのクライアントで、公開鍵認証が完了したら/etc/ssh/sshd_config.d/50-cloud-init.confでPasswordAuthentication yesをPasswordAuthentication noに変更してパスワードでのｓｓｈ禁止した方がセキュリティ的には良いとされています。
<一番上>

6.Timezoneの設定

$ date
Thu Jul  4 08:06:36 AM UTC 2024
$ sudo timedatectl set-timezone Asia/Tokyo
$ date
Thu Jul  4 05:07:56 PM JST 2024

トラブルシューティング

TBD
<一番上>

7.NTPの設定

既定で、systemd-timesyncd.service が動作しています。

$ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-07-04 10:53:58 JST; 6h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 16736 (systemd-timesyn)
     Status: "Initial synchronization to time server [2620:2d:4000:1::41]:123 (ntp.ubuntu.com)."
      Tasks: 2 (limit: 2219)
     Memory: 1.3M
        CPU: 187ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─16736 /lib/systemd/systemd-timesyncd

Jul 04 10:53:58 ubuntu systemd[1]: Started Network Time Synchronization.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:56 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:58 ubuntu systemd-timesyncd[16736]: Network configuration changed, trying to establish connection.
Jul 04 10:54:32 ubuntu systemd-timesyncd[16736]: Initial synchronization to time server [2620:2d:4000:1::41]:123 (ntp.ubuntu.com).

設定ファイルは、/etc/systemd/timesyncd.confです。ntp.nict.jpを指定します。

/etc/systemd/timesyncd
[Time]
NTP=ntp.nict.jp

sudo systemctl restart systemd-timesyncd.serviceで再起動します。
timedatectl timesync-statusで確認します。

$ timedatectl timesync-status
       Server: 2001:df0:232:eea0::fff3 (ntp.nict.jp)
Poll interval: 2min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 1
    Reference: NICT
    Precision: 1us (-20)
Root distance: 0 (max: 5s)
       Offset: -17.548ms
        Delay: 5.724ms
       Jitter: 6.632ms
 Packet count: 2
    Frequency: +174.869ppm

<一番上>

8.ホスト名について

Ubuntuのホスト名の設定や確認方法について説明します。
インタネットで検索すると、hostname コマンドや、/etc/hostname、/etc/hosts などの情報が出てきますが、私はインストールが終わって最初にログインした時にhostnamectl set-hostname fqdnでホスト名＋ドメイン名の名前を設定することをお勧めします。

例: ホスト名がhost01、ドメインがexample.comとします。
$ sudo hostnamectl set-hostname host01.example.com
$

尚、OSインストール時に、ホスト名を設定する画面が出てきたと思います。そこでは、ドット(.)の入力ができないのでホスト名だけ入れたと思います。

ホスト名を確認するときには、hostnameコマンドを実行します。

$ hostname
host０１.example.com
$ hostname -s
host０１
$ hostname -f 
host０１.example.com
$ hostname -d
example.com
$ echo $HOSTNAME
host01.example.com
$ cat /etc/hostname
host01.example.com
$ cat /etc/hosts | grep 127.0.1.1
127.0.1.1 host01

hostnamectlで変更した内容は、/etc/hostnameに書き込まれています。このファイルを、OS起動時に読み込んで、各種設定をしているようです。
尚、/etc/hostnameは以前はホスト名だけを書くルールでしたが、現在は、FQDNで設定して構わないそうです。（man hostnameを参照）
domainnameというコマンドもありますが、NISのDomainのコマンドなので使用しないでください。
<一番上>

9.bashプロンプトの設定

Ubuntuのデフォルトshellはbashです。

$ echo $SHELL
/bin/bash
$ printenv |grep SHELL
SHELL=/bin/bash

BashではPromptはPS1という環境変数で指定されています。

$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$

環境変数:PS1を各ユーザの~/.bashrcで設定すれば、ログインするたびに設定されます。

vi .bashrc
（略）
if [ "$color_prompt" = yes ]; then
        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h: \[\033[00m\](\[\033[01;34m\]\w\[\033[00m\]\$ '　　　　←カラー端末のプロンプト
else
        PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '　　　←モノクロ用。
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"   ←xterm用のプロンプト。
（略）

いくつか、設定を説明します。
\u - 現在のユーザ名
\H - ホスト名(FQDN)を表示する。
\$ - UID:0 (root) の場合＃、それ以外の場合は＄
\W - 現在の作業ディレクトリ
\\ -　バックスラッシュ

私は、基本的にプロンプトをuser@host.example.com:/home/userに統一していますので、それに変更する方法を説明します。ポイントはホスト名がFQDNで現在のディレクトリがフルパスという点です。

user@host01:~$ export PS1="\[\e]0;\u@\H: \W\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\H: \[\033[00m\]\[\033[01;34m\]$PWD\[\033[00m\] \$"
user@host01.example.com: /home/user$

\h(ホスト名） を\H(FQDN)に変更します。
\w(ホームディレクトリからのパス) を＄PWD（現在のディレクトリのフルパスの環境変数）に変更します。

\H が意図した通りにならない場合は、\Hを$(hostname -f)に変更して下さい。

新しいユーザにも同じポリシーを設定する

adduserで作ったユーザにも同じプロンプトにしたい場合は、/etc/skel/.bashrc をコピーしてくるのでこのファイルを変更すれば、新しく作成したユーザにも同じプロンプトが適用されます。

<一番上>

10. rootのパスワード

rootのパスワードは既定で設定されていません。
そのため、rootでログインはできません。
rootでログインしたい場合は、sudo権限を持つユーザでログインした後にsudo suを実行しましょう。

user01@ubuntu:~$ sudo su       ←現在のユーザ(user01)の環境変数でログイン(su)
root@ubuntu:~# exit
exit
user01@ubuntu:~$ sudo su -      ←rootの環境変数でログイン(su)
root@ubuntu:~# exit
logout
user01@ubuntu:~$

お勧めしませんが、以下の方法でrootのパスワードの設定が可能です

$ sudo passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
$ su -
root@ubuntu:~#

<一番上>

11.Active Directory ユーザとの連携

構成:

  1. Active Drectory ドメイン： example.com
  2. ドメインコントローラ(DNSサーバ）: dc.example.com(172.24.0.11)
  3. ユーザのプライマリグループ: Domain Users
  4. AD管理者ユーザ: admin
  5. 一般ユーザ: user

事前の確認事項

  1. ドメインコントローラの名前の逆引きが正しくできること。 dig -x 172.24.0.11
  2. Timezone とNTPの設定を確認します。
  3. ホスト名の設定を行って下さい。
  4. このUbuntuのホスト名（hostname -sの結果）のコンピュータアカウントがAD上に存在しないことを確認します。存在する場合は、削除して下さい。
  5. dig -t NS example.exeが成功すること

パッケージをインストールします。

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install sssd-ad sssd-tools realmd adcli samba-common-bin

ADドメインがDiscoverできるか確認

$ sudo realm -v discover example.com
 * Resolving: _ldap._tcp.snwltac.com
 * Performing LDAP DSE lookup on: 172.24.0.11
 * Successfully discovered: example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

ADにjoinします。

ADにjoinする
$ sudo realm join --user=admin example.com
Password for admin: 
＄　

SSSDの構成情報

構成情報は、/etc/sssd/sssd.confです。

sudo vi /etc/sssd/sssd.conf
[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

既定のホームディレクトリはfallback_homedir = /home/%u@%dでuser@example.comになっています。
'realm list' を確認します。

$ sudo realm list
snwltac.com
  type: kerberos
  realm-name: SNWLTAC.COM
  domain-name: snwltac.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@%D
  login-policy: allow-realm-logins

'login-formats: %U@%D'となっていますので、既定でADユーザの場合、user@example.comと指定します。

ホームディレクトリの作成

ログインしてテストする前に、もう一つ、設定を行います。ローカルにユーザを作成しないので、ホームディレクトリを作成する機会がありません。そのため、はじめてログインする時に自動でホームディレクトリを作成するように設定します。

$ sudo pam-auth-update --enable mkhomedir
$

接続試験

それでは実際にクライアントからsshでログインしてみます。

$ ssh -l user01@example.com host01.example.com
user01@example.com@host01.example.com's password:  
$ user01@example.com@host01:~$ pwd
/home/user01@example.com
$

プロンプトからユーザ名:user01@example.com でログインしていることがわかります。またホームディレクトリが/home/user01@example.com になっています。
id コマンドも確認してみます。

$ id user01@example.com
uid=635401603(user01@example.com) gid=635400513(domain users@example.com) groups=635400513(domain users@example.com),635400512(domain admins@example.com)

このユーザ：user01@example.comのプライマリグループはdomain users@example.com（ADではDomain Users)で、他にdomain admins@example.com(ADではDomain Admins)のグループのメンバーであることがわかります。

ユーザの指定とホームディレクトリの変更

毎回、ユーザ名をuser01@example.comの形式で指定するのは煩雑です。user01だけで済むようにします。またホームディレクトリも/home/user01にします。/etc/sssd/sssd.confを２箇所変更します。
fallback_homedir = /home/%u@%d > fallback_homedir = /home/%u
use_fully_qualified_names = True > use_fully_qualified_names = False
変更の後、sudo systemctl restart sssd でSSSDをリスタートします。

sudoersの設定

最後に、Domain Adminsのメンバがsudoができるように/etc/sudoersに以下の1行を追加します。

visudo
%domain\ admins ALL=(ALL) ALL

ユーザ名の形式が、user01@example.comの場合、domain\ adminsはdomain\ admins@example.comと指定します。

もう一度試験

最後に変更を確認するためにもう一度sshを行います。

$ ssh -l user01 host01.example.com      <-ユーザとしてuser01を指定します。
user01@host01.example.com's password:  
$ user01@host01:~$ pwd　　　　　　　　　　　　<- ホームディレクトリの確認
/home/user01
$ 
$ id user01　　　　　　　　　<- idもシンプルになりました。
uid=635401603(user01) gid=635400513(domain users) groups=635400513(domain users),635400512(domain admins)
$ 
$ sudo su    <-sudo できることを確認します。
Password:
#

<一番上>

12.Desktop環境とXRDPのインストール

Serverなので不要ではありますが、Desktop 環境をインストールして、xRDPもインストールすれば、WindowsやMac からリモートデスクトップでアクセスできます。
デスクトップ環境に好みはあるかもしれませんが、ここでは、GNOMEをインストールします。

Wbuntu ServerへDesktop環境をインストールする

$ sudo apt install ubuntu-desktop task-gnome-desktop

結構時間がかかります。

xRDPのインストール

xRDPのインストールはEasy install xRDP on Ubuntu をお勧めします。
ダウンロードの仕方から使用方法までホームページに記載されています。ここでは、バージョン1.5.2の場合で説明します。

このシェルスクリプトは、デスクトップ環境がインストールされていることが前提で、~/Downloads/で実行されていることが前提です。また、ユーザはsuperuserではない、通常のユーザーで実行することが重要です。なお実行時にaptなどですどが必要なので、パスワードの入力を求められます。

Step 1 – Download the script

cd ~/Downloads/
wget https://www.c-nergy.be/downloads/xRDP/xrdp-installer-1.5.2.zip

Step 2 – unzip the file

unzip xrdp-installer-1.5.2.zip 
chmod +x  ~/Downloads/xrdp-installer-1.5.2.sh

Step 3 – Perform xRDP installation using the script

スクリプト実行時のオプション等は、ホームページで確認してください。ここではもっともシンプルな方法で説明します。

./xrdp-installer-1.5.2.sh

sudoのパスワードや、複数デスクトップマネージャが入っている場合はどれを使うかなど聞かれます。

これで、WindowsやMacのRDPクライアントからログインできるようになります。

ADユーザでのログイン

ADユーザでログインする場合は、/etc/sssd/sssd.conf に以下の２行を追加し、sudo systemctl restart sssdでsssdをリスタートします。

vi /etc/sssd/sssd.conf
ad_gpo_access_control = enforcing
ad_gpo_map_remote_interactive=+xrdp-sesman

<一番上>

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?