IaC/Ansible 실습

SSH 3 | ssh keypair 생성 방법, ~/.ssh/authorized_keys

Greta Lee 2021. 8. 5. 04:03
SMALL

3. ssh keypair 생성 방법

4. ~/.ssh/authorized_keys 파일


ssh 접속의 기본적인 개념은 이렇습니다. client에서 키 페어가 생성되었으면, 퍼블릭 키는 서버의 ~/.ssh/authorized_keys 파일에 등록된 후에야 프라이빗 키를 이용해 ssh 접속을 할 수 있게 됩니다. 중요한 건 keypair의 퍼블릭 키가 미리 VM의 ~/.ssh/authorized_keys 파일에 세팅되어 있어야 한다는 것입니다.

Client   Server
public key ---- 등록 ----> ~/.ssh/authorized_keys
private key -- ssh -i private_key server 접속 -->  

ssh-keygen

키 기반 인증을 하기 위해서는 키 쌍(keypair)이 필요합니다. 이 때 사용하는 명령어가 ssh-keygen 명령어입니다.

ssh-keygen
  • rsa : 서버에 접속할 때는 default로 ECDSA 암호화 알고리즘을 사용합니다. 그러나 클라이언트에서 키 생성시 기본 암호화 방식으로는 RSA 알고리즘을 사용합니다.
  • /home/vagrant/.ssh/id_rsa : 키가 생성되는 default 경로는 ~/.ssh//id_rsa 입니다.
  • passphrase : passphrase와 password는 차이가 있습니다. 패스워드는 보통 짧은 길이의 암호를 의미하며, passphrase는 아주 긴 문장 형태의 암호입니다. 둘을 크게 구분할 필요는 없으나 ssh에서는 password라 하지 않고 passphrase라는 용어를 사용합니다. 블로그나 서적을 보면 보통 passphrase를 지정하지 않고 enter를 치고 넘어가는 경우가 많습니다. 그런데 이는 편의상하는 것이지 원칙적으로는 비워두고 넘어가면 절대 안 됩니다. 반드시 passphrase를 지정해야 합니다. 지정하지 않으면 소유기반 인증에서 끝이 납니다. 즉, 키 파일이 존재하는 것에서 인증이 가능하다는 것입니다. 예를 들어 공인인증서의 경우, 패스워드를 입력해야 공인인증서를 사용할 수 있습니다. 그런데 만약 패스워드 인증이 필요없다면, 인증서 파일을 소유하는 것만으로 공인인증서를 사용할 수 있게 되는데, 이는 매우 위험합니다. 그러므로 반드시 passphrase를 세팅해야 합니다.
  • fingerprint : SHA256 해쉬로 만든 지문입니다.
  • 3072 : 3072bit 길이의 키가 생성되었습니다. 같은 알고리즘의 키의 길이가 길면 길수록 보안의 강도는 더 세집니다. 일반적으로 2048bit 이상의 길이를 사용하는 것을 권장합니다.


ssh-keygen 옵션을 사용하여 키 페어를 생성할 수도 있습니다.

ssh-keygen -f ~/.ssh/id_rsa -N 'P@ssw0rd'


키 페어가 생성되었습니다. ~/.ssh/id_rsa파일은 프라이빗 키이고, ~/.ssh/id_rsa.pub은 퍼블릭 키 파일입니다.

ls .ssh/ cat .ssh/id_rsa cat .ssh/id_rsa.pub

첫 번째 필드는 rsa 방식의 암호화 알고리즘, 두번째 필드는 퍼블릭 키, 마지막 필드는 생성자에 해당하는 정보입니다.


키 페어 파일을 생성할 때 -t 옵션으로 암호화 알고리즘을 지정할 수도 있습니다.

ssh-keygen -t ecdsa

~/.ssh/authorized_keys

  • 용도 : 클라이언트의 인증을 위해 클라이언트의 퍼블릭 키를 등록시켜 놓는 서버측 파일입니다. 이를 해주는 것이 ssh-copy-id 명령어입니다.


ssh 키를 클라이언트가 생성해서, 공개키를 서버측에 미리 세팅해놓아야 합니다. ~/.ssh/authorized_keys는 말 그대로 인증된 키의 목록을 가지고 있는 파일입니다. 암호화 방식, 공개키, 사용자의 정보를 담고 있습니다.


mgmt1 시스템에도 authorized_keys가 세팅되어 있습니다.


control과 mgmt1에 등록된 위 인증 키는 vm이 생성될 때 host의 퍼블릭 키 입니다. 각 시스템에 host의 퍼블릭 키가 등록되어 있기 때문에 host에서 vm으로 ssh 접속이 가능한 것입니다.

ssh-copy-id

ssh-copy-id로 퍼블릭 키를 서버의 ~/.ssh/authorized_keys에 등록해주어야 합니다. 퍼블릭 키를 등록시키기 위해서는 인증을 받아야 하는데, 그러기 위해서는 인증 방식이 살아 있어야 합니다. 이말은 즉슨, 키 기반 인증을 하고 싶다는 것은 키가 등록되어 있지 않다는 뜻이므로 결국에는 password 인증이 살아있어야 한다는 의미입니다. 따라서 패스워드를 입력해 인증합니다.

ssh-copy-id 192.168.200.101

ssh 접속을 위해 passpharse를 입력합니다.


client(control)의 퍼블릭 키( ~/.ssh/id_rsa.pub )가 server(mgmt1)의 ~/.ssh/authorized_keys 파일에 등록되어 있습니다. control에서 mgmt1으로 접속이 가능할 수 있었던 이유는, control의 퍼블릭 키가 mgmt1에 등록되었기 때문입니다.

mgmt1의 ~/.ssh/authorized_keys 파일의 두번째 라인을 지워보겠습니다. control에서 mgmt1으로 ssh 접속해보면 다시 password 인증을 요구합니다. 모든 SSH client는 키가 있다면 키 기반 인증을 먼저 시도하고, 키 인증이 안되면 패스워드 인증을 시도하기 때문입니다. 즉, 원칙은 키 기반 인증이 먼저이고, 그 다음이 패스워드 인증입니다.


정리하면, ~/.ssh/authorized_keys는 서버 측에 세팅이 되는 것이고, 서버 측에 클라이언트의 퍼블릭 키가 인증된 키 목록에 등록됩니다. 이 목록에 등록된 키를 가지고 있는 클라이언트가 접속을 해오면 접속이 성공하게 됩니다.

ssh -i 옵션은 프라이빗 키를 지정하는 옵션입니다. ssh 192.168.200.101 에는 사실 -i .ssh/id_rsa 가 생략되어 있습니다.

ssh-copy-id 192.168.200.101 ssh -i .ssh/id_rsa 192.168.200.101

ssh 도구는 퍼블릭 키나 프라이빗 키를 별도로 지정하지 않으면 항상 ~/.ssh/ 디렉토리에 있는 키페어 파일( id_알고리즘, id_알고리즘.pub )을 참조합니다. 실험을 하나 해 봅시다.

~/.ssh/ 밑의 키 페어 파일을 지웁니다.

rm -rf .ssh/id_* ls -l .ssh/

키가 없는 상태에서 새로운 키 페어를 생성합니다. 이 때 키 파일 생성 위치를 vagrant 파일로 지정합니다. vagrant와 vagrant.pub 키 페어가 생성되었습니다.

ssh-keygen

키 페어 생성 후 server에 퍼블릭 키를 등록하려 하자 키 파일을 찾을 수 없다는 에러가 발생합니다. 이는 ssh 관련된 모든 커맨드에서 퍼블릭 키 파일의 default 경로는 ~/.ssh/id_알고리즘.pub이고, 프라이빗 키 파일의 default 경로는 ~/.ssh/id_알고리즘이기 때문입니다. 따라서 default 경로가 아닌 곳에 키 페어 파일(vagrant, vagrant.pub)이 존재한다면 -i 옵션을 이용하여 해당 경로를 반드시 지정해주어야 합니다.

ssh-copy-id -i vagrant.pub 192.168.200.101


server에 ssh 접속 명령을 실행하면, 키 기반 인증이 아닌 패스워드 인증을 요구하고 있습니다. 이는 키 페어 파일의 default 경로인 ~/.ssh/id_알고리즘(.pub)에 참조할 키 파일이 없어 패스워드 기반 인증으로 넘어간 결과입니다. 키 기반 인증 접속을 위해서는 위와 마찬가지로 -i 옵션을 통해 키 페어 파일의 위치를 지정해주어야 합니다.

생각해볼 문제가 있습니다. 위 실습은 VM끼리 ssh-copy-id를 통해 서버에 클라이언트의 퍼블릭 키를 등록하는 작업을 해주었습니다. 그런데 호스트에서 VM으로 접속할 때는, 별도로 호스트의 퍼블릭 키를 VM에 등록해주는 작업을 하지 않았는데도 각 VM의 ~/.ssh/authorized_keys 파일에 퍼블릭 키가 세팅이 되었습니다. 이것은 어떻게 된 일일까요?

어떻게 vm에 호스트의 퍼블릭 키가 등록이 되었을까요?

공식적으로는 ssh-copy-id를 사용하여 호스트의 퍼블릭 키를 서버의 ~/.ssh/authorized_keys 파일에 등록해주는 것이 원칙입니다. 그런데 퍼블릭 클라우드에서는 아직 VM이 만들어지지 않았기 때문에 ssh-copy-id를 사용할 수 없습니다. 그렇기 때문에 퍼블릭 클라우드에서는 VM을 생성할 때 호스트의 퍼블릭 키를 등록합니다. 그러면 vagrant init이라는 서비스가 그 정보를 받아서 VM의 ~/.ssh/authorized_keys 파일에 세팅합니다.

AWS에서의 key pair


AWS에서 키 페어를 사용하는 방법은 두 가지 입니다.

  1. AWS 콘솔에서 생성하는 방법(Create key pair) : 프라이빗 키 파일 형식은 .pem 방식과 .ppk 방식이 있습니다.
  2. 기존의 키를 가져오는 방법(Import key pair) : ssh-keygen을 이용해서 미리 키 페어를 생성해놓고 퍼블릭 키만 등록합니다.


기존 키를 가져와 등록하기 위해 ssh-keygen으로 키 페어를 생성합니다. 이후 생성된 퍼블릭 키를 복사합니다.


복사한 퍼블릭 키 파일을 AWS 콘솔에 붙여넣습니다.


퍼블릭 키의 fingerprint가 등록되었습니다.


이제 인스턴스를 생성해 봅시다. 키 페어 지정시 기존에 만들어둔 키 페어인 vagrant를 선택합니다.


생성된 인스턴스의 IP를 이용하여 SSH 접속을 합니다. (프라이빗 키 파일은 현재 디폴트 경로에 위치해있기 때문에 -i .ssh/id_rsa는 생략 가능합니다.)

ssh -i .ssh/id_rsa ec2-user@13.124.229.144

ssh 접속에 성공하면 서버측의 ~/.ssh/authorized_keys 파일에 클라이언트 측의 퍼블릭 키가 등록되어 있는지 확인합니다.

클라이언트의 퍼블릭 키와 동일한 것을 확인할 수 있습니다.

즉, authorized_keys에 퍼블릭 키가 등록되었기 때문에 ssh 접속이 가능했던 것입니다.

Cloud-init

cloud-init 서비스가 하는 역할은 프라이빗 IP로 된 가상 컴퓨터의 이름 즉, hostname과 네트워크(IP 세팅), 시스템의 시간대, 키보드 레이아웃을 설정해주기도 하고, 인스턴스 세부 정보 구성시 '사용자 데이터(VM 인스턴스가 생성될 때 딱 한 번만 실행되는 쉘 스크립트)'를 실행하기도 합니다.
또한SSH 퍼블릭 키를 등록해주는 역할도 합니다. 따라서 cloud-init 서비스가 동작하지 않으면, hostname는 물론 네트워크 설정도 안되고 사용자 데이터도 실행이 안되고 ssh 퍼블릭 키도 등록되지 않습니다. cloud-init은 AWS뿐만 아니라 모든 클라우드에서 사용되는 표준 서비스입니다.

다시 AWS EC2에 접속하여 다음의 명령어를 실행합니다. 먼저 yum list를 통해 cloud-init 패키지가 설치된 것을 확인하고, 이 설치된 패키지로 인해 cloud-init 서비스가 동작하고 있습니다.

yum list cloud-init systemctl status cloud-init


cloud-init의 로그를 살펴볼 수도 있습니다. 사용자 데이터가 잘 작동됐는지 알고 싶으면 cloud-init 로그를 확인해야 합니다.

cat /var/log/cloud-init.log cat /var/log/cloud-init-output.log


◆ AWS에서 인스턴스를 생성한 후에 인스턴스 스냅샷을 찍으면 이미지를 만들 수 있습니다. 그런데 이 이미지를 만들기 전에 cloud-init 서비스를 disabled 상태로 만들면 작동하지 않습니다.

◆ AWS에서는 불가능하지만 다른 클라우드에서는 직접 만든 이미지를 올려 인스턴스를 생성할 수 있습니다. 이 때 인스턴스를 만들기 전에 cloud-init 패키지를 설치하지 않거나 disabled하게 되면 사용자 데이터 실행이라든지 퍼블릭 키 등록과 같은 작업이 동작하지 않습니다.

◆ vagrant 역시 cloud-init 서비스가 동작합니다.

GCP에서의 key pair

GCP에서의 키 페어 등록 메커니즘은 AWS와는 다릅니다. AWS에서는 인스턴스를 생성할 때마다 키 페어를 등록해주어야 했으나, GCP에서는 컴퓨트엔진-메타데이터-SSH 키 탭에서 퍼블릭 키를 global하게 등록해주면 됩니다. 키를 추가하고 싶으면 '수정'을 눌러 항목을 추가할 수 있습니다. 퍼블릭 키를 등록해놓게 되면 별도로 설정하지 않는 한, 등록된 퍼블릭 키와 쌍이 되는 프라이빗 키를 이용하여 ssh 로그인을 할 수 있습니다.


한편 인스턴스를 생성할 때 퍼블릭 키를 등록하는 방법도 있습니다. 공개 키 입력 항목에 ~/.ssh/id_rsa.pub 파일의 내용을 복사하여 붙여넣습니다. 마지막 필드의 사용자 계정에 따라 로그인 계정이 자동으로 입력됩니다. 로그인 계정은 꼭 ~/.ssh/id_rsa.pub 파일에 등록된 계정과 동일할 필요가 없고 임의로 설정할 수 있습니다. 이처럼 GCP는 키를 등록할 때 ssh 접속 계정을 지정하는 것이 가능합니다.


생성된 인스턴스 VM에 ssh 접속을 해봅시다.

ssh -i .ssh/id_rsa vagrant@34.132.81.149


server(GCP 인스턴스)의 ~/.ssh/authorized_keys 퍼블릭 키와 client(contro)의 ~/.ssh/id_rsa.pub 퍼블릭 키가 동일한 것이 확인됩니다.


cloud-init 서비스 동작 상태를 확인해보면 활성화되어 있습니다. (해당 VM 인스턴스 이미지는 Ubuntu입니다. GCP에서 default 이미지인 Debian은 cloud-init 서비스가 동작하지 않습니다.)

SMALL