手順

1. 現行セッションで sshd デーモンを開始し、ブート時に自動的に起動するように設定します。

   # systemctl start sshd
   # systemctl enable sshd

2. /etc/ssh/sshd_config 設定ファイルの ListenAddress ディレクティブに、デフォルトの 0.0.0.0 (IPv4) または :: (IPv6) とは異なるアドレスを指定し、より低速な動的ネットワーク設定を使用するには、network-online.target ターゲットユニットの依存関係を sshd.service ユニットファイルに追加します。これを行うには、以下の内容で /etc/systemd/system/sshd.service.d/local.conf ファイルを作成します。

   [Unit]
   Wants=network-online.target
   After=network-online.target

3. /etc/ssh/sshd_config 設定ファイルの OpenSSH サーバーの設定がシナリオの要件を満たしているかどうかを確認します。

4. 必要に応じて、/etc/issue ファイルを編集して、クライアント認証を行う前に OpenSSH サーバーに表示される welcome メッセージを変更します。以下に例を示します。

   Welcome to ssh-server.example.com
   Warning: By accessing this server, you agree to the referenced terms and conditions.

   Banner オプションが /etc/ssh/sshd_config でコメントアウトされておらず、その値に /etc/issue が含まれていることを確認します。

   # less /etc/ssh/sshd_config | grep Banner
   Banner /etc/issue

   ログインに成功すると表示されるメッセージを変更するには、サーバーの /etc/motd ファイルを編集する必要があります。詳細は、pam_motd の man ページを参照してください。

5. systemd 設定を再読み込みし、sshd を再起動して変更を適用します。

   # systemctl daemon-reload
   # systemctl restart sshd

検証

1. sshd デーモンが実行していることを確認します。

   # systemctl status sshd
   ● sshd.service - OpenSSH server daemon
      Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
      Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago
        Docs: man:sshd(8)
              man:sshd_config(5)
    Main PID: 1149 (sshd)
       Tasks: 1 (limit: 11491)
      Memory: 1.9M
      CGroup: /system.slice/sshd.service
              └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,>
   
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon...
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22.
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22.
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.

2. SSH クライアントを使用して SSH サーバーに接続します。

   # ssh user@ssh-server-example.com
   ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc.
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts.
   
   user@ssh-server-example.com's password:

手順

1. テキストエディターで /etc/ssh/sshd_config 設定を開きます。以下に例を示します。

   # vi /etc/ssh/sshd_config

2. PasswordAuthentication オプションを no に変更します。

   PasswordAuthentication no

   新しいデフォルトインストール以外のシステムで PubkeyAuthentication no が設定されていないことと、ChallengeResponseAuthentication ディレクティブが no に設定されていることを確認します。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前に、鍵ベースのログインプロセスをテストします。

3. NFS がマウントされたホームディレクトリーで鍵ベースの認証を使用するには、SELinux ブール値 use_nfs_home_dirs を有効にします。

   # setsebool -P use_nfs_home_dirs 1

4. sshd デーモンを再読み込みし、変更を適用します。

   # systemctl reload sshd

手順

1. SSH プロトコルのバージョン 2 用の ECDSA 鍵ペアを生成するには、次のコマンドを実行します。

   $ ssh-keygen -t ecdsa
   Generating public/private ecdsa key pair.
   Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/joesec/.ssh/id_ecdsa.
   Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub.
   The key fingerprint is:
   SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com
   The key's randomart image is:
   +---[ECDSA 256]---+
   |.oo..o=++        |
   |.. o .oo .       |
   |. .. o. o        |
   |....o.+...       |
   |o.oo.o +S .      |
   |.=.+.   .o       |
   |E.*+.  .  . .    |
   |.=..+ +..  o     |
   |  .  oo*+o.      |
   +----[SHA256]-----+

   ssh-keygen コマンドまたは Ed25519 鍵ペアに -t rsa オプションを指定して RSA 鍵ペアを生成するには、ssh-keygen -t ed25519 コマンドを実行します。

2. 公開鍵をリモートマシンにコピーするには、次のコマンドを実行します。

   $ ssh-copy-id joesec@ssh-server-example.com
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   joesec@ssh-server-example.com's password:
   ...
   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.

   セッションで ssh-agent プログラムを使用しない場合は、上記のコマンドで、最後に変更した ~/.ssh/id*.pub 公開鍵をコピーします (インストールされていない場合)。別の公開キーファイルを指定したり、ssh-agent により、メモリーにキャッシュされた鍵よりもファイル内の鍵の方が優先順位を高くするには、-i オプションを指定して ssh-copy-id コマンドを使用します。

検証

1. パスワードなしで OpenSSH サーバーにログインします。

   $ ssh joesec@ssh-server-example.com
   Welcome message.
   ...
   Last login: Mon Nov 18 18:28:42 2019 from ::1

手順

1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵の一覧を表示し、その出力を keys.pub ファイルに保存します。

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pub で ssh-copy-id コマンドを使用します。

   $ ssh-copy-id -f -i keys.pub username@example.com

3. 手順 1 の ssh-keygen -D コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh example.com
   Enter PIN for 'SSH key':
   [example.com] $

   OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが PKCS#11 キットに登録されているため、以前のコマンドを簡素化できます。

   $ ssh -i "pkcs11:id=%01" example.com
   Enter PIN for 'SSH key':
   [example.com] $

手順

1. ローカルシステムの ~/.ssh/config ファイルを編集してジャンプホストを定義します。以下に例を示します。

   Host jump-server1
     HostName jump1.example.com

   • Host パラメーターは、ssh コマンドで使用できるホストの名前またはエイリアスを定義します。値は実際のホスト名と一致可能ですが、任意の文字列にすることもできます。
   • HostName パラメーターは、ジャンプホストの実際のホスト名または IP アドレスを設定します。

2. ProxyJump ディレクティブを使用してリモートサーバーのジャンプ設定を、ローカルシステムの ~/.ssh/config ファイルに追加します。以下に例を示します。

   Host remote-server
     HostName remote1.example.com
     ProxyJump jump-server1

3. ローカルシステムを使用して、ジャンプサーバー経由でリモートサーバーに接続します。

   $ ssh remote-server

   このコマンドは、設定手順 1 および 2 を省略したときの ssh -J jump-server1 remote-server コマンドと同じです。

手順

1. 必要に応じて、キーを使用してリモートホストに対して認証できることを確認します。

   1. SSH を使用してリモートホストに接続します。

      $ ssh example.user1@198.51.100.1 hostname

   2. 秘密鍵へのアクセス権を付与する鍵の作成時に指定したパスフレーズを入力します。

      $ ssh example.user1@198.51.100.1 hostname
       host.example.com

2. ssh-agent を起動します。

   $ eval $(ssh-agent)
   Agent pid 20062

3. ssh-agent にキーを追加します。

   $ ssh-add ~/.ssh/id_rsa
   Enter passphrase for ~/.ssh/id_rsa:
   Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)

手順

1. sshd システムロールの Playbook の例をコピーします。

   # cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml

2. 以下の例のように、テキストエディターでコピーした Playbook を開きます。

   # vim path/custom-playbook.yml
   
   ---
   - hosts: all
     tasks:
     - name: Configure sshd to prevent root and password login except from particular subnet
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd:
           # root login and password login is enabled only from a particular subnet
           PermitRootLogin: no
           PasswordAuthentication: no
           Match:
           - Condition: "Address 192.0.2.0/24"
             PermitRootLogin: yes
             PasswordAuthentication: yes

   Playbook は、以下のように、管理対象ノードを SSH サーバーとして設定します。

   • パスワードと root ユーザーのログインが無効である
   • 192.0.2.0/24 のサブネットからのパスワードおよび root ユーザーのログインのみが有効である

   設定に合わせて変数を変更できます。詳細は、SSHD Server System Role variables を参照してください。

3. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check path/custom-playbook.yml

4. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file path/custom-playbook.yml
   
   ...
   
   PLAY RECAP
   **************************************************
   
   localhost : ok=12 changed=2 unreachable=0 failed=0
   skipped=10 rescued=0 ignored=0

検証

1. SSH サーバーにログインします。

   $ ssh user1@10.1.1.1

   詳細は以下のようになります。

   • user1 は、SSH サーバーのユーザーです。
   • 10.1.1.1 は、SSH サーバーの IP アドレスです。

2. SSH サーバーの sshd_config ファイルの内容を確認します。

   $ vim /etc/ssh/sshd_config
   
   # Ansible managed
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_ecdsa_key
   HostKey /etc/ssh/ssh_host_ed25519_key
   AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
   AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
   AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
   AcceptEnv XMODIFIERS
   AuthorizedKeysFile .ssh/authorized_keys
   ChallengeResponseAuthentication no
   GSSAPIAuthentication yes
   GSSAPICleanupCredentials no
   PasswordAuthentication no
   PermitRootLogin no
   PrintMotd no
   Subsystem sftp /usr/libexec/openssh/sftp-server
   SyslogFacility AUTHPRIV
   UsePAM yes
   X11Forwarding yes
   Match Address 192.0.2.0/24
     PasswordAuthentication yes
     PermitRootLogin yes

3. 192.0.2.0/24 サブネットから root としてサーバーに接続できることを確認します。

   1. IP アドレスを確認します。

      $ hostname -I
      192.0.2.1

      IP アドレスが 192.0.2.1 - 192.0.2.254 範囲にある場合は、サーバーに接続できます。

   2. root でサーバーに接続します。

      $ ssh root@10.1.1.1

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   ---
   - hosts: all
     tasks:
     - name: "Configure ssh clients"
       include_role:
         name: rhel-system-roles.ssh
       vars:
         ssh_user: root
         ssh:
           Compression: true
           GSSAPIAuthentication: no
           ControlMaster: auto
           ControlPath: ~/.ssh/.cm%C
           Host:
             - Condition: example
               Hostname: example.com
               User: user1
         ssh_ForwardX11: no

   この Playbook は、以下の設定を使用して、管理対象ノードで root ユーザーの SSH クライアント設定を行います。

   • 圧縮が有効になっている。
   • ControlMaster multiplexing が auto に設定されている。
   • example.com ホストに接続するための example エイリアスが user1 である。
   • ホストエイリアスの example が作成されている。(これはユーザー名が user1 の example.com ホストへの接続を表します。)
   • X11 転送が無効化されている。

   必要に応じて、これらの変数は設定に合わせて変更できます。詳細は、ssh System Role variables を参照してください。

2. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check path/custom-playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file path/custom-playbook.yml

手順

1. sshd_config_namespace 変数を含む設定スニペットを Playbook に追加します。

   ---
   - hosts: all
     tasks:
     - name: <Configure SSHD to accept some useful environment variables>
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd_config_namespace: <my-application>
         sshd:
           # Environment variables to accept
           AcceptEnv:
             LANG
             LS_COLORS
             EDITOR

   Playbook をインベントリーに適用すると、ロールは次のスニペットがない場合は /etc/ssh/sshd_config ファイルに追加します。

   # BEGIN sshd system role managed block: namespace <my-application>
   Match all
     AcceptEnv LANG LS_COLORS EDITOR
   # END sshd system role managed block: namespace <my-application>

手順

1. CA の秘密鍵を生成します。たとえば、次のコマンドは、256 ビットの楕円曲線デジタル署名アルゴリズム (ECDSA) キーを作成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.key>

   キー生成プロセスの時間は、ホストのハードウェアとエントロピー、選択したアルゴリズム、およびキーの長さによって異なります。

2. 前のコマンドで生成された秘密鍵を使用して署名された証明書を作成します。

   $ openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN=<Example CA>" -out <ca.crt>

   生成された ca.crt ファイルは、10 年間、他の証明書の署名に使用できる自己署名 CA 証明書です。プライベート CA の場合、<Example CA> を共通名 (CN) として任意の文字列に置き換えることができます。

3. CA の秘密鍵に安全なアクセス許可を設定します。次に例を示します。

   # chown <root>:<root> <ca.key>
   # chmod 600 <ca.key>

検証

1. 証明書署名要求 (CSR) を作成し、CA を使用して要求に署名します。CA は、CSR に基づいて証明書を正常に作成する必要があります。次に例を示します。

   $ openssl x509 -req -in <client-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <client-cert> -out <client-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

   詳細は、「プライベート CA を使用した OpenSSL での CSR の証明書の発行」 を参照してください。

2. 自己署名 CA に関する基本情報を表示します。

   $ openssl x509 -in <ca.crt> -text -noout
   Certificate:
   …
           X509v3 extensions:
               …
               X509v3 Basic Constraints: critical
                   CA:TRUE
               X509v3 Key Usage: critical
                   Certificate Sign, CRL Sign
   …

3. 秘密鍵の一貫性を確認します。

   $ openssl pkey -check -in <ca.key>
   Key is valid
   -----BEGIN PRIVATE KEY-----
   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO
   18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E
   lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF
   -----END PRIVATE KEY-----

手順

1. 以下のようにサーバーシステムで秘密鍵を生成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_server.cnf>
   [server-cert]
   keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   C = <US>
   O = <Example Organization>
   CN = <server.example.com>
   
   [alt_name]
   DNS.1 = <example.com>
   DNS.2 = <server.example.com>
   IP.1 = <192.168.0.1>
   IP.2 = <::1>
   IP.3 = <127.0.0.1>

   extendedKeyUsage = serverAuth オプションは、証明書の使用を制限します。

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>

   -config オプションを省略すると、req ユーティリティーは次のような追加情報の入力を求めます。

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [XX]: <US>
   State or Province Name (full name) []: <Washington>
   Locality Name (eg, city) [Default City]: <Seattle>
   Organization Name (eg, company) [Default Company Ltd]: <Example Organization>
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your name or your server's hostname) []: <server.example.com>
   Email Address []: <server@example.com>

検証

1. 要求された証明書を CA から取得したら、次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ openssl x509 -text -noout -in <server-cert.crt>
   Certificate:
   …
           Issuer: CN = Example CA
           Validity
               Not Before: Feb  2 20:27:29 2023 GMT
               Not After : Feb  2 20:27:29 2024 GMT
           Subject: C = US, O = Example Organization, CN = server.example.com
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
   …
           X509v3 extensions:
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment, Key Agreement
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication
               X509v3 Subject Alternative Name:
                   DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP
   …

手順

1. 次の例のように、クライアントシステムで秘密鍵を生成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_client.cnf>
   [client-cert]
   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   CN = <client.example.com>
   
   [clnt_alt_name]
   email= <client@example.com>

   extendedKeyUsage = clientAuth オプションは、証明書の使用を制限します。

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>

   -config オプションを省略すると、req ユーティリティーは次のような追加情報の入力を求めます。

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   …
   Common Name (eg, your name or your server's hostname) []: <client.example.com>
   Email Address []: <client@example.com>

検証

1. 次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ openssl x509 -text -noout -in <client-cert.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

手順

1. オプション: 任意のテキストエディターを使用して、次の例のように、証明書に拡張機能を追加するための OpenSSL 設定ファイルを準備します。

   $ vim <openssl.cnf>
   [server-cert]
   extendedKeyUsage = serverAuth
   
   [client-cert]
   extendedKeyUsage = clientAuth

2. x509 ユーティリティーを使用して、CSR に基づいて証明書を作成します。次に例を示します。

   $ openssl x509 -req -in <server-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <server-cert> -out <server-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

   セキュリティーを強化するには、CSR から別の証明書を作成する前に、シリアル番号ファイルを削除してください。こうすることで、シリアル番号が常に無作為になるようにします。カスタムファイル名を指定する CAserial オプションを省略した場合、シリアル番号のファイル名は証明書のファイル名と同じですが、その拡張子は .srl 拡張子に置き換えられます (前の例では server-cert.srl)。

手順

1. システムで信頼されている CA の一覧に、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/usr/share/pki/ca-trust-source/anchors/ ディレクトリーまたは /etc/pki/ca-trust/source/anchors/ ディレクトリーに証明書ファイルをコピーします。以下に例を示します。

   # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/

2. システム全体のトラストストア設定を更新するには、update-ca-trust コマンドを実行します。

   # update-ca-trust

手順

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

   # yum install libreswan

2. Libreswan を再インストールする場合は、古いデータベースファイルを削除し、新しいデータベースを作成します。

   # systemctl stop ipsec
   # rm /etc/ipsec.d/*db
   # ipsec initnss

3. ipsec サービスを開始して有効にし、システムの起動時にサービスを自動的に開始できるようにします。

   # systemctl enable ipsec --now

4. ファイアウォールで、ipsec サービスを追加して、IKE プロトコル、ESP プロトコル、および AH プロトコルの 500/UDP ポートおよび 4500/UDP ポートを許可するように設定します。

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

手順

1. 各ホストで Raw RSA 鍵ペアを生成します。

   # ipsec newhostkey

2. 前の手順で生成した鍵の ckaid を返します。左 で次のコマンドを実行して、その ckaid を使用します。以下に例を示します。

   # ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d

   上のコマンドの出力により、設定に必要な leftrsasigkey= 行が生成されます。次のホスト (右) でも同じ操作を行います。

   # ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03

3. /etc/ipsec.d/ ディレクトリーで、新しい my_host-to-host.conf ファイルを作成します。上の手順の ipsec showhostkey コマンドの出力から、RSA ホストの鍵を新規ファイルに書き込みます。以下に例を示します。

   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

4. 鍵をインポートしたら、ipsec サービスを再起動します。

   # systemctl restart ipsec

5. 接続を読み込みます。

   # ipsec auto --add mytunnel

6. トンネルを確立します。

   # ipsec auto --up mytunnel

7. ipsec サービスの開始時に自動的にトンネルを開始するには、以下の行を接続定義に追加します。

   auto=start

手順

1. ホスト間の VPN の設定が含まれるファイルを、新規ファイルにコピーします。以下に例を示します。

   # cp /etc/ipsec.d/my_host-to-host.conf /etc/ipsec.d/my_site-to-site.conf

2. 上の手順で作成したファイルに、サブネット設定を追加します。以下に例を示します。

   conn mysubnet
        also=mytunnel
        leftsubnet=192.0.1.0/24
        rightsubnet=192.0.2.0/24
        auto=start
   
   conn mysubnet6
        also=mytunnel
        leftsubnet=2001:db8:0:1::/64
        rightsubnet=2001:db8:0:2::/64
        auto=start
   
   # the following part of the configuration file is the same for both host-to-host and site-to-site connections:
   
   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

手順

1. 各ノードで PKCS #12 ファイルをインポートします。この手順では、PKCS #12 ファイルの生成に使用するパスワードが必要になります。

   # ipsec import nodeXXX.p12

2. IPsec required (private)、IPsec optional (private-or-clear)、および No IPsec (clear) プロファイルに、以下のような 3 つの接続定義を作成します。

   # cat /etc/ipsec.d/mesh.conf
   conn clear
   	auto=ondemand
   	type=passthrough
   	authby=never
   	left=%defaultroute
   	right=%group
   
   conn private
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=drop
   	negotiationshunt=drop
   	# left
   	left=%defaultroute
   	leftcert=nodeXXXX
   	leftid=%fromcert
           leftrsasigkey=%cert
   	# right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup
   
   conn private-or-clear
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=passthrough
   	negotiationshunt=passthrough
   	# left
   	left=%defaultroute
   	leftcert=nodeXXXX
   	leftid=%fromcert
           leftrsasigkey=%cert
   	# right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup

3. 適切なカテゴリーに、ネットワークの IP アドレスを追加します。たとえば、すべてのノードが 10.15.0.0/16 ネットワークにある場合は、すべてのノードに IPsec 暗号が必要です。

   # echo "10.15.0.0/16" >> /etc/ipsec.d/policies/private

4. 特定のノード (例: 10.15.34.0/24) を、IPsec を使用または使用せずに機能させるには、以下の設定を使用して、これらのノードを private-or-clear グループに追加します。

   # echo "10.15.34.0/24" >> /etc/ipsec.d/policies/private-or-clear

5. ホストを、10.15.1.2 など、IPsec の機能がない clear グループに定義する場合は、次のコマンドを実行します。

   # echo "10.15.1.2/32" >> /etc/ipsec.d/policies/clear

   /etc/ipsec.d/policies ディレクトリーのファイルは、各新規ノードのテンプレートから作成することも、Puppet または Ansible を使用してプロビジョニングすることもできます。

   すべてのノードでは、例外の一覧が同じか、異なるトラフィックフローが期待される点に注意してください。したがって、あるノードで IPsec が必要になり、別のノードで IPsec を使用できないために、ノード間の通信ができない場合もあります。

6. ノードを再起動して、設定したメッシュに追加します。

   # systemctl restart ipsec

7. ノードを追加したら、ping コマンドで IPsec トンネルを開くだけで十分です。ノードが開くトンネルを確認するには、次のコマンドを実行します。

   # ipsec trafficstatus

手順

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

   # yum install libreswan

2. Libreswan を再インストールする場合は、古い NSS データベースを削除します。

   # systemctl stop ipsec
   # rm /etc/ipsec.d/*db

3. ipsec サービスを開始して有効にし、システムの起動時にサービスを自動的に開始できるようにします。

   # systemctl enable ipsec --now

4. ファイアウォールで、ipsec サービスを追加して、IKE プロトコル、ESP プロトコル、および AH プロトコルの 500/UDP ポートおよび 4500/UDP ポートを許可するように設定します。

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

5. システムを FIPS モードに切り替えます。

   # fips-mode-setup --enable

6. システムを再起動して、カーネルを FIPS モードに切り替えます。

   # reboot

検証

1. Libreswan が FIPS モードで実行していることを確認するには、次のコマンドを実行します。

   # ipsec whack --fipsstatus
   000 FIPS mode enabled

2. または、systemd ジャーナルで ipsec ユニットのエントリーを確認します。

   $ journalctl -u ipsec
   ...
   Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Product: YES
   Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Kernel: YES
   Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Mode: YES

3. FIPS モードで使用可能なアルゴリズムを表示するには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | head -11
   FIPS Product: YES
   FIPS Kernel: YES
   FIPS Mode: YES
   NSS DB directory: sql:/etc/ipsec.d
   Initializing NSS
   Opening NSS database "sql:/etc/ipsec.d" read-only
   NSS initialized
   NSS crypto library initialized
   FIPS HMAC integrity support [enabled]
   FIPS mode enabled for pluto daemon
   NSS library is running in FIPS mode
   FIPS HMAC integrity verification self-test passed

4. FIPS モードで無効化されたアルゴリズムをクエリーするには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | grep disabled
   Encryption algorithm CAMELLIA_CTR disabled; not FIPS compliant
   Encryption algorithm CAMELLIA_CBC disabled; not FIPS compliant
   Encryption algorithm SERPENT_CBC disabled; not FIPS compliant
   Encryption algorithm TWOFISH_CBC disabled; not FIPS compliant
   Encryption algorithm TWOFISH_SSH disabled; not FIPS compliant
   Encryption algorithm NULL disabled; not FIPS compliant
   Encryption algorithm CHACHA20_POLY1305 disabled; not FIPS compliant
   Hash algorithm MD5 disabled; not FIPS compliant
   PRF algorithm HMAC_MD5 disabled; not FIPS compliant
   PRF algorithm AES_XCBC disabled; not FIPS compliant
   Integrity algorithm HMAC_MD5_96 disabled; not FIPS compliant
   Integrity algorithm HMAC_SHA2_256_TRUNCBUG disabled; not FIPS compliant
   Integrity algorithm AES_XCBC_96 disabled; not FIPS compliant
   DH algorithm MODP1024 disabled; not FIPS compliant
   DH algorithm MODP1536 disabled; not FIPS compliant
   DH algorithm DH31 disabled; not FIPS compliant

5. FIPS モードで許可されているすべてのアルゴリズムと暗号の一覧を表示するには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | grep ESP | grep FIPS | sed "s/^.*FIPS//"
   {256,192,*128}  aes_ccm, aes_ccm_c
   {256,192,*128}  aes_ccm_b
   {256,192,*128}  aes_ccm_a
   [*192]  3des
   {256,192,*128}  aes_gcm, aes_gcm_c
   {256,192,*128}  aes_gcm_b
   {256,192,*128}  aes_gcm_a
   {256,192,*128}  aesctr
   {256,192,*128}  aes
   {256,192,*128}  aes_gmac
   sha, sha1, sha1_96, hmac_sha1
   sha512, sha2_512, sha2_512_256, hmac_sha2_512
   sha384, sha2_384, sha2_384_192, hmac_sha2_384
   sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
   aes_cmac
   null
   null, dh0
   dh14
   dh15
   dh16
   dh17
   dh18
   ecp_256, ecp256
   ecp_384, ecp384
   ecp_521, ecp521

手順

1. Libreswan の NSS データベースのパスワード保護を有効にします。

   # certutil -N -d sql:/etc/ipsec.d
   Enter Password or Pin for "NSS Certificate DB":
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:

2. 前の手順で設定したパスワードを追加した /etc/ipsec.d/nsspassword ファイルを作成します。以下に例を示します。

   # cat /etc/ipsec.d/nsspassword
   NSS Certificate DB:MyStrongPasswordHere

   nsspassword ファイルは以下の構文を使用することに注意してください。

   token_1_name:the_password
   token_2_name:the_password

   デフォルトの NSS ソフトウェアトークンは NSS Certificate DB です。システムが FIPS モードで実行し場合は、トークンの名前が NSS FIPS 140-2 Certificate DB になります。

3. 選択したシナリオに応じて、nsspassword ファイルの完了後に ipsec サービスを起動または再起動します。

   # systemctl restart ipsec

検証

1. NSS データベースに空でないパスワードを追加した後に、ipsec サービスが実行中であることを確認します。

   # systemctl status ipsec
   ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
      Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disable>
      Active: active (running)...

2. 必要に応じて、初期化の成功を示すエントリーが Journal ログに含まれていることを確認します。

   # journalctl -u ipsec
   ...
   pluto[6214]: Initializing NSS using read-write database "sql:/etc/ipsec.d"
   pluto[6214]: NSS Password from file "/etc/ipsec.d/nsspassword" for token "NSS Certificate DB" with length 20 passed to NSS
   pluto[6214]: NSS crypto library initialized
   ...

手順

1. config setup セクションの /etc/ipsec.conf ファイルに以下のオプションを追加します。

   listen-tcp=yes

2. UDP で最初の試行に失敗した場合に TCP カプセル化をフォールバックオプションとして使用するには、クライアントの接続定義に以下の 2 つのオプションを追加します。

   enable-tcp=fallback
   tcp-remoteport=4500

   または、UDP を永続的にブロックしている場合は、クライアントの接続設定で以下のオプションを使用します。

   enable-tcp=yes
   tcp-remoteport=4500

手順

1. ESP ハードウェアオフロードサポートの自動検出を使用する接続の /etc/ipsec.d/ ディレクトリーにある Libreswan 設定ファイルを編集します。
2. 接続の設定で nic-offload パラメーターが設定されていないことを確認します。

3. nic-offload を削除した場合は、ipsec を再起動します。

   # systemctl restart ipsec

1. IPsec 接続が使用するイーサネットデバイスの tx_ipsec カウンターおよび rx_ipsec カウンターを表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

2. IPsec トンネルを介してトラフィックを送信します。たとえば、リモート IP アドレスに ping します。

   # ping -c 5 remote_ip_address

3. イーサネットデバイスの tx_ipsec カウンターおよび rx_ipsec カウンターを再度表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   カウンターの値が増えると、ESP ハードウェアオフロードが動作します。

手順

1. ネットワークボンディングで ESP ハードウェアオフロードのサポートを有効にします。

   # nmcli connection modify bond0 ethtool.feature-esp-hw-offload on

   このコマンドにより、bond0 接続での ESP ハードウェアオフロードのサポートが有効になります。

2. bond0 接続を再度アクティブにします。

   # nmcli connection up bond0

3. ESP ハードウェアオフロードに使用すべき接続の /etc/ipsec.d/ ディレクトリーにある Libreswan 設定ファイルを編集し、nic-offload=yes ステートメントを接続エントリーに追加します。

   conn example
       ...
       nic-offload=yes

4. ipsec サービスを再起動します。

   # systemctl restart ipsec

検証

1. ボンディングのアクティブなポートを表示します。

   # grep "Currently Active Slave" /proc/net/bonding/bond0
   Currently Active Slave: enp1s0

2. アクティブなポートの tx_ipsec カウンターおよび rx_ipsec カウンターを表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

3. IPsec トンネルを介してトラフィックを送信します。たとえば、リモート IP アドレスに ping します。

   # ping -c 5 remote_ip_address

4. アクティブなポートの tx_ipsec カウンターおよび rx_ipsec カウンターを再度表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   カウンターの値が増えると、ESP ハードウェアオフロードが動作します。

1. vpn.example.com 接続をもう一度読み込みます。

   # ipsec auto --add vpn.example.com
   002 added connection description "vpn.example.com"

2. 次に、VPN 接続を開始します。

   # ipsec auto --up vpn.example.com

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:

   この Playbook は、システムロールによって自動生成されたキーを使用した事前共有キー認証を使用して、managed_node1からmanaged_node2 への接続を設定します。

2. 必要に応じて、ホストの vpn_connections リストに次のセクションを追加して、管理対象ホストから、インベントリーファイルに記述されていない外部ホストへの接続を設定します。

       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
             external_node:
               hostname: 192.0.2.2

   これは、追加の接続 (managed_node1からexternal_node) へと (managed_node2からexternal_node) を設定します。

1. 必要に応じて、vpn_connections 内の追加セクション (コントロールプレーンやデータプレーンなど) を使用して、管理対象ノードに複数の VPN 接続を指定できます。

   - name: Multiple VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed_node1:
               hostname: 192.0.2.0 # IP for the control plane
             managed_node2:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed_node1:
               hostname: 10.0.0.1 # IP for the data plane
             managed_node2:
               hostname: 10.0.0.2

2. 必要に応じて、設定に合わせて変数を変更できます。詳細は、/usr/share/doc/rhel-system-roles/vpn/README.md ファイルを参照してください。

3. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file

4. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml

検証

1. 管理対象ノードで、接続が正常にロードされていることを確認します。

   # ipsec status | grep connection.name

   connection.nameを、このノードからの接続の名前 (たとえば、managed_node1-to-managed_node2) に置き換えます。

1. 管理対象ノードで、接続が正常に開始されたことを確認します。

   # ipsec trafficstatus | grep connection.name

2. 必要に応じて、接続が正常に読み込まれなかった場合は、次のコマンドを入力して手動で接続を追加します。これにより、接続の確立に失敗した理由を示す、より具体的な情報が提供されます。

   # ipsec auto --add connection.name

   注記

   接続の読み込みおよび開始のプロセス中に発生した可能性のあるエラーは、ログに報告されます。ログは、/var/log/pluto.log にあります。これらのログは解析が難しいため、代わりに接続を手動で追加して、標準出力からログメッセージを取得してみてください。

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - name: Mesh VPN
     hosts: managed_node1, managed_node2, managed_node3
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - opportunistic: true
           auth_method: cert
           policies:
             - policy: private
               cidr: default
             - policy: private-or-clear
               cidr: 198.51.100.0/24
             - policy: private
               cidr: 192.0.2.0/24
             - policy: clear
               cidr: 192.0.2.7/32

2. 必要に応じて、設定に合わせて変数を変更できます。詳細は、/usr/share/doc/rhel-system-roles/vpn/README.md ファイルを参照してください。

3. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

4. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

手順

1. MACsec を設定する最初のホストで:

   • 事前共有鍵の接続アソシエーション鍵 (CAK) と接続アソシエーション鍵名 (CKN) を作成します。

     1. 16 バイトの 16 進 CAK を作成します。

        # dd if=/dev/urandom count=16 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        50b71a8ef0bd5751ea76de6d6c98c03a

     2. 32 バイトの 16 進 CKN を作成します。

        # dd if=/dev/urandom count=32 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

2. 両方のホストで、MACsec 接続を介して接続します。

3. MACsec 接続を作成します。

   # nmcli connection add type macsec con-name macsec0 ifname macsec0 connection.autoconnect yes macsec.parent enp1s0 macsec.mode psk macsec.mka-cak 50b71a8ef0bd5751ea76de6d6c98c03a macsec.mka-ckn f2b4297d39da7330910a7abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

   前の手順で生成された CAK および CKN を macsec.mka-cak および macsec.mka-ckn パラメーターで使用します。この値は、MACsec で保護されるネットワーク内のすべてのホストで同じである必要があります。

4. MACsec 接続で IP を設定します。

   1. IPv4 設定を指定します。たとえば、静的 IPv4 アドレス、ネットワークマスク、デフォルトゲートウェイ、および DNS サーバーを macsec0 接続に設定するには、以下のコマンドを実行します。

      # nmcli connection modify macsec0 ipv4.method manual ipv4.addresses '192.0.2.1/24' ipv4.gateway '192.0.2.254' ipv4.dns '192.0.2.253'

   2. IPv6 設定を指定しますたとえば、静的 IPv6 アドレス、ネットワークマスク、デフォルトゲートウェイ、および DNS サーバーを macsec0 接続に設定するには、以下のコマンドを実行します。

      # nmcli connection modify macsec0 ipv6.method manual ipv6.addresses '2001:db8:1::1/32' ipv6.gateway '2001:db8:1::fffe' ipv6.dns '2001:db8:1::fffd'

5. 接続をアクティベートします。

   # nmcli connection up macsec0

検証手順

1. トラフィックが暗号化されていることを確認します。

   # tcpdump -nn -i enp1s0

2. オプション: 暗号化されていないトラフィックを表示します。

   # tcpdump -nn -i macsec0

3. MACsec の統計を表示します。

   # ip macsec show

4. integrity-only (encrypt off) および encryption (encrypt on) の各タイプの保護に対して個々のカウンターを表示します。

   # ip -s macsec show

手順

1. ファイアウォールポリシーを作成します。

   # firewall-cmd --permanent --new-policy ExamplePolicy

   ポリシーは、ゾーンとは対照的に、入力、出力、および転送されるトラフィックのパケットフィルタリングを許可します。ローカルで実行されている Web サーバー、コンテナー、または仮想マシン上のエンドポイントにトラフィックを転送するには、このような機能が必要になるため、これは重要です。

2. 受信トラフィックと送信トラフィックのシンボリックゾーンを設定して、ルーター自体がローカル IP アドレスに接続し、このトラフィックを転送できるようにします。

   # firewall-cmd --permanent --policy=ExamplePolicy --add-ingress-zone=HOST
   # firewall-cmd --permanent --policy=ExamplePolicy --add-egress-zone=ANY

   --add-ingress-zone=HOST オプションは、ローカルで生成され、ローカルホストから送信されるパケットを参照します。--add-egress-zone=ANY オプションは、任意のゾーン宛てのトラフィックを参照します。

3. トラフィックを Web サーバーに転送するリッチルールを追加します。

   # firewall-cmd --permanent --policy=ExamplePolicy --add-rich-rule='rule family="ipv4" destination address="192.0.2.1" forward-port port="443" protocol="tcp" to-port="443" to-addr="192.51.100.20"'

   リッチルールは、ルーターの IP アドレス 192.0.2.1 のポート 443 から Web サーバーの IP 192.51.100.20 のポート 443 に TCP トラフィックを転送します。ルールは ExamplePolicy を使用して、ルーターがローカル IP アドレスにも接続できるようにします。

4. ファイアウォール設定ファイルをリロードします。

   # firewall-cmd --reload
   success

5. カーネルで 127.0.0.0/8 のルーティングを有効にします。

   # echo "net.ipv4.conf.all.route_localnet=1" > /etc/sysctl.d/90-enable-route-localnet.conf
   # sysctl -p /etc/sysctl.d/90-enable-route-localnet.conf

検証

1. Web サーバーに転送したルーターの IP アドレスおよびポートに接続します。

   # curl https://192.0.2.1:443

2. オプション: net.ipv4.conf.all.route_localnet がアクティブであることを確認します。

   # sysctl net.ipv4.conf.all.route_localnet
   net.ipv4.conf.all.route_localnet = 1

3. ExamplePolicy がアクティブで、必要な設定が含まれていることを確認します。特に、送信元 IP アドレスとポート、使用するプロトコル、および宛先 IP アドレスとポート:

   # firewall-cmd --info-policy=ExamplePolicy
   ExamplePolicy (active)
     priority: -1
     target: CONTINUE
     ingress-zones: HOST
     egress-zones: ANY
     services:
     ports:
     protocols:
     masquerade: no
     forward-ports:
     source-ports:
     icmp-blocks:
     rich rules:
   	rule family="ipv4" destination address="192.0.2.1" forward-port port="443" protocol="tcp" to-port="443" to-addr="192.51.100.20"