logo

ssh - 비밀번호 없이 RSA키 접속만 허용하기

openssh-server 설정을 통해 RSA키 접속만 허용하기

81 조회

0 추천

1,589 단어

8분 예상

2024. 06. 18. 게시

2025. 02. 17. 수정

luasenvy 작성

CC BY-NC-SA 4.0

비밀번호 저장하기

키 생성

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

ssh-keygen 명령을 통해 키를 생성한다. -C 옵션은 주석을 추가하는 옵션으로 여러가지 플랫폼에서 해당 주석을 파싱하는 방식이 서로 다를 수 있음. 원하는 주석 포맷으로 입력하여 생성하면 되는데 키를 구분하기 위해 사용자명@호스트명이 일반적임. rsa형식으로 생성할 경우, 글 작성일 기준으로 4096을 권장하고 있음.

키 등록

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

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

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

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

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

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 인증방식과 공개키 인증방식이 올바르게 설정되었는지 확인해야함. RSAAuthentication 옵션의 경우 현재버전(1:9.2p1-2+deb12u2) 기준 제거됨:

PubkeyAuthentication   yes

키 활용

아마존처럼 접속설정하기

아마존 ec2 인스턴스의 경우, 비밀번호 입력없이 무조건 identity_file을 통한 접속만 허용됨. 보안측면에서 이점을 볼 수 있는 구조이지만, 아마존처럼 거대한 프로젝트가 아닐경우 맞지 않을 수 있음. 또한, 처음 설정하다보면 ssh-keygen을 여러번 하면서 테스트 할 수 있음. 이때 등록된 공개키가 새로 덮어 씌워지면 서버에 설치된 공개키와 클라이언트의 개인키가 서로 맞지 않게 되어 ssh 접속을 할 수 없는 상황이 발생할 수 있으므로 직접 터미널에 접속할 수 없는 클라우드 환경같은 경우 신중히 설정해야함.

SSH 클라이언트

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

SSH 서버 데몬 설정

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

/etc/ssh/sshd_config 설정 후 systemctl restart sshd를 통해 ssh 데몬 재시작. 여기서부터는 ssh 인증시도시 비밀번호 입력방식을 사용할 수 없으므로 조심. 기존에 접속되어있는 ssh 연결은 남아있으므로 혹시 잘못될 경우를 대비하여 계속 켜두고 작업하는 것이 좋다. 클라이언트에서 새로운 터미널을 띄우고 명령으로 접속하여 정상 접속 되었다면 성공

ssh -i "$HOME/.ssh/id_rsa" -l SSH_USERNAME SSH_SERVER_HOST

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

ssh -i "$HOME/.ssh/test/test.pem" -l SSH_USERNAME SSH_SERVER_HOST

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

한계점 및 후

사용자 클라이언트 ─ 인증 서버 ─ ec2 인스턴스

진행하면서 눈치챘겠지만 하나의 서버와 다수의 클라이언트로 구성된 직접연결에서는 관리하기 힘들다. 아마도, 아마존의 경우 인증서버가 존재하여 키페어를 생성하고 발급하는 시스템이 별도로 있을 것이다. 적어도 위처럼은 구성되어야 인증 서버에서만 개인키를 발급하고 ec2 인스턴스에 공개키를 설치해야만 그나마 관리가 될 것이다.

개인 환경에 적용하려면 적어도 장난감 서버 하나는 더 있어야 된다. 그래야 장난감 서버의 개인키를 집, 사무실 등 PC에 복사해서 동일한 키를 통해 접속을 할 수 있다. 집이나 사무실에 방화벽이 없다면 직접 접속해서 키파일을 복사할 수 있겠지만 보통은 그렇지 않기 때문에 여간 귀찮은 일이 아니다...매번 비밀번호 치는게 귀찮아서 설정해보았지만 공개키 설치정도가 현실적이고 그냥 비밀번호 한 번 치고 들어가는게 더 편하다. 애초에 관리 시스템이 없으면 관리가 안된다.

개인서버를 단순히 편의를 위해 이렇게 구성하려는 것이라면 배보다 배꼽이 더 크고 그 전에 흔히 권장하는 비밀번호 길게 쓰고 방화벽 잘 걸고 아이피 밴 잘 걸기 이 정도로만 구성해도 충분히 합리적이고 편리하다.