본문 바로가기
320x100
320x100

https://code-boki.tistory.com/135

 

원격 서버 접속하기(1) - telnet/ssh

입사를 해서 회사 일을 해보면, 이런 단어들을 들어볼 수 있을 것이다 로컬 서버, 개발 서버, 스테이징 서버, 배포 서버, 테스트 서버 등등 큰 기업에 가면 xx서버에 접속해서, 변화점이 있는 파일

code-boki.tistory.com

 

https://code-boki.tistory.com/138

 

개인키 알고리즘(feat. RSA)

이전 https://code-boki.tistory.com/136 대칭키 / 비대칭키(공개키) 암호화 대칭키 암호화 (Symmetric Key Encryption) 세션 키(Session Key), 공유 키(Shared Key)라고도 부른다 정의: 대칭키 암호화는 같은 키를 암호화

code-boki.tistory.com

선수지식 또는 앞선 포스팅과 함께 SSH 2번째 포스팅이다

 

일단 내 개인 맥북 2개로 SSH를 실습하며 동작과정을 알아볼 것이다

 

현재 맥북(SSH 클라이언트) - 192.168.123.101

whoami
ifconfig | grep inet | grep 192.168.123

맥북1 - boki(192.168.123.101)

=> boki

=> 192.168.123.101

 

접속할 맥북(SSH 서버) - 192.168.123.104

원격 로그인 허용

맥OS 원격 로그인 허용

whoami
ifconfig | grep inet | grep 192.168.123

맥북2 - tester(192.168.123.104)

=> tester

=> 192.168.123.104

 

최초 접속하지 않은 경우 .ssh폴더 미존재

.ssh 이동 - .ssh폴더가 없어서 이동 불가

SSH로 원격 서버에 접속

ssh 숨김폴더로 이동해서 known_hosts 파일 존재유무 확인 및 192.168.123.104 ip가 쓰여있는지 확인

cd ~/.ssh
ls | grep known_hosts
cat known_hosts | grep 192.168.123.104

비어있는 known_hosts 파일

SSH 접속 방법에는 ID/PW 방식, 공개키/개인키 방식이 있다

 

ID/PW 방식

클라이언트

ssh tester@192.168.123.104

최초 접속시 서버의 공개키를 known_hosts 파일에 append 시킬건지 여부를 물어본다 ⇒ yes

비밀번호 입력..

whoami 명령어로 현재 사용자 확인

Ctrl + D로 연결 종료

클라이언트에서 SSH로 원격 서버에 최초접속(ID/PW)

서버의 공개키가 클라이언트의 known_hosts 파일에 쓰이게 된다

cat known_hosts | grep 192.168.123.104

클라이언트의 known_hosts 파일에 쓰여진 정보 확인

아까와 다르게 ssh-ed25519 key 알고리즘으로 어떤 값이 적힌 것을 볼 수 있다(SSH로 접속할 서버의 공개키)

그럼 서버로 가서 이게 진짜 공개키인지 확인해보자

 

서버

whoami
sudo cat /etc/ssh/ssh_host_ed25519_key.pub

로그인한 계정 출력 및 ed25519 key 알고리즘으로 쓰여진 공개키 파일을 확인

서버의 공개키 확인

=> 똑같다

 

결론

클라이언트known_hosts파일에 서버의 공개키가 저장이 된다는 것을 확인해볼 수 있었다

 

테스트

1. 최초에 서버의 공개키가 클라이언트  known_hosts  파일에 쓰인 뒤에는 어떻게 접속되는가?

known_hosts에 있는 서버로 접속하는 경우

⇒ 한번 성공이 수립된 이후에는 접속 비밀번호만 요청한다

 

2. ssh로 접속을 하려하는데 known_hosts 파일에 쓰인 공개키가 다른 경우 어떻게 되는가?(MITM[중간자 공격] - Man In The Middle 테스트)

 

공격자가 서버인척 위장을 하며 클라이언트에게 자신의 공개키를 제공하는 경우(SSH 접속시)

vi ~/.ssh/known_hosts

[ 이 공개키의 맨 마지막 알파벳 e를 a로 바꿔봤다 ]

=> 이 경우는 사실상 서버에서 잘못된 공개키를 제공하는게 아니라, 클라이언트에서 테스트용으로 임의로 바꿔준 것일뿐

 

ssh 접속을 시도

ssh tester@192.168.123.104

=> 중간자 공격을 시도하고있는 서버일 가능성이 있다고 알려준다

=> 현재 known_hosts에 쓰여있는 공개키의 정보와 SSH 접속을 시도할때 서버에서 알려준 공개키의 값이 서로 다르기 때문이다

=> 나는 클라이언트에서 값을 바꾸고 테스트를 했지만, 실제로는 잘못된 서버에서 이상한 공개키를 제공했다고 가정해야 올바른 MITM이다

 

결국 최초 접속이 수립되면 클라이언트는 서버의 정보를 ip / 공개키로 known_hosts 에 저장해놓으므로 최소한의 공격을 막을 수 있다

 

결론

SSH로 접속을 시도하려고 할 때 인증 과정(Id/pw 또는 공개키/개인키)을 거치기 전에 기존에 접속했던 정보를 known_hosts에서 비교해보는 과정을 진행한다

320x100

댓글