키 기반 SSH 연결

크리에이티브 커먼즈 라이선스


▴ Photo by geralt on Pixabay

# 키 생성

ssh-keygen 명령을 통한 키 생성

-C 옵션은 주석을 추가하는 옵션으로 여러가지 플랫폼에서 해당 주석을 파싱하는 방식이 서로 다를 수 있음. 원하는 주석 포맷으로 입력하여 생성하면 되는데 키를 구분하기 위해 사용자명@호스트명이 일반적임.

rsa형식으로 생성할 경우, 글 작성일 기준으로 4096을 권장하고 있음.:

1
ssh-keygen -t rsa -b 4096 -C USERNAME@HOSTNAME

# 키 등록

키를 생성하면 $HOME/.ssh 경로에 id_rsa(개인키), id_rsa.pub(공개키) 파일이 생성됨.

공개키를 접속하려는 장치에 설치해두면 이후부터는 ssh clientssh server가 서로 키 확인을 자동으로 진행하여 비밀번호 입력없이 바로 접속이 가능함.

다음 명령을 통해 공개키를 접속하려는 장치에 설치

특정 공개키를 지정하려면 -i 옵션을 통해 지정가능. 과거에는 identity_file이라고 불렀기 때문에 명령 도움말을 보면 identity_file로 가이드 하고 있음.

이 문서에서는 ssh-keygen을 통해 하나의 키만 생성하였으므로 별도 옵션이 없이 진행. 옵션이 없으면 기본값인 $HOME/.ssh/id_rsa.pub가 대상이 됨.:

1
ssh-copy-id SSH_USERNAME@SSH_SERVER_HOST

SSH_USERNAME(설치 대상 호스트 로그인 유저명), SSH_SERVER_HOST(설치 대상 호스트) 각각 자신에게 맞는 것으로 변경하고 입력하고 설치를 진행. 공개키 설치도 ssh를 통해 원격 호스트에 설치하는 것이므로 ssh 접속하듯이 비밀번호 입력하면 알아서 설치가 진행됨.

ssh-keygen주석 옵션에 입력한 것과는 전혀 관계 없음.

# 연결

ssh SSH_USERANME@SSH_SERVER_HOST 명령으로 다시 접속해보면 비밀번호 입력없이 바로 접속되는 것을 확인할 수 있음.

# 로그인 되지 않을 경우 SSH 서버 설정확인

/etc/ssh/sshd_config에서 RSA 인증방식공개키 인증방식이 올바르게 설정되었는지 확인해야함.:

1
2
RSAAuthentication      yes
PubkeyAuthentication yes

# 키 활용

# 아마존 처럼 접속설정하기

아마존 ec2 인스턴스의 경우, 비밀번호 입력없이 무조건 identity_file을 통한 접속만 허용됨. 보안측면에서 이점을 볼 수 있는 구조이지만, 아마존 처럼 거대한 프로젝트가 아닐경우 맞지 않을 수 있음.

또한, 처음 설정하다보면 ssh-keygen을 여러번 하면서 테스트 할 수 있음. 이때 등록된 공개키가 새로 덮어 씌워지면 서버에 설치된 공개키와 클라이언트의 개인키가 서로 맞지 않게 되어 ssh 접속을 할 수 없는 상황이 발생할 수 있으므로 직접 터미널에 접속할 수 없는 클라우드 환경같은 경우 신중히 설정해야함.

# SSH 클라이언트

이 문서에 작성된 키 생성, 키 등록을 진행하여 클라이언트에 개인키와 공개키를 생성하고, 공개키를 대상 서버에 설치한다.

# SSH 서버 데몬 설정

  1. RSA 인증방식: 활성화
  2. 공개키 인증방식: 활성화
  3. 비밀번호 입력방식: 비활성화
  4. PAM사용: 활성화
  5. ChallengeResponseAuthentication: 비활성화
    • PAM방식 사용을 활성화한다면 비활성화하여야함.

/etc/ssh/sshd_config:

1
2
3
4
RSAAuthentication      yes
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM yes

설정 후 systemctl restart sshd를 통해 ssh 데몬 재시작. 여기서부터는 ssh 인증시도시 비밀번호 입력방식을 사용할 수 없으므로 조심. 기존에 접속되어있는 ssh 연결은 남아있으므로 혹시 잘못될 경우를 대비하여 계속 켜두고 작업하는 것이 좋다.

클라이언트에서 새로운 터미널을 띄우고 ssh -i "$HOME/.ssh/id_rsa" -l SSH_USERNAME@SSH_SERVER_HOST 명령으로 접속하여 정상접속 되었다면 성공.

# 다른 클라이언트에서 키파일을 이용해 접속하기

기존에 접속성공한 클라이언트의 개인키 파일($HOME/.ssh/id_rsa)을 복사하여 테스트할 다른 장치에 저장한다. 파일명은 어쨌든 상관없다. 이 문서에서는 $HOME/.ssh/test/test.pem이라고 저장했다고 치자.

ssh -i "$HOME/.ssh/test/test.pem" -l SSH_USERNAME@SSH_SERVER_HOST 명령을 통해 접속되었다면 성공.

# 한계점

진행하면서 눈치챘겠지만 하나의 서버와 다수의 클라이언트로 구성된 직접연결에서는 관리하기 힘들다.

아마도, 아마존의 경우 인증서버가 존재하여 키페어를 생성하고 발급하는 시스템이 별도로 있을 것이다.

사용자 클라이언트 < — > 인증 서버 < — > ec2 인스턴스

적어도 위처럼은 구성되어야 인증 서버에서만 개인키를 발급하고 ec2 인스턴스에 공개키를 설치해야만 그나마 관리가 될 것이다.

# 후기

개인 환경에 적용하려면 적어도 장난감 서버 하나는 더 있어야 된다. 그래야 장난감 서버의 개인키를 집, 사무실 등 PC에 복사해서 동일한 키를 통해 접속을 할 수 있다. 집이나 사무실에 방화벽이 없다면 직접 접속해서 키파일을 복사할 수 있겠지만 보통은 그렇지 않기 때문에 여간 귀찮은 일이 아니다…

매번 비밀번호 치는게 귀찮아서 설정해보았지만 공개키 설치정도가 현실적이고 그냥 비밀번호 한 번 치고 들어가는게 더 편하다. 애초에 관리 시스템이 없으면 관리가 안된다.

보안이 걱정된다면 그냥 비밀번호 길게 쓰고 방화벽으로 아이피밴 걸어놓는게 더 낫다고 본다.