Cloud Service Practice 10
Web1을 거쳐 Web2로 들어가기 위해 SSH 설정을 바꾸는 이유
두 번째 서버에 이미 키 페어가 있는데 왜 password 접속을 켜고 sshd_config를 바꾸는지 낯설다.
근거 · 교안 p76-p82
1장: 낯선 지시: 키 페어는 어디로?
솔라는 모니터 화면과 노트를 번갈아 보며 미간을 찌푸렸다. 손가락은 키보드 위에서 멈춘 채 망설이고 있었다. 방금 전까지의 작업은 순조로웠다. 클라우드에 가상 서버 두 대를 만들고, 각각 Web1, Web2라는 이름도 붙였다. 보안을 위해 당연히 키 페어(.pem)를 사용해서 접속했다. 비밀번호보다 훨씬 안전한 방식이라고, 그렇게 알고 있었고 직접 경험도 했다.
그런데 지금 눈앞의 실습 가이드 한 줄이 솔라의 손가락을 묶어버렸다.
Web2 서버에 접속하여, Key가 아닌 Password 입력을 통해 접속이 가능하도록 ssh 설정 파일을 편집합니다.
“이거… 이상한데.”
혼잣말이 불쑥 튀어나왔다. 키가 아니라 암호로 접속하라니. 일부러 보안 수준을 낮추라는 말처럼 들렸다. 혹시 내가 가이드를 잘못 읽었나 싶어 눈을 비비고 다시 읽어봐도 문장은 그대로였다.
마침 거실에서 들어온 언니 루나가 멈칫한 솔라의 뒷모습을 보고는 조용히 옆으로 다가왔다. 솔라의 모니터에 떠 있는 검은 터미널 창과 가이드 문서를 잠시 들여다보았다.
“왜, 뭐 막히는 거 있어?”
“언니, 이것 좀 봐. 여태까지 서버 접속할 때 무조건 키 페어 쓰라고 해서 그렇게 했잖아. 그게 훨씬 안전하다고. 근데 갑자기 Web2 서버는 비밀번호로 접속할 수 있게 설정을 바꾸래. 일부러 문을 열어주라는 거 아냐?”
솔라는 답답하다는 듯이 말했다. 마치 잘 잠가둔 자물쇠를 일부러 망가뜨리라는 지시를 받은 기분이었다.
“틀린 말은 아니지. 우리가 배운 바로는 키 페어가 비밀번호 인증보다 훨씬 안전하니까.”
루나는 고개를 끄덕이며 솔라의 말에 동의했다. 그리고는 덧붙였다.
“솔라 네가 생각하는 키 페어 방식의 장점이 뭔데? 왜 그게 더 안전하다고 생각해?”
질문의 방향이 의외였다. ‘왜 그렇게 해야 하는지’를 알려주는 대신, ‘왜 그렇게 생각하는지’를 되묻고 있었다. 솔라는 잠시 머뭇거리다 자신이 아는 것을 정리하기 시작했다.
“음… 일단 비밀번호는 사람이 기억하기 쉬운 걸로 만들다 보면 짧거나 단순해지기 쉽잖아. 무차별 대입 공격 같은 걸로 언젠가는 뚫릴 수도 있고. 근데 키 페어는 개인이 갖는 비밀 키랑 서버에 두는 공개 키, 한 쌍으로 동작하니까. 이 비밀 키 파일이 없으면 아예 접속 시도조차 못 하고. 또 키 자체도 엄청 길고 복잡한 문자열이라서… 사실상 해독이 불가능하고.”
스스로 설명하면서 솔라의 확신은 더 단단해졌다. 그래, 이거였다. 키 페어는 그냥 ‘더 좋은’ 수준이 아니라, 근본적으로 다른 차원의 보안이었다. 이 확신에 찬 설명을 듣고 있던 루나는 솔라의 책상에 놓여있던 열쇠 꾸러미를 집어 들었다.
“이건 우리 집 열쇠, 이건 자전거 자물쇠 열쇠… 전부 모양이 다르네. 만약 우리 집 현관문이 이 열쇠들 대신, 네가 좋아하는 가수의 생일 네 자리로 열린다면 어떨까?”
“그건 절대 안 되지! 누구나 추측할 수 있잖아. 위험하게.”
솔라는 손사래를 쳤다.
“바로 그거야. 지금 네가 말한 게 일반적인 상황에서 SSH 접속에 키 페어를 쓰는 이유야. 추측 가능한 짧은 암호 대신, 유일하고 복잡한 ‘열쇠’를 사용하는 것. 그 원칙은 맞아.”
루나는 열쇠를 내려놓으며 말했다.
“그럼 이 가이드는 틀린 거네? 옛날 방식이거나, 보안을 잘 모르는 사람이 쓴 거 아닐까?”
솔라의 목소리엔 안도감과 약간의 의기양양함이 섞였다. 자신의 생각이 맞았다는 기쁨이었다. 하지만 루나는 고개를 저었다.
“아니, 아마 틀린 건 아닐 거야. 가이드를 다시 봐봐. ‘왜’ 바꿔야 하는지에 대한 설명은 아직 안 나왔지만, 분명히 ‘비밀번호로 접속 가능하도록’ 하라고 지시하고 있어.”
루나의 말에 솔라는 다시 모니터로 눈을 돌렸다. 여전히 이해할 수 없는 지시였다. 하지만 ‘이 가이드는 틀렸어’라고 단정했던 처음의 생각에서 한 걸음 물러나게 되었다. 내가 아는 보안 원칙은 분명한 사실이지만, 눈앞의 이 지시도 명백한 ‘의도’를 가지고 있었다.
“그럼… 내가 아는 원칙이 틀린 게 아니라면, 이 상황이 내가 모르는 ‘특별한 상황’이라는 뜻인가?”
솔라의 목소리에 조금 전의 확신 대신 새로운 질문이 담겨 있었다. 왜 갑자기 비밀번호 인증을 활성화해야 할까? 정말 보안에 문제는 없는 걸까?
“그럴 수 있지.”
루나가 짧게 대답했다.
솔라는 키보드 위에 다시 손을 올렸다. 하지만 여전히 명령어를 입력하지는 못했다. 일반적인 원칙과 눈앞의 지시 사이의 간극. 그 간극의 정체를 이해하기 전까지는, 이 낯선 지시를 따를 수 없을 것 같았다. 머릿속에는 오직 하나의 질문만이 맴돌았다. 도대체 어떤 특별한 상황이기에, 더 안전한 길을 두고 굳이 돌아가라고 하는 걸까.
2장: 중간 접속 지점: Web1의 새로운 역할
솔라의 손가락은 여전히 키보드 위를 맴돌았다. ‘특별한 상황’이라는 말의 무게가 손가락 끝을 누르는 듯했다. 일반적인 보안 원칙이 옳다는 믿음과, 눈앞의 실습 가이드 역시 나름의 이유가 있을 거라는 추측 사이에서 생각이 오갔다.
그때, 루나가 솔라의 책상에서 이면지 한 장과 펜을 가져왔다. 그리고는 말없이 슥슥, 사각형 두 개를 그렸다. 각각의 사각형 아래에 Web1, Web2라고 적었다. 그리고 조금 떨어진 곳에 작은 집 모양 아이콘을 그리고 내 컴퓨터라고 썼다. 그림을 완성한 루나는 펜을 솔라 쪽으로 밀어주었다.
“지금까지 네가 서버에 접속했던 길을 한번 그려볼래?”
솔라는 잠시 언니의 의도를 파악하려는 듯 쳐다보다가, 이내 펜을 집어 들었다. 그리고는 망설임 없이 내 컴퓨터에서 Web1으로, 또 내 컴퓨터에서 Web2로 각각 직선을 그었다. 각 선 위에는 작게 ‘.pem 키’라고 적었다. 지금까지의 방식은 이것이 전부였다.
“맞아. 지금까지는 이렇게 네 컴퓨터에서 각 서버로 직접 들어갔지. 그래서 네 컴퓨터에 있는 비밀 키 하나만 있으면 충분했고.”
루나는 솔라가 그린 그림을 가리켰다. 그림 속에서 내 컴퓨터는 두 서버와 직접 연결된 중심점처럼 보였다.
“그런데 가이드를 조금만 더 읽어보면, 우리가 놓친 단서가 하나 있어.”
루나는 솔라의 모니터 쪽으로 고개를 돌려, 아까 솔라가 혼란스러워했던 지시 바로 다음 줄을 가리켰다. 거기에는 이런 문장이 적혀 있었다.
이 변경은 이후 Web1 서버에서 Web2 서버의 내부 IP로 접속하는 실습을 위해 필요합니다.
“Web1에서… Web2로?”
솔라는 문장을 나지막이 읊조렸다. 순간 머릿속에서 뭔가 번쩍했다. 시선이 빠르게 종이 위 그림으로 돌아갔다. 내 컴퓨터에서 Web2로 향하던 직선. 그 길이 아니었다.
솔라는 스스로 그었던 선 하나를 지웠다. 내 컴퓨터와 Web2를 잇던 길이었다. 대신, 새로운 길을 그렸다. Web1에서 Web2로 향하는 선이었다. 완성된 그림은 완전히 다른 이야기를 하고 있었다.
내 컴퓨터 → Web1 → Web2
“아…! 내 컴퓨터에서 Web2로 바로 접속하는 게 아니었구나. Web1을 한번 거쳐서, Web1이 Web2로 접속하게 만드는 거였어.”
이제야 전체 그림이 보이기 시작했다. 최종 목적지는 Web2가 맞지만, 출발지와 경로가 완전히 달랐다. 내 컴퓨터에서 직접 가는 게 아니라, Web1이라는 중간 다리를 건너야 하는 여정이었다.
“응. 이번 실습에서 Web1은 단순한 웹 서버가 아니라, Web2로 들어가기 위한 일종의 ‘관문’이나 ‘경유지’ 역할을 하는 셈이지.”
루나의 말에 솔라는 고개를 끄덕였다. ‘점프 호스트(Jump Host)’라는 용어가 어렴풋이 떠올랐지만, 용어 자체보다 그 구조가 선명하게 와 닿았다. 외부에는 Web1만 열어두고, 중요한 서버인 Web2는 내부망에 숨겨둔 뒤 Web1을 통해서만 접근하게 만드는, 더 안전한 구조.
그림을 다시 보니, 첫 번째 길(내 컴퓨터 → Web1)은 명확했다. 기존처럼 내 컴퓨터의 비밀 키를 사용하면 된다. 하지만 두 번째 길이 문제였다. 솔라의 얼굴에 새로운 궁금증이 떠올랐다.
“잠깐만. 내 컴퓨터에서 Web1으로 들어갈 땐 내 비밀 키를 쓰면 돼. 그런데… Web1 서버가 Web2 서버로 접속할 땐 뭘로 인증해야 하지? 내 비밀 키는 내 컴퓨터에만 있잖아. Web1 서버에는 없는데.”
질문이 바뀌었다. ‘왜 보안 수준을 낮추는가?‘에서 ‘새로운 길에서는 어떻게 문을 열어야 하는가?‘로. Web1을 중간 접속 지점으로 설정하자, 그전에는 보이지 않던 새로운 연결 지점이 나타났고, 그 지점에는 새로운 인증 방식이 필요하다는 사실을 깨달은 것이다. 비밀번호 인증을 활성화하라는 지시가 더 이상 보안 원칙을 무시하는 엉뚱한 요구로 보이지 않았다. 어쩌면 이 새로운 길을 위한, 가장 실용적인 ‘열쇠’일지도 모른다는 생각이 들었다.
3장: 상황에 맞는 선택: 내부망 접속의 실용성
솔라의 시선은 이면지 위에 그려진 두 갈래 길, 내 컴퓨터 → Web1 → Web2에 고정되었다. 첫 번째 길은 명확했지만 두 번째 길, Web1에서 Web2로 넘어가는 경로는 새로운 퍼즐이었다. 가장 안전하고 익숙한 방법은 키 페어 인증. 솔라는 그 원칙을 이 새로운 길에 적용해보기 위해, 머릿속으로 필요한 절차를 구체적으로 그려나가기 시작했다.
“좋아, 일단 Web1 서버에 접속해서… 거기서 ssh-keygen 명령으로 새 키 페어를 만들어야겠지. 그리고 생성된 공개 키를 복사해서 Web2 서버의 authorized_keys 파일에 넣어주면 돼.” 스스로 절차를 되짚어보던 솔라의 미간이 살짝 찌푸려졌다. “그런데 잠깐, Web1에서 Web2로는 아직 접속할 길이 없잖아? 그럼 Web2의 파일은 어떻게 수정하지? 아, 내 컴퓨터에서는 Web2로 키 페어 접속이 되니까… 먼저 Web1에서 만든 공개 키 내용을 어떻게든 내 컴퓨터로 가져온 다음, 내가 다시 Web2에 접속해서 그 키를 authorized_keys 파일에 붙여넣어야 하나? 일이 뭔가 복잡해지는데….”
스스로 뱉은 말 속에서 절차의 꼬임이 느껴졌다. 가장 안전한 길을 고집하려니, 오히려 가야 할 길이 빙빙 돌아가는 기분이었다.
옆에서 솔라의 혼잣말을 듣고 있던 루나가 조용히 펜을 들었다. 그리고는 이면지 한쪽 구석에 ‘방법 1: 키 페어 고수하기’라고 적고, 솔라가 방금 중얼거린 복잡한 과정을 간결하게 정리했다.
내 컴퓨터에서Web1접속.Web1에서 새 키 페어 생성.Web1의 새 공개 키 내용을 복사. (cat ~/.ssh/id_rsa.pub)- 별도의 터미널에서
내 컴퓨터->Web2접속. Web2의authorized_keys파일에Web1의 공개 키 추가.- 이제
Web1에서Web2로 키 페어 접속 가능.
“이 방법도 틀린 건 아니야. 원칙적으로 가능하고, 아주 안전한 방식이지.”
루나의 말에 솔라는 복잡한 표정으로 고개를 끄덕였다. 가능하지만, 이 실습의 한 단계를 넘기 위해 거쳐야 할 과정으로는 번거롭게 느껴졌다.
“그럼, 가이드에서 제안하는 방법은 어때?”
루나가 이면지의 반대편에 ‘방법 2: 가이드 따르기’라고 적었다. 솔라는 다시 모니터 속 가이드를 보며 필요한 절차를 나열했다.
내 컴퓨터에서Web2접속 (현재 접속된 상태).Web2서버에 비밀번호 설정.Web2서버의 SSH 설정 파일 수정 (비밀번호 인증 허용).Web2서버의 SSH 서비스 재시작.
두 개의 목록이 나란히 놓이자, 차이점은 극명하게 드러났다. 방법 1은 여러 서버를 오가며 키를 전달해야 하는 반면, 방법 2는 현재 접속한 Web2 서버 안에서 모든 설정이 끝났다.
“아…”
솔라의 입에서 짧은 탄성이 터져 나왔다.
“비밀번호 방식은… 그냥 이 실습을 위해서, Web1에서 Web2로 넘어가는 ‘임시 다리’를 간단하게 놓는 거구나. 외부에서 누구나 들어올 수 있는 대문이 아니라, 이미 안으로 들어온 사람만 건널 수 있는 내부 통로를 만드는 거니까.”
“맞아. 여기서 중요한 건 ‘상황’이야.”
루나가 말을 이었다.
“Web2 서버의 SSH 포트는 외부 인터넷에 직접 노출되어 있지 않아. 오직 우리 내부 네트워크, 지금 이 구조에서는 Web1을 통해서만 접근할 수 있지. 즉, 무차별적인 비밀번호 추측 공격이 들어올 경로 자체가 차단된 상태야. 보안의 원칙도 중요하지만, 그 원칙이 적용되는 환경을 먼저 보는 게 실용적인 선택일 때가 있어.”
‘보안과 실용성의 균형’. 솔라는 머릿속에서 맴돌던 단어를 떠올렸다. 언제나 100%의 보안을 지키는 것이 최선이라고 생각했지만, 그를 위해 치러야 할 비용과 복잡성이 때로는 더 큰 실수를 유발할 수도 있겠다는 생각이 들었다. 제한된 내부망 환경, 그리고 실습이라는 명확한 목적. 이 두 가지 조건이 만나니, 비밀번호 인증은 ‘보안 수준을 낮추는 행위’가 아니라 ‘상황에 맞는 합리적인 선택’이 되었다.
이제 망설일 이유가 없었다. 솔라는 마침내 키보드 위에서 확신에 찬 움직임으로 타이핑을 시작했다.
먼저, Web2 서버의 루트 계정에 비밀번호를 설정했다.
[ec2-user@web2 ~]$ sudo passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.다음으로, 가이드의 핵심 지시였던 SSH 설정 파일을 열었다.
[ec2-user@web2 ~]$ sudo vi /etc/ssh/sshd_config편집기 안에서 PasswordAuthentication이라는 줄을 찾아 값을 no에서 yes로 바꾸는 것은 이제 더 이상 낯설거나 불안한 작업이 아니었다. 이 한 줄이 어떤 맥락에서 필요한지 완벽하게 이해했기 때문이다.
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication no
PasswordAuthentication yes솔라는 PasswordAuthentication no로 되어있는 줄을 찾아 yes로 수정했다. 그리고 ESC 키를 누른 후 :wq를 입력하여 저장하고 빠져나왔다.
마지막으로 변경된 설정을 시스템에 적용하기 위해 SSH 데몬을 재시작했다.
[ec2-user@web2 ~]$ sudo systemctl restart sshd모든 명령이 오류 없이 실행되었다. 솔라는 검은 터미널 창을 잠시 바라보았다. 처음 이 지시를 마주했을 때의 답답함은 사라지고, 복잡한 문제의 본질을 꿰뚫어 본 듯한 명쾌함이 남았다. 정답이 정해진 것이 아니라, 상황에 맞는 최적의 해답을 찾아가는 것. 그것이 진짜 실력이라는 사실을 깨닫는 순간이었다.