절차

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 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 도움말 페이지를 참조하십시오.

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 가 설정되지 않았으며 Kbd interactiveAuthentication 지시문이 no 로 설정되어 있는지 확인합니다. 콘솔 또는 대역 외 액세스를 사용하지 않고 원격으로 연결하는 경우 암호 인증을 비활성화하기 전에 키 기반 로그인 프로세스를 테스트합니다.

3. NFS로 마운트된 홈 디렉토리에서 키 기반 인증을 사용하려면 use_nfs_home_dirs SELinux 부울을 활성화합니다.

   # 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 -t ed25519 명령을 입력하여 ssh-keygen 명령 또는 Ed25519 키 쌍과 함께 -t rsa 옵션을 사용하여 RSA 키 쌍을 생성할 수도 있습니다.

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로 메모리에 캐시된 키보다 파일의 키 우선 순위를 지정하려면 ssh-copy-id 명령을 -i 옵션과 함께 사용합니다.

검증

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 Kit에 등록되므로 이전 명령을 간소화할 수 있습니다.

   $ 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. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

   ---
   - name: SSH server configuration
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure sshd to prevent root and password login except from particular subnet
         ansible.builtin.include_role:
           name: rhel-system-roles.sshd
         vars:
           sshd:
             PermitRootLogin: no
             PasswordAuthentication: no
             Match:
               - Condition: "Address 192.0.2.0/24"
                 PermitRootLogin: yes
                 PasswordAuthentication: yes

   플레이북은 다음을 수행하도록 구성된 SSH 서버로 관리 노드를 구성합니다.

   • 암호 및 root 사용자 로그인이 비활성화되어 있습니다
   • 암호 및 root 사용자 로그인은 서브넷 192.0.2.0/24에서만 활성화됩니다.

2. 플레이북 구문을 확인합니다.

   $ ansible-playbook --syntax-check ~/playbook.yml

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

검증

1. SSH 서버에 로그인합니다.

   $ ssh <username>@<ssh_server>

2. SSH 서버에서 sshd_config 파일의 내용을 확인합니다.

   $ cat /etc/ssh/sshd_config.d/00-ansible_system_role.conf
   #
   # Ansible managed
   #
   PasswordAuthentication no
   PermitRootLogin no
   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@<ssh_server>

절차

1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

   ---
   - name: SSH client configuration
     hosts: managed-node-01.example.com
     tasks:
       - name: "Configure ssh clients"
         ansible.builtin.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: server.example.com
                 User: user1
           ssh_ForwardX11: no

   이 플레이북은 다음 구성을 사용하여 관리 노드에서 root 사용자의 SSH 클라이언트 기본 설정을 구성합니다.

   • 압축이 활성화됩니다.
   • ControlMaster 멀티플렉싱이 auto 로 설정되어 있습니다.
   • server. example.com 호스트에 연결하는 예제 별칭은 user1 입니다.
   • 예제 호스트 별칭이 생성되며, 이 별칭은 user1 사용자 이름으로 을 호스팅하는 server.example.com 에 대한 연결을 나타냅니다.
   • X11 전달이 비활성화되어 있습니다.

2. 플레이북 구문을 확인합니다.

   $ ansible-playbook --syntax-check ~/playbook.yml

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

절차

1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

   • RHEL 8 이상을 실행하는 관리형 노드의 경우:

     ---
     - name: Non-exclusive sshd configuration
       hosts: managed-node-01.example.com
       tasks:
         - name: <Configure SSHD to accept some useful environment variables>
           ansible.builtin.include_role:
             name: rhel-system-roles.sshd
           vars:
             sshd_config_namespace: <my-application>
             sshd:
               # Environment variables to accept
               AcceptEnv:
                 LANG
                 LS_COLORS
                 EDITOR

   • RHEL 9 이상을 실행하는 관리형 노드의 경우:

     - name: Non-exclusive sshd configuration
       hosts: managed-node-01.example.com
       tasks:
         - name: <Configure sshd to accept some useful environment variables>
           ansible.builtin.include_role:
             name: rhel-system-roles.sshd
           vars:
             sshd_config_file: /etc/ssh/sshd_config.d/<42-my-application>.conf
             sshd:
               # Environment variables to accept
               AcceptEnv:
                 LANG
                 LS_COLORS
                 EDITOR

     sshd_config_file 변수에서 sshd 시스템 역할이 구성 옵션을 쓰는 .conf 파일을 정의합니다. 두 자리 접두사(예: 42- )를 사용하여 구성 파일을 적용할 순서를 지정합니다.

2. 플레이북 구문을 확인합니다.

   $ ansible-playbook --syntax-check ~/playbook.yml

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

절차

1. CA의 개인 키를 생성합니다. 예를 들어 다음 명령은 256비트 Elliptic Curve Digital Signature Algorithm(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의 경우 <ECDHE 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

   자세한 내용은 3.5절. “개인 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> -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

절차

1. CA의 개인 키를 생성합니다. 예를 들어 다음 명령은 256비트 ECDSA(Elliptic Curve Digital Signature Algorithm) 키를 생성합니다.

   $ certtool --generate-privkey --sec-param High --key-type=ecdsa --outfile <ca.key>

   키 생성 프로세스의 시간은 호스트의 하드웨어 및 엔트로피, 선택한 알고리즘 및 키 길이에 따라 달라집니다.

2. 인증서에 대한 템플릿 파일을 생성합니다.

   1. 선택한 텍스트 편집기로 파일을 생성합니다. 예를 들면 다음과 같습니다.

      $ vi <ca.cfg>

   2. 필요한 인증 세부 정보를 포함하도록 파일을 편집합니다.

      organization = "Example Inc."
      state = "Example"
      country = EX
      cn = "Example CA"
      serial = 007
      expiration_days = 365
      ca
      cert_signing_key
      crl_signing_key

3. 1단계에서 생성된 개인 키를 사용하여 서명된 인증서를 생성합니다.

   생성된 < ca.crt > 파일은 1년 동안 다른 인증서에 서명하는 데 사용할 수 있는 자체 서명된 CA 인증서입니다. < ca.crt > 파일은 공개 키(인증서)입니다. 로드된 파일 < ca.key& gt;는 개인 키입니다. 이 파일을 안전한 위치에 보관해야 합니다.

   $ certtool --generate-self-signed --load-privkey <ca.key> --template <ca.cfg> --outfile <ca.crt>

4. CA의 개인 키에 대해 보안 권한을 설정합니다. 예를 들면 다음과 같습니다.

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

검증

1. 자체 서명된 CA에 대한 기본 정보를 표시합니다.

   $ certtool --certificate-info --infile <ca.crt>
   Certificate:
   …
       	X509v3 extensions:
           	…
           	X509v3 Basic Constraints: critical
               	CA:TRUE
           	X509v3 Key Usage: critical
               	Certificate Sign, CRL Sign

2. CSR(인증서 서명 요청)을 생성하고 CA를 사용하여 요청에 서명합니다. CA는 CSR을 기반으로 인증서를 성공적으로 생성해야 합니다. 예를 들면 다음과 같습니다.

   1. CA의 개인 키를 생성합니다.

      $ certtool --generate-privkey --outfile <example-server.key>

   2. 선택한 텍스트 편집기에서 새 구성 파일을 엽니다. 예를 들면 다음과 같습니다.

      $ vi <example-server.cfg>

   3. 필요한 인증 세부 정보를 포함하도록 파일을 편집합니다.

      signing_key
      encryption_key
      key_agreement
      
      tls_www_server
      
      country = "US"
      organization = "Example Organization"
      cn = "server.example.com"
      
      dns_name = "example.com"
      dns_name = "server.example.com"
      ip_address = "192.168.0.1"
      ip_address = "::1"
      ip_address = "127.0.0.1"

   4. 이전에 생성된 개인 키를 사용하여 요청을 생성합니다.

      $ certtool --generate-request --load-privkey <example-server.key> --template <example-server.cfg> --outfile <example-server.crq>

   5. 인증서를 생성하고 CA의 개인 키로 서명합니다.

      $ certtool --generate-certificate --load-request <example-server.crq> --load-ca-certificate <ca.crt> --load-ca-privkey <ca.key> --outfile <example-server.crt>

      추가 리소스

      • certtool(1) 및 trust(1) 도움말 페이지

절차

1. 서버 시스템에서 개인 키를 생성합니다. 예를 들면 다음과 같습니다.

   $ certtool --generate-privkey --sec-param High --outfile <example-server.key>

2. 선택 사항: 선택한 텍스트 편집기를 사용하여 CSR 생성을 간소화하는 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.

   $ vim <example_server.cnf>
   signing_key
   encryption_key
   key_agreement
   
   tls_www_server
   
   country = "US"
   organization = "Example Organization"
   cn = "server.example.com"
   
   dns_name = "example.com"
   dns_name = "server.example.com"
   ip_address = "192.168.0.1"
   ip_address = "::1"
   ip_address = "127.0.0.1"

3. 이전에 생성한 개인 키를 사용하여 CSR을 생성합니다.

   $ certtool --generate-request --template <example-server.cfg> --load-privkey <example-server.key> --outfile <example-server.crq>

   --template 옵션을 생략하면 certool 유틸리티에서 추가 정보를 입력하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.

   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.
   -----
   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

검증

1. CA에서 요청된 인증서를 가져온 후 인증서의 사람이 읽을 수 있는 부분이 요구 사항과 일치하는지 확인합니다.

   $ certtool --certificate-info --infile <example-server.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. 클라이언트 시스템에서 개인 키를 생성합니다. 예를 들면 다음과 같습니다.

   $ certtool --generate-privkey --sec-param High --outfile <example-client.key>

2. 선택 사항: 선택한 텍스트 편집기를 사용하여 CSR 생성을 간소화하는 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.

   $ vim <example_client.cnf>
   signing_key
   encryption_key
   
   tls_www_client
   
   cn = "client.example.com"
   email = "client@example.com"

3. 이전에 생성한 개인 키를 사용하여 CSR을 생성합니다.

   $ certtool --generate-request --template <example-client.cfg> --load-privkey <example-client.key> --outfile <example-client.crq>

   --template 옵션을 생략하면 certtool 유틸리티에서 추가 정보를 입력하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.

   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

검증

1. 사용자가 읽을 수 있는 인증서 부분이 요구 사항과 일치하는지 확인합니다. 예를 들면 다음과 같습니다.

   $ certtool --certificate-info --infile <example-client.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

절차

1. 선택 사항: 선택한 텍스트 편집기를 사용하여 인증서에 확장 기능을 추가하기 위해 GnuTLS 구성 파일을 준비합니다. 예를 들면 다음과 같습니다.

   $ vi <server-extensions.cfg>
   honor_crq_extensions
   ocsp_uri = "http://ocsp.example.com"

2. certtool 유틸리티를 사용하여 CSR을 기반으로 인증서를 생성합니다. 예를 들면 다음과 같습니다.

   $ certtool --generate-certificate --load-request <example-server.crq> --load-ca-privkey <ca.key> --load-ca-certificate <ca.crt> --template <server-extensions.cfg> --outfile <example-server.crt>

절차

1. 간단한 PEM 또는 DER 파일 형식의 인증서를 시스템에서 신뢰하는 CA 목록에 추가하려면 인증서 파일을 /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 패키지를 설치합니다.

   # dnf install libreswan

2. Libreswan을 다시 설치하는 경우 이전 데이터베이스 파일을 제거하고 새 데이터베이스를 만듭니다.

   # systemctl stop ipsec
   # rm /var/lib/ipsec/nss/*db
   # ipsec initnss

3. ipsec 서비스를 시작하고 부팅 시 서비스를 자동으로 시작합니다.

   # systemctl enable ipsec --now

4. ipsec 서비스를 추가하여 IKE, ESP 및 AH 프로토콜에 500 및 4500/UDP 포트를 허용하도록 방화벽을 구성합니다.

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

절차

1. 각 호스트에 원시 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 (private)에 대해 다음 세 가지 연결 정의 (private-or-clear) 및 No IPsec (clear) 프로파일에 대해 다음 세 가지 연결 정의를 만듭니다.

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

1. ping 명령을 사용하여 IPsec 터널을 엽니다.

   # ping <nodeYYY>

2. 가져온 인증서를 사용하여 NSS 데이터베이스를 표시합니다.

   # certutil -L -d sql:/etc/ipsec.d
   
   Certificate Nickname    Trust Attributes
                           SSL,S/MIME,JAR/XPI
   
   west                    u,u,u
   ca                      CT,,

3. 노드가 열려 있는 터널을 확인합니다.

   # ipsec trafficstatus
   006 #2: "private#10.15.0.0/16"[1] ...nodeYYY, type=ESP, add_time=1691399301, inBytes=512, outBytes=512, maxBytes=2^63B, id='C=US, ST=NC, O=Example Organization, CN=east'

절차

1. libreswan 패키지를 설치합니다.

   # dnf install libreswan

2. Libreswan을 다시 설치하는 경우 이전 NSS 데이터베이스를 제거하십시오.

   # systemctl stop ipsec
   
   # rm /var/lib/ipsec/nss/*db

3. ipsec 서비스를 시작하고 부팅 시 서비스를 자동으로 시작합니다.

   # systemctl enable ipsec --now

4. ipsec 서비스를 추가하여 IKE, ESP 및 AH 프로토콜에 500 및 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 Mode: YES

3. FIPS 모드에서 사용 가능한 알고리즘을 보려면 다음을 수행합니다.

   # ipsec pluto --selftest 2>&1 | head -6
   Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
   FIPS Mode: YES
   NSS crypto library initialized
   FIPS mode enabled for pluto daemon
   NSS library is running in FIPS mode
   FIPS HMAC integrity support [disabled]

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 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 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//"
   aes_ccm, aes_ccm_c
   aes_ccm_b
   aes_ccm_a
   NSS(CBC)  3des
   NSS(GCM)  aes_gcm, aes_gcm_c
   NSS(GCM)  aes_gcm_b
   NSS(GCM)  aes_gcm_a
   NSS(CTR)  aesctr
   NSS(CBC)  aes
   aes_gmac
   NSS       sha, sha1, sha1_96, hmac_sha1
   NSS       sha512, sha2_512, sha2_512_256, hmac_sha2_512
   NSS       sha384, sha2_384, sha2_384_192, hmac_sha2_384
   NSS       sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
   aes_cmac
   null
   NSS(MODP) null, dh0
   NSS(MODP) dh14
   NSS(MODP) dh15
   NSS(MODP) dh16
   NSS(MODP) dh17
   NSS(MODP) dh18
   NSS(ECP)  ecp_256, ecp256
   NSS(ECP)  ecp_384, ecp384
   NSS(ECP)  ecp_521, ecp521

절차

1. Libreswan에 대해 NSS 데이터베이스에 대한 암호 보호를 활성화합니다.

   # certutil -N -d sql:/var/lib/ipsec/nss
   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:/var/lib/ipsec/nss"
   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 캡슐화를 대체 옵션으로 사용하려면 클라이언트의 연결 정의에 다음 두 옵션을 추가합니다.

   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-node-01.example.com, managed-node-02.example.com
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed-node-01.example.com:
             managed-node-02.example.com:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   이 플레이북은 시스템 역할에 의해 자동으로 생성되는 키와 함께 사전 공유 키 인증을 사용하여 managed-node-01.example.com-to-managed-node-02.example.com 연결을 구성합니다. vpn_manage_firewall 및 vpn_manage_selinux 둘 다 true 로 설정되므로 vpn 역할은 firewall 및 selinux 역할을 사용하여 vpn 역할에서 사용하는 포트를 관리합니다.

   인벤토리 파일에 나열되지 않은 외부 호스트로의 관리 호스트에서 연결을 구성하려면 다음 섹션을 호스트 vpn_connections 목록에 추가합니다.

       vpn_connections:
         - hosts:
             managed-node-01.example.com:
             <external_node>:
               hostname: <IP_address_or_hostname>

   그러면 하나의 추가 연결을 구성합니다 . managed-node-01.example.com-to-<external_node>

   참고

   연결은 관리형 노드에서만 구성되며 외부 노드에는 구성되지 않습니다.

2. 선택 사항: vpn_connections 내의 추가 섹션을 사용하여 관리 노드에 대해 여러 VPN 연결을 지정할 수 있습니다(예: 컨트롤 플레인 및 데이터 플레인).

   - name: Multiple VPN
     hosts: managed-node-01.example.com, managed-node-02.example.com
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed-node-01.example.com:
               hostname: 192.0.2.0 # IP for the control plane
             managed-node-02.example.com:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed-node-01.example.com:
               hostname: 10.0.0.1 # IP for the data plane
             managed-node-02.example.com:
               hostname: 10.0.0.2

3. 플레이북 구문을 확인합니다.

   $ ansible-playbook --syntax-check ~/playbook.yml

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

4. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

검증

1. 관리형 노드에서 연결이 성공적으로 로드되었는지 확인합니다.

   # ipsec status | grep <connection_name>

   & lt;connection_name >을 이 노드의 연결 이름으로 바꿉니다(예: managed_node1-to-managed_node 2) .

   참고

   기본적으로 역할은 각 시스템의 관점에서 생성하는 각 연결에 대해 설명이 포함된 이름을 생성합니다. 예를 들어 managed_node1 과 managed_node2 간의 연결을 생성할 때 managed_node1 에서 이 연결의 설명적인 이름은 managed_node1-to-managed_node2 이지만, managed_node2 에서 연결 이름은 managed_node2-to-managed_node1 입니다.

2. 관리형 노드에서 연결이 성공적으로 시작되었는지 확인합니다.

   # ipsec trafficstatus | grep <connection_name>

3. 선택 사항: 연결이 성공적으로 로드되지 않으면 다음 명령을 입력하여 연결을 수동으로 추가합니다. 이렇게 하면 연결 설정 실패 이유를 나타내는 더 구체적인 정보가 제공됩니다.

   # ipsec auto --add <connection_name>

   참고

   연결을 로드하고 시작하는 동안 발생할 수 있는 오류는 /var/log/pluto.log 파일에 보고됩니다. 이러한 로그는 구문 분석하기 어렵기 때문에 대신 표준 출력에서 로그 메시지를 가져오는 데 수동으로 연결을 추가합니다.

절차

1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

   - name: Mesh VPN
     hosts: managed-node-01.example.com, managed-node-02.example.com, managed-node-03.example.com
     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
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   인증서를 사용한 인증은 플레이북에 auth_method: cert 매개변수를 정의하여 구성됩니다. 기본적으로 노드 이름은 인증서 닉네임으로 사용됩니다. 이 예에서는 managed-node-01.example.com 입니다. 인벤토리에서 cert_name 속성을 사용하여 다른 인증서 이름을 정의할 수 있습니다.

   이 예제 절차에서는 Ansible 플레이북을 실행하는 시스템인 제어 노드에서 관리 노드(192.0.2.0/24)와 동일한 classless inter-domain routing (CIDR) 번호를 공유하며 IP 주소 192.0.2.7을 갖습니다. 따라서 제어 노드는 CIDR 192.0.2.0/24에 대해 자동으로 생성되는 개인 정책에 속합니다.

   플레이 중에 SSH 연결 손실을 방지하기 위해 제어 노드에 대한 명확한 정책이 정책 목록에 포함됩니다. CIDR이 기본값과 같은 정책 목록에도 항목이 있습니다. 이 플레이북은 기본 정책의 규칙을 재정의하여 private-or-clear 대신 비공개로 만들기 때문입니다.

   vpn_manage_firewall 및 vpn_manage_selinux 둘 다 true 로 설정되므로 vpn 역할은 firewall 및 selinux 역할을 사용하여 vpn 역할에서 사용하는 포트를 관리합니다.

2. 플레이북 구문을 확인합니다.

   $ ansible-playbook --syntax-check ~/playbook.yml

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

절차

1. 방화벽 규칙을 추가합니다. 예를 들면 다음과 같습니다.

   • TCP 연결을 제한하고 111 포트를 통해 192.168.0.0/24 호스트에서 패키지를 수락합니다.

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'

   • TCP 연결을 제한하고 111 포트를 통해 로컬 호스트에서 패키지를 수락합니다.

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'

   • UDP 연결을 제한하고 111 포트를 통해 192.168.0.0/24 호스트에서 패키지를 수락합니다.

     # firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

     방화벽 설정을 영구적으로 설정하려면 방화벽 규칙을 추가할 때 --permanent 옵션을 사용합니다.

2. 방화벽을 다시 로드하여 새 규칙을 적용합니다.

   # firewall-cmd --reload

절차

1. 서버에 방화벽 규칙을 추가합니다. 예를 들면 다음과 같습니다.

   • 192.168.0.0/24 호스트에서 mountd 연결을 수락합니다.

     # firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'

   • 로컬 호스트에서 mountd 연결을 수락합니다.

     # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

     방화벽 설정을 영구적으로 설정하려면 방화벽 규칙을 추가할 때 --permanent 옵션을 사용합니다.

2. 방화벽을 다시 로드하여 새 규칙을 적용합니다.

   # firewall-cmd --reload

절차

1. PostgreSQL을 설치합니다.

   # yum install postgresql-server

2. 다음 옵션 중 하나를 사용하여 데이터베이스 스토리지 영역을 초기화합니다.

   1. initdb 유틸리티 사용:

      $ initdb -D /home/postgresql/db1/

      -D 옵션이 있는 initdb 명령은 해당 디렉터리가 아직 존재하지 않는 경우 지정한 디렉터리를 생성합니다(예: /home/postgresql/db1/ ). 그러면 이 디렉터리에는 데이터베이스에 저장된 모든 데이터와 클라이언트 인증 구성 파일도 포함됩니다.

   2. postgresql-setup 스크립트 사용:

      $ postgresql-setup --initdb

      기본적으로 스크립트는 /var/lib/pgsql/data/ 디렉터리를 사용합니다. 이 스크립트는 시스템 관리자에게 기본 데이터베이스 클러스터 관리를 지원합니다.

3. 인증된 모든 로컬 사용자가 사용자 이름이 있는 모든 데이터베이스에 액세스할 수 있도록 pg_hba.conf 파일에서 다음 행을 수정합니다.

   local   all             all                                     trust

   이 문제는 데이터베이스 사용자를 생성하고 로컬 사용자가 없는 계층화된 애플리케이션을 사용할 때 문제가 될 수 있습니다. 시스템의 모든 사용자 이름을 명시적으로 제어하지 않으려면 pg_hba.conf 파일에서 로컬 행 항목을 제거합니다.

4. 데이터베이스를 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart postgresql

   이전 명령은 데이터베이스를 업데이트하고 구성 파일의 구문도 확인합니다.

절차

1. MACsec을 구성하는 첫 번째 호스트에서 다음을 수행합니다.

   • 사전 공유 키에 대해 CAK(연결 연결 키) 및 연결 연결 키 이름(CKN)을 만듭니다.

     1. 16바이트 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 f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

   이전 단계에서 생성된 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. 각 유형의 보호 유형에 대한 개별 카운터 표시: 무결성 전용 (encrypt off) 및 암호화 (encrypt on)

   # ip -s macsec show

절차

1. MACsec을 구성하는 첫 번째 호스트에서 사전 공유 키에 대한 연결 연결 키(CAK) 및 연결 키 이름(CKN)을 생성합니다.

   1. 16바이트 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 연결을 통해 연결하려는 두 호스트에서 다음 단계를 완료합니다.

   1. 다음 설정으로 YAML 파일(예: create-macsec-connection.yml )을 생성합니다.

      ---
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-interface: macsec0
          next-hop-address: 192.0.2.2
          table-id: 254
        - destination: 192.0.2.2/32
          next-hop-interface: macsec0
          next-hop-address: 0.0.0.0
          table-id: 254
      dns-resolver:
        config:
          search:
          - example.com
          server:
          - 192.0.2.200
          - 2001:db8:1::ffbb
      interfaces:
      - name: macsec0
        type: macsec
        state: up
        ipv4:
          enabled: true
          address:
          - ip: 192.0.2.1
            prefix-length: 32
        ipv6:
          enabled: true
          address:
          - ip: 2001:db8:1::1
            prefix-length: 64
        macsec:
          encrypt: true
          base-iface: enp0s1
          mka-cak: 50b71a8ef0bd5751ea76de6d6c98c03a
          mka-ckn: f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550
          port: 0
          validation: strict
          send-sci: true

   2. mka-cak 및 mka-ckn 매개변수의 이전 단계에서 생성된 CAK 및 CKN을 사용합니다. MACsec 보호 네트워크의 모든 호스트에서 값이 동일해야 합니다.

   3. 선택 사항: 동일한 YAML 구성 파일에서 다음 설정을 구성할 수도 있습니다.

      • /32 서브넷 마스크가 있는 정적 IPv4 주소 - 192.0.2.1
      • /64 서브넷 마스크가 있는 정적 IPv6 주소 2001:db8:1::1
      • IPv4 기본 게이트웨이 - 192.0.2.2
      • IPv4 DNS 서버 - 192.0.2.200
      • IPv6 DNS 서버 - 2001:db8:1::ffbb
      • DNS 검색 도메인 - example.com

3. 시스템에 설정을 적용합니다.

   # nmstatectl apply create-macsec-connection.yml

검증

1. 현재 상태를 YAML 형식으로 표시합니다.

   # **nmstatectl show macsec0

2. 트래픽이 암호화되었는지 확인합니다.

   # tcpdump -nn -i enp0s1

3. 선택 사항: 암호화되지 않은 트래픽을 표시합니다.

   # tcpdump -nn -i macsec0

4. MACsec 통계를 표시합니다.

   # ip macsec show

5. 각 유형의 보호 유형에 대한 개별 카운터 표시: 무결성 전용 (encrypt off) 및 암호화 (encrypt on)

   # ip -s macsec show

절차

1. Dovecot를 설정합니다.

   1. /etc/dovecot/conf.d/10-master.conf 파일에 다음 행을 추가합니다.

      service auth {
        unix_listener /var/spool/postfix/private/auth {
          mode = 0660
          user = postfix
          group = postfix
        }
      }

      이전 예에서는 DestinationRule과 Dovecot 간의 통신에 UNIX-domain 소켓을 사용합니다. 이 예제에서는 /var/spool/ECDHE/ 디렉터리에 있는 메일 대기열과 postfix 사용자 및 그룹에서 실행되는 애플리케이션을 포함하는 기본 DestinationRule SMTP 서버 설정도 가정합니다.

   2. 선택 사항: TCP를 통해 DestinationRule 인증 요청을 수신 대기하도록 Dovecot를 설정합니다.

      service auth {
        inet_listener {
            port = port-number
        }
      }

   3. /etc/dovecot/conf.d/10-auth.conf 파일에서 auth_mechanisms 매개변수를 편집하여 이메일 클라이언트가 Dovecot로 인증하는 방법을 지정합니다.

      auth_mechanisms = plain login

      auth_mechanisms 매개변수는 다양한 일반 텍스트 및 일반 텍스트 인증 방법을 지원합니다.

2. /etc/ECDHE/main.cf 파일을 수정하여ECDHE를 설정합니다.

   1. DestinationRule SMTP 서버에서 SMTP 인증을 활성화합니다.

      smtpd_sasl_auth_enable = yes

   2. SMTP 인증에 대해 Dovecot SASL 구현을 활성화합니다.

      smtpd_sasl_type = dovecot

   3. DestinationRule 큐 디렉터리를 기준으로 인증 경로를 제공합니다. 상대 경로를 사용하면 DestinationRule 서버가 chroot 에서 실행되는지 여부에 관계없이 구성이 작동합니다.

      smtpd_sasl_path = private/auth

      이 단계에서는 DestinationRule과 Dovecot 간의 통신에 UNIX 도메인 소켓을 사용합니다.

      통신에 TCP 소켓을 사용하는 경우 다른 시스템에서 Dovecot를 찾도록 DestinationRule을 구성하려면 다음과 유사한 구성 값을 사용합니다.

      smtpd_sasl_path = inet: ip-address : port-number

      이전 예에서 ip-address 를 Dovecot 시스템의 IP 주소로 바꾸고 포트 번호를 Dovecot의 /etc/dovecot/conf.d/10-master.conf 파일에 지정된 포트 번호로 바꿉니다.

   4. DestinationRule SMTP 서버가 클라이언트에서 사용할 수 있도록 SASL 메커니즘을 지정합니다. 암호화 및 암호화되지 않은 세션에 대해 다양한 메커니즘을 지정할 수 있습니다.

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      이전 지시문에서는 암호화되지 않은 세션 동안 익명 인증이 허용되지 않으며 암호화되지 않은 사용자 이름 또는 암호를 전송하는 메커니즘이 허용되지 않도록 지정합니다. TLS를 사용하는 암호화된 세션의 경우 비익명 인증 메커니즘만 허용됩니다.