SSH 완전 정복: 원격 서버에 '안전하게' 접속하는 기술

들어가며: 10,000km 떨어진 서버를 어떻게 조종할까?

금요일 밤 11시. 서울의 한 스타트업 개발자가 슬랙 알림을 받는다. "프로덕션 서버 응답 없음." 서버는 미국 동부 버지니아(us-east-1)의 AWS 데이터센터에 있다. 직선거리로 약 11,000km. 비행기를 타면 14시간이 걸린다.

하지만 이 개발자는 자리에서 일어나지 않는다. 노트북을 열고 터미널에 한 줄을 친다:

3초 뒤, 서울의 노트북 화면에 버지니아 서버의 쉘 프롬프트가 뜬다. 마치 그 서버 앞에 직접 앉아 있는 것처럼 명령어를 입력하고, 로그를 확인하고, 프로세스를 재시작한다. 15분 만에 문제를 해결하고 다시 넷플릭스를 켠다.

이 모든 것을 가능하게 하는 기술이 SSH(Secure Shell)다.

클라우드 컴퓨팅 시대에 서버는 더 이상 사무실 전산실에 있지 않다. 전 세계 데이터센터에 흩어져 있다. 이 서버들을 원격으로 관리하려면, 네트워크를 통해 안전하게 접속하는 방법이 필요하다. SSH는 그 방법의 사실상 표준이다.

이 글에서는 SSH가 왜 필요해졌는지(Telnet의 치명적 결함), 어떻게 작동하는지(암호화와 인증), 실무에서 어떻게 쓰는지(키 생성, 터널링, 파일 전송), 그리고 클라우드 환경에서 SSH를 안전하게 운용하는 방법까지 — 완전히 정복한다.

1. SSH 이전의 세계: Telnet과 치명적 결함

1969년, 원격 접속의 시작

인터넷의 전신인 ARPANET 시절부터 사람들은 원격 컴퓨터에 접속할 필요가 있었다. 이를 위해 1969년에 만들어진 프로토콜이 Telnet(Teletype Network)이다. RFC 15로 시작해 1983년 RFC 854로 표준화되었다.

Telnet의 동작은 단순했다. 클라이언트가 서버의 23번 포트에 TCP 연결을 맺고, 사용자가 입력하는 키보드 입력을 그대로 서버에 전송하고, 서버의 출력을 그대로 화면에 표시한다. 마치 아주 긴 케이블로 서버의 모니터와 키보드를 연결한 것과 같다.

1990년대 초반까지 Telnet은 원격 접속의 표준이었다. 대학교 전산실, 기업의 유닉스 서버, 인터넷 초기의 BBS — 모두 Telnet으로 접속했다.

치명적 결함: 모든 것이 평문

문제는 Telnet이 모든 데이터를 암호화 없이 평문(plaintext)으로 전송한다는 것이다.

사용자 이름, 비밀번호, 입력하는 모든 명령어, 서버가 보내는 모든 출력 — 네트워크를 지나가는 모든 바이트가 누구나 읽을 수 있는 상태로 전송된다.

이것은 마치 엽서에 비밀번호를 적어 보내는 것과 같다. 우체국 직원, 배달부, 옆집 사람 — 엽서를 손에 든 사람은 누구나 내용을 읽을 수 있다.

초기 인터넷에서는 이것이 큰 문제가 아니었다. 네트워크 참여자가 소수의 신뢰할 수 있는 대학과 연구기관이었기 때문이다. 하지만 인터넷이 상용화되고 수백만, 수억 명이 연결되면서 상황이 완전히 바뀌었다.

패킷 스니핑(Packet Sniffing) — 네트워크를 흘러가는 데이터를 중간에서 가로채 읽는 공격 — 이 현실적인 위협이 되었다. 같은 네트워크에 있는 누군가가 Wireshark 같은 도구를 실행하면, Telnet으로 전송되는 비밀번호를 문자 그대로 읽을 수 있었다.

Telnet vs SSH: 근본적 차이

이 상황에서, 핀란드의 한 대학원생이 결정적인 한 걸음을 내딛는다.

2. SSH의 탄생: 핀란드 대학원생의 분노

1995년, 헬싱키 공과대학교

타투 일뢰넨(Tatu Ylönen)은 핀란드 헬싱키 공과대학교(Helsinki University of Technology)의 연구원이었다. 1995년, 그의 대학 네트워크에서 패스워드 스니핑 공격이 발생했다. 수천 개의 사용자 이름과 비밀번호가 유출되었다.

일뢰넨은 분노했다. 그리고 직접 해결책을 만들기로 했다. 그가 3개월 만에 개발한 프로토콜이 SSH-1(Secure Shell version 1)이다. 1995년 7월에 무료로 공개했다.

SSH의 핵심 아이디어는 단순했다:

클라이언트와 서버 사이의 모든 통신을 암호화하자.

공개 직후 폭발적인 반응을 얻었다. 배포 후 몇 달 만에 전 세계 50개국에서 2만 명 이상이 사용했다. "더 이상 Telnet 쓰지 마세요"가 시스템 관리자들 사이에서 상식이 되기 시작했다.

SSH-2: 프로토콜의 진화

SSH-1에는 몇 가지 설계상 취약점이 있었다. 2006년에 SSH-2가 RFC 4251~4256으로 IETF 표준이 되었다. SSH-2는 SSH-1과 호환되지 않는 완전히 새로운 프로토콜로, 더 강력한 암호화, 더 나은 무결성 검증, 그리고 채널 멀티플렉싱을 지원한다.

OpenSSH: 오픈소스의 승리

일뢰넨의 SSH는 점차 상용화되었고, 라이선스 제약이 생겼다. 이에 OpenBSD 팀이 1999년, SSH-1의 초기 자유 라이선스 버전을 기반으로 OpenSSH를 만들었다. 이후 OpenSSH는 세계에서 가장 널리 쓰이는 SSH 구현이 되었다.

오늘날 macOS 터미널을 열면 ssh 명령어가 이미 설치되어 있다. Windows 10부터는 OpenSSH 클라이언트가 기본 포함된다. 리눅스는 말할 것도 없다. SSH는 인터넷 인프라의 공기와 같은 존재가 되었다.

3. SSH는 어떻게 작동하는가: 암호화의 3단계

SSH 연결이 맺어질 때, 내부에서는 세 가지 단계가 순서대로 진행된다. 각 단계를 하나씩 살펴보자.

1단계: 키 교환 (Key Exchange)

클라이언트가 서버에 연결하면, 가장 먼저 대칭 암호화에 사용할 세션 키(session key)를 안전하게 공유해야 한다. 문제는 이 키를 네트워크를 통해 전송하면 도청당할 수 있다는 것이다.

이 문제를 해결하는 것이 Diffie-Hellman 키 교환 알고리즘이다. 1976년에 발명된 이 알고리즘은 "열린 공간에서, 비밀을 전혀 전송하지 않고도, 양쪽이 같은 비밀 값을 공유할 수 있다"는 놀라운 속성을 가진다.

비유하면 이렇다. 두 사람이 각각 비밀 색상을 하나 고른다. 공개된 색상(예: 노란색)을 섞어 자신의 비밀 색상과 혼합한 뒤 상대에게 보낸다. 상대는 받은 혼합 색상에 자기 비밀 색상을 다시 섞는다. 놀랍게도 양쪽이 최종적으로 같은 색상을 얻지만, 중간에 지켜본 사람은 원래의 비밀 색상을 알아낼 수 없다.

실제 SSH에서는 색상 대신 거대한 소수(prime number)와 수학적 연산을 사용하며, 현대 SSH는 주로 Curve25519 기반의 ECDH(Elliptic Curve Diffie-Hellman)를 사용한다.

2단계: 서버 및 사용자 인증

키 교환이 끝나면 암호화된 채널이 열린다. 이제 두 가지 인증이 필요하다:

서버 인증 (Host Key Verification): 내가 접속하려는 서버가 진짜 그 서버인지 확인한다. SSH에 처음 접속하면 이런 메시지를 본 적이 있을 것이다:

yes를 입력하면 이 서버의 공개 키가 ~/.ssh/known_hosts 파일에 저장된다. 다음에 같은 서버에 접속할 때, 서버의 키가 바뀌어 있으면 SSH는 경고를 띄운다. 누군가가 가짜 서버로 바꿔치기한 것일 수 있기 때문이다. 이것이 중간자 공격(Man-in-the-Middle Attack) 방어의 핵심이다.

사용자 인증: 서버가 진짜임을 확인한 후, 이번에는 사용자가 자신의 신원을 증명한다. 방법은 두 가지다:

1. 비밀번호 인증 — 사용자가 비밀번호를 입력
2. 공개 키 인증 — 사용자의 키 쌍으로 인증 (다음 섹션에서 자세히)

3단계: 암호화된 세션

인증이 완료되면, 이후의 모든 데이터는 1단계에서 합의한 세션 키로 대칭 암호화(AES-256-GCM 등)되어 전송된다. 명령어 입력, 서버 출력, 파일 전송 — 모든 것이 암호화된다. 중간에 누가 패킷을 가로채도 의미 없는 바이트 덩어리만 보인다.

4. 비밀번호 인증 vs 키 기반 인증

SSH로 서버에 접속할 때, 사용자 인증 방식은 크게 두 가지다. 비밀번호와 키 기반 인증. 둘의 차이를 이해하는 것은 SSH 보안의 핵심이다.

비밀번호 인증: 익숙하지만 위험한

가장 직관적인 방식이다. ssh user@server를 입력하면 비밀번호를 묻고, 맞으면 접속된다.

비밀번호 자체는 SSH의 암호화된 채널을 통해 전송되므로 Telnet처럼 평문으로 노출되지는 않는다. 하지만 근본적인 문제가 있다:

• 브루트포스 공격: 자동화된 봇이 수천 가지 비밀번호를 계속 시도할 수 있다
• 비밀번호 재사용: 사람들은 여러 서비스에 같은 비밀번호를 쓴다. 하나가 유출되면 전부 위험하다
• 숄더 서핑: 누군가 옆에서 비밀번호 입력을 지켜볼 수 있다
• 관리 부담: 서버가 100대면 비밀번호 100개를 관리해야 한다

키 기반 인증: 비밀번호 없이, 더 안전하게

키 기반 인증은 수학적으로 연결된 한 쌍의 키를 사용한다:

• 개인 키(Private Key): 내 컴퓨터에만 존재. 절대 외부에 공개하지 않는다. 나의 도장
• 공개 키(Public Key): 서버에 등록. 누구에게 공개해도 상관없다. 나의 인감증명서

인증 과정을 간략히 설명하면:

1. 서버가 랜덤한 "챌린지(challenge)" 데이터를 보낸다
2. 클라이언트는 개인 키로 이 데이터에 서명(sign)한다
3. 서버는 등록된 공개 키로 서명을 검증한다
4. 서명이 유효하면 인증 성공

이 과정에서 개인 키 자체는 네트워크를 통해 전송되지 않는다. 서명만 전송된다. 공개 키로 서명을 검증할 수는 있지만, 공개 키로부터 개인 키를 역산하는 것은 수학적으로 불가능하다.

비밀번호 vs 키: 비교

5. 실전: SSH 키 생성부터 접속까지

이론은 충분하다. 이제 실제로 SSH 키를 만들고, 서버에 등록하고, 접속해 보자.

5-1. ssh-keygen: 키 쌍 만들기

각 옵션을 설명하면:

• -t ed25519: 키 알고리즘 지정. Ed25519는 현재 가장 권장되는 알고리즘이다. RSA보다 짧은 키 길이에 동등 이상의 보안을 제공하고 서명/검증 속도도 빠르다
• -C "email": 코멘트. 키를 식별하기 위한 라벨. 관리 편의를 위해 이메일을 넣는다
• 패스프레이즈(passphrase): 개인 키를 암호화하는 비밀번호. 개인 키 파일이 유출되어도 패스프레이즈 없이는 사용 불가. 반드시 설정하는 것을 권장한다

생성 결과 두 개의 파일이 만들어진다:

5-2. ssh-copy-id: 서버에 공개 키 등록

키를 만들었으면, 접속하려는 서버에 공개 키를 등록해야 한다. 가장 편리한 방법은 ssh-copy-id다:

이 명령은 내부적으로 서버의 ~/.ssh/authorized_keys 파일에 공개 키를 추가한다. 이후부터는 비밀번호 없이 키로 접속할 수 있다.

비밀번호를 묻지 않는다. 키 교환 → 서명 검증이 자동으로 진행되었기 때문이다.

5-3. ~/.ssh/config: SSH를 편하게 쓰는 비결

서버가 여러 대라면 매번 ssh ubuntu@54.172.xx.xx -i ~/.ssh/my-key -p 2222를 입력하는 것은 고통이다. ~/.ssh/config 파일을 설정하면 별칭(alias)으로 간단히 접속할 수 있다:

이제 이렇게만 입력하면 된다:

~/.ssh/config에서 자주 쓰는 설정들:

6. SSH 터널링: 암호화된 비밀 통로

SSH의 진정한 힘은 단순한 원격 접속을 넘어선다. SSH는 암호화된 터널을 만들어, 일반적으로는 접근할 수 없는 네트워크 리소스에 안전하게 도달하는 통로 역할을 한다. 이것이 SSH 포트 포워딩(Port Forwarding), 흔히 SSH 터널링이라 불리는 기능이다.

로컬 포트 포워딩 (Local Port Forwarding)

"내 컴퓨터의 포트를 통해 원격 서버 뒤에 있는 서비스에 접근한다."

가장 흔한 시나리오: 프로덕션 데이터베이스(RDS)가 프라이빗 서브넷에 있어서 직접 접근할 수 없다. 하지만 같은 VPC의 EC2 인스턴스는 접근 가능하다.

-L 로컬포트:원격호스트:원격포트 형식이다. 내 컴퓨터의 3306 포트에 접속하면, SSH 터널을 타고 EC2를 경유해서 db.internal:3306(RDS)에 도달한다.

리모트 포트 포워딩 (Remote Port Forwarding)

"원격 서버의 포트를 통해 내 컴퓨터의 서비스를 노출한다."

예를 들어, 내 노트북에서 개발 중인 웹 앱(localhost:3000)을 동료에게 보여주고 싶은데, 내 노트북은 NAT 뒤에 있어서 직접 접근이 안 된다.

-R 원격포트:로컬호스트:로컬포트 형식이다. 방향이 반대임에 주의하라.

동적 포트 포워딩 (Dynamic Port Forwarding)

"SSH 서버를 SOCKS 프록시로 사용한다."

특정 포트 하나가 아니라, 모든 트래픽을 SSH 터널로 보낸다. 사실상 간이 VPN이다.

세 가지 터널링 비교

7. SCP와 SFTP: SSH로 파일 전송하기

서버에 접속하는 것만큼 자주 하는 일이 파일 전송이다. SSH 위에 구축된 두 가지 파일 전송 도구가 있다.

SCP (Secure Copy Protocol)

cp 명령어의 네트워크 버전이다. 파일을 SSH 채널을 통해 암호화 전송한다.

SCP는 단순하고 빠르다. 하지만 파일 목록 조회, 이어받기, 디렉토리 탐색 등 고급 기능은 없다.

SFTP (SSH File Transfer Protocol)

FTP와 비슷한 인터페이스를 제공하지만, SSH 위에서 동작해 모든 데이터가 암호화된다. 기존의 FTP(평문 전송)를 완전히 대체한다.

SCP vs SFTP 비교

8. 클라우드 환경에서의 SSH

클라우드, 특히 AWS에서는 SSH가 어떻게 쓰이는지 살펴보자. 온프레미스와는 다른 패턴들이 있다.

EC2 키 페어

AWS EC2 인스턴스를 생성할 때, AWS 콘솔에서 키 페어(Key Pair)를 만들거나 기존 키를 지정한다. AWS가 하는 일은:

1. RSA 또는 ED25519 키 쌍을 생성한다
2. 공개 키를 EC2 인스턴스의 ~/.ssh/authorized_keys에 자동 등록한다
3. 개인 키(.pem 파일)를 다운로드하게 한다 (이 기회가 처음이자 마지막이다!)

배스천 호스트 (Bastion Host / Jump Box)

프로덕션 환경에서는 EC2 인스턴스를 퍼블릭 서브넷에 직접 노출하지 않는다. 프라이빗 서브넷에 배치하고, SSH 접속은 배스천 호스트라는 단일 진입점을 통해서만 허용한다.

SSH의 ProxyJump 기능을 사용하면 배스천을 경유하는 것이 한 줄로 가능하다:

AWS Systems Manager Session Manager: SSH를 넘어서

최근 AWS는 SSH의 대안으로 Session Manager를 제공한다. SSH 포트(22)를 열지 않아도 EC2에 접속할 수 있다.

Session Manager는 "SSH 포트를 아예 닫을 수 있다"는 점에서 보안 관점의 큰 진보다. 하지만 SSH를 완전히 대체하지는 못한다. SCP/SFTP 같은 파일 전송, 복잡한 터널링, AWS 외부 서버 접속 — 이런 경우에는 여전히 SSH가 필요하다.

9. SSH 보안 모범 사례: 현실적인 10가지

SSH 자체는 안전한 프로토콜이다. 하지만 설정을 잘못하면 아무리 좋은 자물쇠도 무용지물이 된다. 프로덕션 환경에서 반드시 적용해야 할 보안 설정을 정리한다.

서버의 SSH 설정 파일은 /etc/ssh/sshd_config다. 아래 설정들을 적용한 후 sudo systemctl restart sshd로 SSH 데몬을 재시작한다.

9-1. root 직접 로그인 비활성화

root는 시스템의 최고 권한 계정이다. root로 직접 SSH 접속을 허용하면, 공격자가 root 비밀번호만 뚫으면 시스템 전체를 장악한다. 일반 계정으로 접속한 뒤 sudo를 사용하는 것이 안전하다.

9-2. 비밀번호 인증 비활성화

키 기반 인증만 허용한다. 비밀번호 인증을 끄면 브루트포스 공격이 원천적으로 불가능하다.

9-3. SSH 포트 변경

기본 22번 포트를 변경하면 자동화된 봇의 스캔을 상당수 회피할 수 있다. 보안의 근본적 해결책은 아니지만(security through obscurity), 불필요한 공격 시도를 줄여 로그를 깨끗하게 유지하는 데 도움이 된다.

9-4. fail2ban 설치

fail2ban은 반복적으로 로그인을 실패하는 IP를 자동으로 차단(ban)한다. 기본 설정으로 5회 실패 시 10분간 차단. 설정에 따라 영구 차단도 가능하다.

9-5. 접속 허용 사용자 제한

시스템에 계정이 많더라도, SSH 접속이 가능한 사용자를 명시적으로 제한한다.

나머지 핵심 설정들

추가로 꼭 알아야 할 설정들:

키 교체 (Key Rotation)

키도 비밀번호처럼 주기적으로 교체해야 한다. 특히:

• 퇴사자 발생 시: 해당 공개 키를 모든 서버의 authorized_keys에서 즉시 제거
• 키 유출 의심 시: 즉시 새 키 쌍 생성, 구 키 폐기, 모든 서버 업데이트
• 정기 교체: 6개월~1년 주기 권장

10. SSH 문제 해결 가이드

SSH 접속이 안 될 때, 당황하지 말고 아래 순서대로 점검하자.

가장 흔한 에러와 해결법

디버깅 체크리스트

마치며: SSH는 클라우드로 가는 다리다

이 글에서 우리는 먼 여정을 했다. Telnet의 평문 전송이라는 치명적 결함에서 출발해, 분노한 핀란드 대학원생이 SSH를 만들고, 그것이 OpenSSH로 발전해 오늘날 인터넷 인프라의 기반이 된 이야기. 키 교환과 암호화의 원리, 비밀번호 대신 키를 써야 하는 이유, 터널링으로 안전한 통로를 만드는 방법, 그리고 클라우드 환경에서의 실전 운용까지.

SSH는 30년이 넘은 기술이다. 하지만 클라우드 시대에 그 중요성은 오히려 커졌다. 서버가 더 이상 건물 안 전산실에 있지 않기 때문이다. 전 세계에 분산된 수십, 수백 대의 서버를 관리하려면, 안전한 원격 접속 기술이 반드시 필요하다. SSH가 바로 그 기술이다.

DX 전문가를 꿈꾸는 여러분에게 SSH는 가장 먼저 익혀야 할 기술 중 하나다. 서버에 접속할 수 없으면 아무것도 할 수 없기 때문이다. 오늘 바로 터미널을 열고 ssh-keygen을 실행해 보자. 첫 번째 키 쌍을 만드는 순간, 클라우드로 가는 다리를 건너기 시작한 것이다.