앞서 KEY-PAIR 인증 방식에 대해 기본적으로 확인해보면서 이를 CentOS7 환경에서 사용하는 방법에 대해 살펴보았다.
개념을 CentOS 환경에서 어떤 방식으로 수행하는 지를 위주로 작성할 계획이다.
기존 글 연장선
SSH 통신을 위해선 이전에 작성한 글은 순전히 클라이언트 인증에 대한 개념이였고, 실제 통신에서는 클라이언트 입장에서 해당 서버가 올바른지 확인하는 서버 인증의 과정이 선행적으로 존재한다.
아래는 이전에 작성한 글이고 이는 순전히 클라이언트 인증 과정에 대한 설명이다.
SSH KEY-PAIR 개념(비대칭 키 인증 방식)
SSH란? SSH(Secure Shell)는 네트워크를 통해 다른 원격지의 컴퓨터에 로그인하거나 명령을 실행하여 이를 조작하는 Protocol을 의미한다. => Remote Connection 방식 중 하나! 과거의 원격지의 컴퓨터와 통신
alive-wong.tistory.com
서버 인증
서버 인증이란, 특정 서버를 접속하려는 클라이언트 입장에서 해당 서버가 내가 접속했던 서버가 맞는지 확인하는 방법 중 하나이다.
최초의 통신 이후, 접속한 서버의 정보를 클라이언트가 갖고 있고 이를 바탕으로 다음 접속 때 이 정보를 활용해서 서버를 인증한다.
이때 사용하는 인증을 기본적으로 Key Pair 방식을 사용하고, 클라이언트가 서버에게 받게 되는 공개 키는 CentOS 환경에서 ssh 패키지와 함께 존재하는 ssh_host_ecdsa_key.pub를 사용한다.
이는 ssh 설정에 관련한 파일들이 위치한 디렉토리에서 확인이 가능하다.
[root@kvm1 ~]# ls /etc/ssh
moduli ssh_host_ecdsa_key ssh_host_ed25519_key.pub
ssh_config ssh_host_ecdsa_key.pub ssh_host_rsa_key
sshd_config ssh_host_ed25519_key ssh_host_rsa_key.pub
아래는 최초에 다른 호스트에 ssh 접속을 시도하면 나타나는 안내 문구이다.
[root@kvm1 ~]# ssh 192.168.1.102
The authenticity of host '192.168.1.102 (192.168.1.102)' can''t be established.
ECDSA key fingerprint is SHA256:9S43pRxHlJXoby2S/z4sEgkytwEmDY3j06YNaVeKw5w.
ECDSA key fingerprint is MD5:13:8e:a7:a8:dc:12:27:d2:b1:b2:c5:57:64:0b:2c:12.
Are you sure you want to continue connecting (yes/no)?
내용을 확인해보면 192.168.1.102 호스트가 안전한지에 대해 판단할 수 없고 ECDSA 키의 지문 부분을 알려 주고, 계속 접속을 시도할 건지 물어본다.
[root@kvm1 ~]# ssh kvm2
The authenticity of host 'kvm2 (192.168.1.102)' can''t be established.
ECDSA key fingerprint is SHA256:9S43pRxHlJXoby2S/z4sEgkytwEmDY3j06YNaVeKw5w.
ECDSA key fingerprint is MD5:13:8e:a7:a8:dc:12:27:d2:b1:b2:c5:57:64:0b:2c:12.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.
[root@kvm1 ~]# ssh kvm2
The authenticity of host 'kvm2 (192.168.1.102)'' can't be established.
ECDSA key fingerprint is SHA256:9S43pRxHlJXoby2S/z4sEgkytwEmDY3j06YNaVeKw5w.
ECDSA key fingerprint is MD5:13:8e:a7:a8:dc:12:27:d2:b1:b2:c5:57:64:0b:2c:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'kvm2,192.168.1.102' (ECDSA) to the list of known hosts.
root@kvm2''s password:
Last login: Sat Jun 10 12:41:12 2023 from kvm1
[root@kvm2 ~]#이 부분에서 no를 선택하면 인증 실패로 접속이 취소되고,
yes를 누르면 경고 창이 출력되지만 비밀번호 입력이 성공적이면 접속이 완료된다!
경고 창의 의미는 kvm2 호스트의 ECDSA를 known hosts 리스트에 영구적으로 추가했다라고 볼 수있는데, 해당 파일을 확인해보면 다음과 같다.
kvm2, 192.168.1.102 호스트의 ecdsa 관련 키가 저장되어 있음을 알 수 있다. 결국, 이 키가 kvm2의 ecdsa Key-Pair 중의 공개키와 일치할 것이다.
이와 같은 방식으로 서버의 공개키를 클라이언트의 ~/.ssh/known_hosts에 보관하여 사용하는 방식으로 서버 인증을 수행한다!
ssh-keyscan 사용
하지만, ssh 접속으로 이를 생성하지 말고, 서버의 공개키를 스캔해오는 방법 또한 존재한다.
해당 방식은 아래와 같다.
[root@kvm1 ~]# ls -a ~ | grep ssh
[root@kvm1 ~]# mkdir ~/.ssh
[root@kvm1 ~]# ssh-keyscan 192.168.1.102 >> ~/.ssh/known_hosts
# 192.168.1.102:22 SSH-2.0-OpenSSH_7.4
# 192.168.1.102:22 SSH-2.0-OpenSSH_7.4
# 192.168.1.102:22 SSH-2.0-OpenSSH_7.4
[root@kvm1 ~]# ssh 192.168.1.102
root@192.168.1.102''s password:
Last login: Sat Jun 10 12:52:08 2023 from kvm1
[root@kvm2 ~]#ssh-keyscan을 통해서 서버를 인증할 때 필요한 공개 키들을 자신의 known_hosts에 저장할 수 있다. 이렇게 하면 사용자의 입력을 받지 않아도 된다!
클라이언트 인증 - KeyPair 사용
우선, 이를 위해 해줘야할 점을 나열해보면,
- 접속에 사용할 Key-Pair 생성
- 클라이언트의 공개 키 서버의 ~/.ssh/authorized_keys에 포함
- ssh 설정 파일의 PubkeyAuthentication 옵션 설정
위와 같다.
가상머신 kvm1에서 kvm2로의 접속을 위해 KeyPair 방식을 사용해보자
ssh-keygen으로 키페어 생성 - W2.pem & W2.pem.pub
[root@kvm1 ~]# ssh-keygen -q -N "" -f W2.pem
[root@kvm1 ~]# ls
anaconda-ks.cfg Documents Music Public Videos W2.pem.pub
Desktop Downloads Pictures Templates W2.pem각 옵션의 의미는 다음과 같다.
- -q: quite 모드. 키 생성 중의 프로그레스 바를 보여주지 않는다.
- -N "": 키 사용 간 비밀번호를 "". 즉, 사용하지 않는다.
- -f W2.pem: 키의 이름을 W2.pem & W2.pem.pub으로 만든다.
이렇게 만든 W2.pem(개인키)과 W2.pem.pub(공개키) 중 공개키를 접속하고자 하는 호스트의 계정의 ~/.ssh/authorized_keys 파일에 포함시켜야 한다.
최초의 환경에서는 ~/.ssh 디렉토리부터 존재하지 않을 경우가 있어, 해당 디렉토리와 파일을 모두 생성해야한다.
[root@kvm2 ~]# mkdir ~/.ssh
[root@kvm2 ~]# touch ~/.ssh/authorized_keys
[root@kvm2 ~]# vi ~/.ssh/authorized_keys
[root@kvm2 ~]# systemctl restart sshd~/.ssh/authorized_keys에 W2.pem.pub 키를 추가시켰다면, kvm2 sshd 데몬에서 공개키 인증 방식을 사용하도록 설정해야한다.
아래는 /etc/sshd/config 파일인데, 43번째 줄을 확인했을 때 공개키 옵션이 기본적으로 꺼져 있음을 알 수 있다.
만약, 비밀번호를 위한 접속을 막고 싶으면 65번째 줄의 설정을 변경(no 혹은 주석처리)하면 된다.
위의 설정을 완료하게 된다면 아래와 같이 kvm1에서 kvm2로 접속이 가능해진다.
정리
- 사용자 호스트에서 목적지 호스트로의 SSH 접속을 위해선 서버 인증과 클라이언트 인증 과정을 거친다.
- 서버 인증은 사용자 호스트가 목적이 호스트를 식별하는 과정으로 사용자 호스트의 ~/.ssh/known_hosts 파일의 서버의 ssh 자체의 공개 키를 포함해야한다. 이는 shh-keyscan을 통해 수행 가능하다.
- Key-Pair 방식 클라이언트 인증은 사용자 호스트에서 Key-Pair를 생성한 후 공개 키를 목적지 호스트의 ~/.ssh/authorized_keys에 저장해야한다.
- 추가적으로 sshd의 설정파일을 열어 공개키 방식의 인증을 사용하도록 설정을 수행해야한다.
여담 - 키를 통한 접속이 계속 안될 때
실습 환경에서 Key-Pair 방식의 ssh 접속 설정을 진행할 때, 다른 설정을 다 해줘도 ssh 접속 시 비밀번호 입력 프롬프트가 뜰 때가 있다.
자신이 공개키를 목적지 호스트의 authorized_keys에 포함시킬 때 복사, 붙여넣기 방식을 사용했다면, 그 방법 말고 scp 같은 파일을 직접 전송하는 방식으로 공개 키 자체를 넘겨주고 파일 자체를 넘겨주는 방식을 사용해보면 금방 해결될 수 있다. 예시 코드는 아래와 같다.
[root@kvm1 ~]# scp W2.pem.pub root@192.168.1.102:~ ## 파일 전송 프로토콜
root@192.168.1.102''s password:
W2.pem.pub 100% 391 711.4KB/s 00:00
[root@kvm1 ~]# ssh 192.168.1.102 ## 비밀번호를 통한 ssh 접속
root@192.168.1.102''s password:
Last login: Sat Jun 10 13:49:39 2023 from kvm1
[root@kvm2 ~]# ls ## W2.pem.pub 파일 확인
anaconda-ks.cfg Desktop Documents Downloads Music Pictures Public Templates Videos W2.pem.pub
[root@kvm2 ~]# cat W2.pem.pub >> ~/.ssh/authorized_keys ## authorized_keys에 전달
[root@kvm2 ~]# exit
logout
Connection to 192.168.1.102 closed.
[root@kvm1 ~]# ssh -i W2.pem 192.168.1.102 ## 개인키를 이용한 접속 시도
Last login: Sat Jun 10 16:17:35 2023 from kvm1 ## 성공!본인도 처음 실습환경에서 이를 만들 때, 권한 설정 등을 포함해 다양한 방법을 시도해보았는데, 결국 복사, 붙여넣기의 과정에서 인코딩의 문제인건지.. 계속 비밀번호 요청을 받았었다.
잘 안되면 파일을 직접 넣는 방식으로 실습하는 것이 정신 건강에 좋다! 프로비저닝 도구나 클라우드에서 공개 키를 복사&붙여넣기 방식으로 직접 넣는 경우는 없기 때문이다.