Cloud Service Practice 07
EC2 접속, 보이지 않는 조건들을 파헤치다
연결 버튼을 누르면 접속이 되는 것처럼 보이지만, 실제로는 키 파일 위치, 사용자명, 퍼블릭 주소, 보안 그룹이 모두 맞아야 한다는 점이 잘 보이지 않는다.
근거 · 교안 p50-p54
1장: 연결 버튼이 보여주는 것과 감추는 것
솔라가 노트북 화면을 들여다보며 가볍게 중얼거렸다. “인스턴스 선택, 연결 버튼 클릭, 정보 확인… 간단하네.”
실습 가이드에 나온 한 문장이 머릿속에 맴돌았다. 마치 잘 닦인 고속도로처럼, 클라우드 위에 띄운 내 작은 서버(EC2 인스턴스)에 접속하는 길이 아주 매끄러워 보였다. 솔라는 금방이라도 서버의 주인이 될 것 같은 기분에 의자 등받이에 몸을 기댔다.
“언니, EC2 접속하는 거 생각보다 되게 간단한 것 같아.”
거실에 있던 루나에게 쪼르르 다가가 노트북 화면을 보여주며 솔라가 말했다.
“그냥 이 ‘연결’ 버튼만 누르면 필요한 정보를 다 알려주잖아. 거의 다 된 거나 마찬가지 아니야?”
솔라의 손가락이 가리킨 화면에는 파란색 ‘연결’ 버튼이 선명했다. 루나는 솔라의 화면을 잠시 들여다보았다. ‘연결’이라는 단어가 주는 명쾌함이 때로는 가장 큰 함정이 되기도 한다는 것을 알았다. 저 버튼 뒤에는 눈에 보이지 않는 여러 조건이 복잡하게 얽혀 있었다.
“그래? 그럼 우리 그 화면이 정확히 뭘 알려주는지 한번 자세히 볼까? 솔라 네가 직접 소리 내서 읽어줘.”
루나는 다그치거나 정답을 말해주지 않았다. 그저 솔라가 스스로 발견하도록 작은 멍석을 깔아주었을 뿐이다.
솔라는 자신만만하게 다시 AWS 콘솔의 ‘인스턴스에 연결’ 화면을 열고 ‘SSH 클라이언트’ 탭을 클릭했다. 그리고 화면에 나타난 지시사항을 큰 소리로 읽기 시작했다.
“음, 보자… 1번, SSH 클라이언트를 엽니다. 이건 내 컴퓨터 터미널 열라는 거겠지. 쉽네. 2번, 프라이빗 키 파일이 저장된 디렉터리로 이동합니다… 어라?”
솔라의 목소리에 살짝 금이 갔다. ‘이동’이라는 단어가 마음에 걸렸다. 그냥 파일을 가지고만 있으면 되는 게 아닌가?
“그리고 3번, 다음 명령을 실행합니다… 하면서 명령어가 길게 있네.”
솔라는 화면에 예시로 나온 명령어를 소리 내어 읽었다.
ssh -i "my-key-pair.pem" ec2-user@ec2-192-0-2-0.compute-1.amazonaws.com“그리고… 어? 여기 작은 글씨로 ‘키가 공개적으로 표시되지 않도록 파일 권한을 수정해야 할 수 있습니다’라고도 쓰여있어. 권한 수정?”
자신만만했던 목소리는 어느새 의문으로 가득 찼다. ‘연결’ 버튼을 누르니 펼쳐진 것은 간단한 접속 완료 창이 아니라, 마치 조립 설명서 같은 낯선 지시들의 목록이었다.
솔라가 고개를 갸웃거리자 루나가 조용히 물었다.
“어때? ‘연결’ 버튼 하나 누르는 걸로 끝나는 일이었어?”
“아니… 전혀 아니네. 이건 그냥 ‘접속 설명서’를 보여주는 거였구나.”
솔라는 허탈하게 웃었다. “나는 저 버튼을 누르면 뭔가 마법처럼 뿅 하고 서버 문이 열리는 줄 알았지. 이건 그냥 요리법 카드 같은 거였어. 재료 목록이랑 조리 순서가 빼곡히 적힌.”
그 순간, 아까 무심코 지나쳤던 실습 가이드의 문장이 다시 떠올랐다.
‘인스턴스를 선택 후 연결 버튼을 눌러서 접속 정보를 확인합니다.’
이제 그 문장이 완전히 다르게 읽혔다. ‘정보를 확인한다’는 말은 ‘접속이 완료되었음을 확인한다’는 뜻이 아니었다. 접속에 필요한 ‘조건들의 목록’을 바로 여기서 확인하라는 의미였던 것이다. 버튼 하나로 모든 게 해결된다는 생각은 섣부른 오해였다.
“맞아. 그 버튼은 목적지로 순간이동 시켜주는 문이 아니라, 목적지까지 가는 길이 그려진 지도를 주는 곳이야. 그 지도에는 여러 조건이 적혀 있지.”
루나는 화면을 가리켰다. “네가 방금 읽은 것만 봐도, 성공적인 접속을 위해서는 적어도 네 가지는 필요해 보이는데.”
루나의 말에 솔라는 고개를 끄덕이며 화면의 내용을 다시 짚었다. “응. 우선 내 컴퓨터에 있는 ‘인증서 키 파일’. 그리고 서버의 고유한 ‘퍼블릭 주소’. 또 서버에 로그인할 ‘사용자 이름’. 마지막으로 이 모든 걸 올바른 순서로 조합한 ‘접속 명령어’. 이 네 가지가 모두 정확하게 맞물려야만 문이 열리는 거구나.”
이제야 안개가 걷히는 기분이었다. 복잡해 보이기만 하던 과정이 몇 개의 핵심 조건으로 정리되자, 무엇을 해야 할지 명확해졌다. 솔라는 한결 후련한 표정으로 자신감이 붙어 말했다.
“좋아! 그럼 이제 이 명령어를 그대로 복사해서 터미널에 붙여넣기만 하면 되겠네. 키 파일은 아까 인스턴스 만들 때 다운로드 받아뒀으니까!”
그 말에 루나는 아무 대답 없이 옅은 미소만 지었다. 솔라의 손가락이 터미널 창으로 향하는 것을 보면서, 지도의 두 번째 줄을 아직 제대로 읽지 않았다는 것을 알 수 있었다.
키 파일을 그냥 ‘가지고 있는 것’만으로는 충분하지 않다는 사실을, 솔라는 곧 몸으로 배우게 될 터였다.
2장: 보이지 않는 키 파일의 조건: 위치와 권한
솔라는 자신감에 차 있었다. 이제 접속에 필요한 조건들을 파악했으니, 실행만 남았다. 그녀는 노트북의 검은 터미널 창을 열었다. 하얀 커서가 무심하게 깜빡이고 있었다.
조금 전 AWS 콘솔에서 복사해 둔 긴 명령어를 그대로 붙여넣고, 솔라는 망설임 없이 엔터 키를 눌렀다. 이제 저 멀리 어딘가에 있을 내 서버의 문이 활짝 열릴 터였다. 하지만 화면에 나타난 것은 환영 인사가 아니었다.
ssh: my-key-pair.pem: No such file or directory“어? 파일이 없다고?”
솔라는 황당한 표정으로 화면을 들여다봤다. 분명히 인스턴스를 만들 때 ‘my-key-pair.pem’ 파일을 다운로드했고, 지금도 ‘다운로드’ 폴더에 잘만 있었다. 컴퓨터가 거짓말을 하는 것 같았다.
“언니, 이상해. 키 파일이 여기 있는데 왜 없다고 나오지?”
솔라의 목소리에는 당혹감이 묻어났다. 루나는 솔라의 노트북 화면으로 다가와, 터미널 창과 파일 탐색기 창을 나란히 보았다. 한쪽에는 솔라의 홈 디렉터리 경로(~)가, 다른 한쪽에는 ‘다운로드’ 폴더 안의 키 파일이 보였다.
“터미널은 지금 네가 서 있는 바로 그 자리에서만 키를 찾고 있어. 그런데 네 키는 저쪽 방에 있잖아.”
루나는 터미널의 현재 경로를 손가락으로 가리켰다가, ‘다운로드’ 폴더를 가리켰다.
“아…”
그제야 솔라는 자신이 놓친 것을 깨달았다. 아까 대충 읽고 넘어갔던 접속 설명서의 두 번째 줄. ‘프라이빗 키 파일이 저장된 디렉터리로 이동합니다.’ 단순히 파일을 가지고 있는 것과, 그 파일이 있는 ‘위치’에서 명령을 실행하는 것은 전혀 다른 문제였다. 터미널이라는 깐깐한 집사는 문 앞에 서서 열쇠를 달라고 하는데, 자신은 거실에 열쇠를 던져두고는 문을 열어달라고 소리치고 있었던 셈이다.
“그렇구나. 내가 그 키가 있는 곳으로 직접 가야 하는 거였어.”
솔라는 cd ~/Downloads 명령어를 입력해 키 파일이 있는 ‘다운로드’ 폴더로 이동했다. 이제야 제대로 된 위치에 섰다. 그녀는 다시 한번 자신감을 갖고 아까와 똑같은 SSH 명령어를 입력했다. 이번에야말로 성공이겠지.
하지만 터미널은 또다시 냉정하게 접속을 거부했다. 이번에는 훨씬 더 알 수 없는 메시지였다.
| 오류 메시지 | 의미 |
|---|---|
Permissions 0644 for 'my-key-pair.pem' are too open. | 키 파일의 권한이 너무 공개적이어서 위험하다고 판단되어 접속을 거부합니다. |
“권한이 너무 열려있다고? 이게 무슨 소리야?”
솔라는 미간을 찌푸렸다. 위치를 맞췄더니 이제는 권한 타령이라니. 점점 미궁으로 빠지는 기분이었다.
“서버 입장에서 생각해봐.”
루나가 차분하게 말했다.
“그 키는 너만 가지고 있어야 하는 아주 중요한 비밀 열쇠야. 그런데 지금 그 열쇠가 ‘누구나 볼 수 있게 길에 놓여있는 상태’라고 서버에게 알려주고 있는 거야. 그런 불안한 열쇠를 받고 문을 열어줄 리가 없지.”
루나의 말에 솔라는 AWS 콘솔 창에서 스치듯 봤던 작은 경고 문구를 떠올렸다. ‘키가 공개적으로 표시되지 않도록 파일 권한을 수정해야 할 수 있습니다.’ 그저 참고사항인 줄 알았는데, 이것 역시 접속을 위한 필수 조건이었던 것이다.
“그럼 이 키를 ‘나만 볼 수 있는 상태’로 만들어야 하는구나.”
“바로 그거야. 서버가 안심할 수 있도록, 키의 보안 등급을 높여주는 거지.”
솔라는 안내에 따라 chmod 400 my-key-pair.pem 명령을 터미널에 입력했다. 이 숫자가 정확히 무엇을 의미하는지는 몰랐지만, ‘오직 소솔라만 읽을 수 있다’는 뜻이라는 루나의 설명에 고개를 끄덕였다. 이제 열쇠를 안전한 주머니 속에 넣었다.
마지막으로, 솔라는 숨을 한번 고르고 다시 SSH 명령어를 실행했다.
엔터.
잠시의 정적 후, 화면의 내용이 바뀌었다. 낯선 환영 문구와 함께, 명령어 프롬프트가 ec2-user@...로 변해 있었다. 드디어 서버에 접속된 것이다!
“됐다! 들어왔어!”
솔라는 안도의 한숨과 함께 작은 환호성을 질렀다. 몇 번의 실패 끝에 마침내 문을 연 기분은 짜릿했다. 그녀는 자신이 지나왔던 길을 되돌아보았다.
‘연결’ 버튼 뒤에 숨어 있던 지도. 그 지도에 적힌 첫 번째 조건 ‘키 파일’은 그저 ‘가지고 있기만 하면 되는’ 물건이 아니었다. 올바른 위치로 찾아가, 적절한 권한을 손에 쥐고 사용해야만 비로소 제 역할을 하는, 두 개의 보이지 않는 조건이 결합된 도구였다.
이제 실습 가이드의 문장이 완전히 새롭게 보였다.
‘SSH 클라이언트 방식에서는 다운로드한 user*-key.pem 파일 위치로 이동하고, 안내된 ssh 명령을 사용한다.’*
‘이동하고’라는 단어가 품고 있던 무게를, 이제는 온전히 이해할 수 있었다. 솔라는 성공적으로 실행된 명령어를 가만히 들여다보았다. 키 파일의 미스터리는 풀렸지만, 여전히 궁금증이 남았다.
“좋아, -i "my-key-pair.pem"은 이제 알겠어. 그럼 그 뒤에 붙는 ec2-user는 누구고, 이 길고 복잡한 주소는 정확히 어떤 문을 가리키는 걸까?“
3장: SSH 명령의 세 부분: 사용자, 주소, 그리고 역할
마침내 서버에 접속한 솔라는 안도의 한숨과 함께 화면에 떠 있는 명령어를 가만히 들여다보았다. 까다로운 비밀번호처럼 보였던 키 파일의 조건, 즉 위치와 권한의 미스터리는 풀렸다. 하지만 성공적으로 실행된 명령어는 또 다른 질문을 던지고 있었다.
ssh -i "my-key-pair.pem" ec2-user@ec2-192-0-2-0.compute-1.amazonaws.com솔라의 시선은 명령어의 뒷부분, ec2-user@...에 머물렀다. 키 파일이 현관 열쇠라면, 이 부분은 대체 무엇일까. 그냥 복사해서 붙여넣은 이 글자들이 사실은 어떤 중요한 역할을 하고 있는 건 아닐까?
그때 루나가 옆에 앉아 작은 메모지를 내밀었다. 메모지에는 솔라가 입력했던 명령어가 세 부분으로 나뉘어 적혀 있었다.
| 도구 (어떻게) | 신분 (누가) | 목적지 (어디로) |
|---|---|---|
ssh -i "my-key-pair.pem" | ec2-user | @ec2-192-0-2-0.compute-1.amazonaws.com |
“명령어는 한 덩어리가 아니야. 이렇게 세 부분으로 이루어진 하나의 문장 같은 거지.”
루나의 말에 솔라는 고개를 끄덕였다. “열쇠를 가지고, 내가 누구인지 밝히고, 어느 집 문을 두드릴지 말하는 거네. 그런데 ‘ec2-user’라는 건 그냥 기본 사용자 이름이니까, 다른 이름으로 들어가도 되지 않을까? 예를 들면 최고 관리자인 ‘root’ 같은 걸로.”
그럴듯한 추측이었다. 더 높은 권한을 가진 이름으로 들어가면 더 많은 일을 할 수 있을 것 같았다. 솔라는 ec2-user 부분을 root로 바꿔서 명령어를 다시 입력하고 엔터 키를 눌렀다.
결과는 즉각적인 거절이었다.
| 시도한 명령어 | 결과 |
|---|---|
ssh -i "my-key-pair.pem" root@ec2-192-0-2-0.compute-1.amazonaws.com | Permission denied (publickey,gssapi-keyex,gssapi-with-mic) |
“어라? 이번엔 권한이 거부됐네. 키 파일 권한은 아까 고쳤는데.”
솔라는 혼란스러웠다. 키 파일의 권한 문제(Permissions are too open)와는 다른, Permission denied (publickey)라는 메시지가 나타났다.
“네가 가진 ‘my-key-pair.pem’ 열쇠는 ‘ec2-user’의 집 현관문에만 맞는 열쇠거든. ‘root’의 집 문은 다른 열쇠를 사용해. 서버는 네가 엉뚱한 열쇠로 문을 열려고 하니까 ‘공개 키 인증 실패’, 즉 맞는 키가 아니라고 알려주는 거야.”
“아!”
솔라의 눈이 동그래졌다. “그럼 ec2-user라는 건 그냥 형식적으로 쓰는 이름이 아니라, 내가 가진 키 파일과 한 쌍으로 묶여있는, 유일하게 허가된 신분이었구나!”
이제야 ec2-user라는 이름의 의미가 명확해졌다. 키 파일이 열쇠라면, 사용자명은 그 열쇠로 열 수 있는 단 하나의 자물쇠를 지정하는 것이었다.
“좋아, 그럼 신원은 해결됐고… 이제 목적지. 이 주소는 틀리면 어떻게 되는데?”
솔라는 이번엔 명령어의 가장 마지막 부분, 길고 복잡한 서버 주소를 일부러 틀리게 고쳐봤다. 중간에 숫자 하나를 0에서 1로 바꾸고 다시 접속을 시도했다.
이번에는 아까와 반응이 완전히 달랐다. 화면은 한참 동안 아무런 응답이 없다가, 결국 이런 메시지를 뱉어냈다.
ssh: connect to host ec2-192-0-2-1.compute-1.amazonaws.com port 22: Connection timed out“연결 시간 초과? 이번엔 아예 대답도 안 하네.”
“그렇지. 아까는 서버가 ‘너는 들어올 자격이 없어’라고 대답이라도 해줬지만, 지금은 네가 외치는 소리를 들을 서버 자체가 그 주소에 존재하지 않는 거야. 없는 집에 대고 문을 두드리고 있는 셈이지.”
루나의 비유에 솔라는 무릎을 쳤다. 사용자명을 틀렸을 때는 ‘인증 실패’라는 거절의 응답이 왔지만, 주소를 틀리자 ‘대상을 찾을 수 없음’이라는 침묵이 돌아왔다. 두 실패는 원인이 완전히 달랐다.
솔라는 다시 루나가 그려준 메모지를 들여다봤다. 이제 각 부분이 선명한 역할을 가진 독립된 부품으로 보였다.
ssh -i "my-key-pair.pem": 인증 도구. ‘이 열쇠로 들어갈게.’ec2-user: 신원. ‘ec2-user라는 이름으로 들어갈게.’@ec2-192-0-2-0...: 목적지 주소. ‘이 주소에 있는 서버로 들어갈게.’
이 세 가지 조건이 모두 완벽하게 맞물렸을 때만 접속이라는 결과가 만들어지는, 하나의 정교한 절차였던 것이다. ‘명령어 복사-붙여넣기’라는 단 하나의 행동 뒤에는 이렇게 여러 단계의 검증이 숨어 있었다.
실습 가이드에 적혀 있던 문장이 다시 떠올랐다.
‘접속 대상은 퍼블릭 IP 또는 퍼블릭 DNS이며 기본 사용자명은 ec2-user다.’
처음에는 그저 암기해야 할 규칙처럼 보였던 이 문장이, 이제는 당연한 사실을 설명하는 것처럼 느껴졌다. 퍼블릭 주소는 유일한 ‘목적지’를, ec2-user는 허가된 ‘신원’을 가리키는 것이었다.
“이제 알겠어. 키, 사용자, 주소. 이 세 가지가 접속의 3요소였구나. 마치 소포를 보낼 때 보내는 사람, 받는 사람, 주소가 정확해야만 제대로 전달되는 것처럼!”
솔라는 자신이 겪었던 실패의 경험들을 통해 명령어의 구조를 꿰뚫어 본 것 같아 뿌듯했다. 이제 EC2 접속에 대해서는 모든 것을 이해했다고 생각한 순간, 루나가 AWS 콘솔 화면의 다른 곳을 가리켰다. 인스턴스의 ‘보안’ 탭에 있는 ‘인바운드 규칙’이었다.
“맞아. 그 세 가지가 모두 정확해야 해. 하지만 우리가 가진 키로, 올바른 사용자가, 정확한 주소의 문을 두드려도… 그 집에 도착하기까지의 길이 막혀 있다면 어떨까?”
루나의 질문에 솔라의 자신감 넘치던 표정에 다시 옅은 물음표가 떠올랐다. 보이지 않는 조건이 아직 하나 더 남아있는 듯했다.