웹사이트 검색

Ubuntu로 호스트와 클라이언트를 검증하기 위해 SSH CA를 만드는 방법

상태: 더 이상 사용되지 않음

이 문서에서는 더 이상 지원되지 않는 Ubuntu 버전에 대해 설명합니다. 현재 Ubuntu 12.04를 실행하는 서버를 운영 중인 경우 지원되는 Ubuntu 버전으로 업그레이드하거나 마이그레이션하는 것이 좋습니다.

  • Ubuntu 14.04로 업그레이드합니다.
  • Ubuntu 14.04에서 Ubuntu 16.04로 업그레이드
  • 서버 데이터를 지원되는 버전으로 마이그레이션

이유:

대신 참조:

소개

많은 사용자가 있는 대량의 서버를 구성할 때 인프라에 대한 SSH 액세스를 유지하는 것이 복잡해질 수 있습니다. LDAP와 같은 중앙 집중식 인증 기관을 구현하는 방법에는 여러 가지가 있지만 이러한 방법은 때때로 과잉입니다.

SSH에는 실제로 인증 기관을 사용하여 서버와 클라이언트를 인증하는 기능이 있습니다. 이것은 양방향으로 작동합니다. 이 시스템을 사용하면 클라이언트에 대해 호스트를 인증할 수 있으므로 호스트의 진위 여부를 확인할 수 없다는 혼란스러운 메시지를 피할 수 있습니다. 또한 호스트에 대한 클라이언트의 유효성을 검사하여 새 SSH 키를 한 곳에서 등록하고 조직 전체에 대한 액세스를 허용할 수 있습니다.

위에서 설명한 두 가지 방법으로 이러한 인증서를 활용하는 방법에 대해 설명합니다. 우리는 이것을 3개의 Ubuntu 12.04 VPS 인스턴스에서 시연할 것입니다. 하나는 호스트 역할을 하고 다른 하나는 클라이언트 역할을 하며 세 번째는 인증 기관 역할을 합니다.

호스트 인증서를 구성하는 방법

서버를 클라이언트에 인증할 인증서를 구성하는 것으로 시작하겠습니다. 이렇게 하면 클라이언트가 서버의 진위 여부를 묻지 않고도 서버에 연결할 수 있습니다.

인증 기관으로 사용할 시스템에서 시작합니다. 이 예에서는 이를 "auth.example.com”이라고 합니다.

서명 키 생성

먼저 서명 키 역할을 할 일부 RSA 키를 생성해야 합니다. 원하는 사용자를 사용하지만 루트 사용자가 좋은 생각일 수 있습니다. "server_ca” 및 "server_ca.pub”라는 키를 생성할 것입니다. 이러한 키는 서버를 인증하는 데 사용되기 때문입니다.

홈 디렉토리에 다음 키를 생성해 보겠습니다.

cd ~
ssh-keygen -f server_ca

암호를 만들 것인지 묻는 메시지가 표시됩니다. 이렇게 하면 키가 잘못된 사람의 손에 들어갈 경우 키에 대한 추가 보호 계층이 추가됩니다. 이 작업이 완료되면 홈 디렉토리에 개인 및 공개 키가 생깁니다.

ls

server_ca   server_ca.pub

호스트 키 서명

이제 키가 있으므로 호스트 키 서명을 시작할 수 있습니다.

인증 기관 자체의 호스트 키에 서명하는 것으로 시작해야 합니다. 다음 구문을 사용하여 이를 수행할 수 있습니다.

<예비>

이 모든 것이 무엇을 의미하는지 살펴보겠습니다.

  • -s: 다른 모든 키에 서명하는 데 사용할 방금 만든 개인 키입니다.
  • -I: 인증서를 식별하기 위해 사용하는 이름입니다. 인증서가 인증에 사용될 때 로깅 용도로 사용됩니다.
  • -h: 결과 인증서를 클라이언트 키가 아닌 호스트 키로 표시합니다.
  • -n: 이 인증서와 연결된 이름(사용자 또는 호스트)을 식별하는 데 사용됩니다.
  • -V: 인증서의 유효 기간을 지정합니다. 이 경우 인증서가 1년(52주) 후에 만료되도록 지정합니다.

그런 다음 서명하려는 키를 지정합니다.

우리의 경우 호스트 RSA 키에 서명하기 위해 다음과 같은 줄을 사용합니다. 이 서버를 "host_auth_server”로 식별할 것입니다. 서명 키를 만들 때 사용한 암호를 입력하라는 메시지가 표시됩니다.

ssh-keygen -s server_ca -I host_auth_server -h -n auth.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Signed host key /etc/ssh/ssh_host_rsa_key-cert.pub: id "host_auth_server" serial 0 for auth.example.com valid from 2014-03-20T12:25:00 to 2015-03-19T12:26:05

출력에서 볼 수 있듯이 인증서는 1년 동안 유효합니다. 서버 호스트 키(/etc/ssh/)와 동일한 디렉토리에 생성되었으며 "ssh_host_rsa_key-cert.pub”라고 합니다.

이제 인증 기관 자체에서 호스트 키에 서명했으므로 클라이언트에 인증하려는 별도의 SSH 서버에 대한 호스트 키에 서명할 수 있습니다.

SSH 서버에서 호스트 키를 복사합니다. 이 시스템을 "sshserver.example.com”이라고 합니다. scp를 사용하여 이 작업을 수행할 수 있습니다.

cd ~
scp root@sshserver.example.com:/etc/ssh/ssh_host_rsa_key.pub .

이제 위에서 사용한 것과 동일한 방법을 사용하여 이 파일에서 인증서를 만들 수 있습니다. 서명할 새 호스트를 참조하도록 일부 값을 변경해야 합니다.

ssh-keygen -s server_ca -I host_sshserver -h -n sshserver.example.com -V +52w ssh_host_rsa_key.pub

Signed host key ssh_host_rsa_key-cert.pub: id "host_sshserver" serial 0 for sshserver.example.com valid from 2014-03-20T12:40:00 to 2015-03-19T12:41:48

이제 생성된 인증서 파일을 호스트에 다시 복사해야 합니다. 이번에도 scp를 사용할 수 있습니다.

scp ssh_host_rsa_key-cert.pub root@sshserver.example.com:/etc/ssh/

그런 다음 인증 서버에서 SSH 서버의 공개 키와 인증서를 모두 삭제할 수 있습니다.

rm ssh_host_rsa_key.pub ssh_host_rsa_key-cert.pub

이제 서명된 인증서가 준비되었으므로 이를 사용하도록 구성 요소를 구성하기만 하면 됩니다.

호스트 인증서를 사용하도록 구성 요소 구성

먼저 두 서버(sshserver.example.com)에서 우리가 생성한 인증서 파일을 인식하도록 계속 진행해야 합니다.

이 두 시스템 모두에서 기본 SSH 데몬 구성 파일을 편집해야 합니다. ssh_config 파일이 아니라 sshd_config 파일을 편집하고 있는지 확인하십시오.

sudo nano /etc/ssh/sshd_config

HostCertificate 행을 찾을 수 있으면 수정하십시오. 그렇지 않으면 이것을 파일 맨 아래에 추가하십시오. 호스트 인증서 파일의 경로를 설정해야 합니다.

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

완료되면 파일을 저장하고 닫습니다.

이제 SSH 데몬을 다시 시작하여 이러한 변경 사항을 적용합니다.

sudo service ssh restart

호스트 인증서를 구성하는 모든 서버에서 이 작업을 수행하십시오.

이제 우리 서버는 인증서를 사용하도록 구성되었지만 클라이언트는 서버가 제공할 인증서를 확인하는 방법을 모릅니다.

"client.example.com”이라고 하는 클라이언트 시스템에서 "~/.ssh/known_hosts” 파일을 열거나 생성합니다. :

nano ~/.ssh/known_hosts

인증서 항목에 대해 구성 중인 서버와 관련된 모든 항목을 제거해야 합니다. 모두 삭제하는 것이 가장 좋습니다.

그런 다음 호스트가 로그인 중에 제공할 인증서를 확인하는 데 사용해야 하는 공개 키를 지정하는 특수 항목을 추가해야 합니다. @cert-authority로 시작하세요. 그런 다음 키가 적용될 도메인 제한을 포함할 수 있으며 모든 항목에 서명하는 데 사용한 공개 인증 기관 키가 뒤따를 수 있습니다.

인증 기관 시스템에서 다음을 입력하여 공개 인증서 서명 키를 얻을 수 있습니다.

cat ~/server_ca.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

이 정보를 사용하여 ~/.ssh/known_hosts 파일의 줄은 다음과 같아야 합니다.

@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxC+gikReZlWEnZhKkGzhcNeRD3dKh0L1opw4/LQJcUPfRj07E3ambJfKhX/+G4gfrKZ/ju0nanbq+XViNA4cpTIJq6xVk1uVvnQVOi09p4SIyqffahO9S+GxGj8apv7GkailNyYvoMYordMbIx8UVxtcTR5AeWZMAXJM6GdIyRkKxH0/Zm1r9tsVPraaMOsKc++8isjJilwiQAhxdWVqvojPmXWE6V1R4E0wNgiHOZ+Wc72nfHh0oivZC4/i3JuZVH7kIDb+ugbsL8zFfauDevuxWeJVWn8r8SduMUVTMCzlqZKlhWb4SNCfv4j7DolKZ+KcQLbAfwybVr3Jy5dSl root@auth

완료되면 파일을 저장하고 닫습니다.

이제 클라이언트에서 처음으로 SSH 서버를 방문할 때(전체 호스트 이름 사용) 원격 호스트를 신뢰하는지 묻는 메시지가 표시되지 않습니다. 이는 호스트가 인증 기관에서 서명한 호스트 인증서를 제시했기 때문입니다. known_hosts 파일을 확인하고 인증서가 합법적인지 확인했습니다.

사용자 키를 구성하는 방법

이제 사용자에게 서버를 인증하는 방법을 배웠으므로 사용자를 서버에 인증하도록 인증 기관을 구성할 수도 있습니다.

이전과 마찬가지로 이 프로세스는 인증 기관 서버에서 시작됩니다. 이번에는 사용자 인증서에 서명하기 위해 새로운 키 세트를 생성해야 합니다.

ssh-keygen -f users_ca

다시 말하지만 누군가가 액세스 권한을 얻은 경우 키가 보호되도록 암호를 선택하십시오.

사용자 인증으로 로그인을 수락하도록 서버 구성

완료되면 사용자 인증을 확인해야 하는 각 SSH 서버에 공개 키를 복사해야 합니다. 평소처럼 scp를 사용하여 이 작업을 수행합니다.

scp users_ca.pub root@sshserver.example.com:/etc/ssh/

이 키를 찾으려면 SSH 서버에서 SSH 데몬 구성을 수정해야 합니다.

"sshserver.example.com” 호스트에서 구성 파일을 엽니다.

sudo nano /etc/ssh/sshd_config

하단의 HostCertificate 줄 아래에 방금 복사한 파일을 참조하는 다른 줄을 추가해야 합니다.

TrustedUserCAKeys /etc/ssh/users_ca.pub

다시 말하지만 이러한 변경 사항을 적용하려면 SSH 데몬을 다시 시작해야 합니다.

sudo service ssh restart

사용자 로그인 키 서명

이제 서버가 users_ca 키로 서명된 키를 신뢰하도록 구성되었으므로 이 스키마가 작동하도록 사용자의 인증 키에 실제로 서명해야 합니다.

먼저 scp를 사용하여 인증 기관 서버에 클라이언트 키를 가져와야 합니다. 인증서 서버에서 다음을 입력합니다.

<예비>

이제 인증서 시스템에 키가 있으므로 users_ca 키를 사용하여 서명할 수 있습니다. 이는 이전에 server_ca 키를 사용하여 키에 서명했을 때와 매우 유사하지만 지금은 사용자 키이기 때문에 -h 매개변수를 포함하지 않습니다.

우리가 원하는 명령은 다음과 같습니다. 더 쉬운 관리를 위해 서명하는 사용자의 이름을 반영하도록 "username\ 값을 변경합니다.

<예비>

키 생성 중에 설정한 users_ca 암호를 입력하라는 메시지가 표시됩니다. 이제 디렉터리에 클라이언트 시스템으로 다시 전송해야 하는 id_rsa-cert.pub 파일이 있습니다.

<예비>

이제 클라이언트 컴퓨터에서 sshserver.example.com에 로그인할 때 이전에 이 사용자로 이 서버에 로그인한 적이 없더라도 인증 세부 정보를 묻는 메시지가 표시되지 않습니다.

결론

호스트 및 사용자 키에 서명하면 사용자 및 서버 유효성 검사를 위한 보다 유연한 시스템을 만들 수 있습니다. 이를 통해 전체 인프라에 대해 하나의 중앙 집중식 권한을 설정하여 서버를 사용자에게 검증하고 사용자를 서버에 검증할 수 있습니다.

중앙 집중식 인증을 생성하는 가장 강력한 방법은 아니지만 많은 시간과 구성을 요구하지 않고 설정하기 쉽고 기존 도구를 활용합니다. 또한 인증서를 확인하기 위해 CA 서버가 온라인 상태일 필요가 없다는 이점도 있습니다.

저스틴 엘링우드