SSH란 무엇인가?

Atualizado há 1 mês

SSH가 나오기 전, 원격 서버에 로그인하는 것은 마치 사람 가득한 방에서 비밀번호를 큰 소리로 외치면서 올바른 사람만 듣기를 바라는 것과 같았다.

과장이 아니다. 초기 인터넷을 지배했던 원격 접속 프로토콜인 Telnet은 모든 것을 평문으로 전송했다—사용자 이름, 비밀번호, 입력한 모든 명령어, 받은 모든 응답. 사용자와 서버 사이의 네트워크 경로 어딘가에 있는 누구든 전체 대화를 지켜볼 수 있었다. 인증 정보를 가로채서 그냥 걸어 들어올 수 있었던 것이다.

SSH(Secure Shell)는 이 문제를 해결했다. 도청자 눈에는 알아볼 수 없는 데이터만 보일 만큼 강력한 암호화로 모든 것을 감싸버린 것이다. 지금은 서버 관리의 너무나 당연한 요소가 되어, SSH 없는 시절을 떠올리는 것은 마취 없이 수술하는 장면을 상상하는 것과 같다.

핸드셰이크

ssh username@server를 입력하는 순간, 정교하게 맞춰진 절차가 시작된다.

먼저, 서버가 공개 키—자신의 신분증—를 보내온다. 클라이언트는 확인한다: 이 서버를 전에 접속한 적 있는가? 처음이라면, 서버의 핑거프린트를 보여주고 확인을 요청한다. 이게 중요하다. 서버인 척하는 공격자는 다른 핑거프린트를 가질 수밖에 없다. 첫 접속 때 그냥 넘기는 그 경고? 그것이 중간자 공격과 사용자 사이에 서 있는 유일한 방어선이다.

다음이 핵심이다: 키 교환. 한 번도 만난 적 없는 두 컴퓨터가, 신뢰할 수 없는 네트워크를 통해 통신하면서, 공유 비밀을 만들어야 한다. 비밀을 직접 전송하면 중간에서 누구든 가로챌 수 있다. 그래서 비대칭 암호화를 쓴다—양쪽이 각자의 난수를 제공하고, 공개 키와 개인 키를 이용한 수학적 연산을 통해, 비밀 자체는 전송하지 않고도 양쪽이 동일한 공유 비밀에 도달한다. 지켜보는 사람은 교환 과정을 볼 수 있지만 비밀을 알아낼 수는 없다. 이것이 Diffie-Hellman 키 교환이며, 암호학 역사상 가장 우아한 해법 중 하나이다.

공유 비밀이 만들어지면, 실제 세션을 위해 더 빠른 대칭 암호화로 전환한다. 이후 모든 데이터는 암호화된 터널을 통해 오간다. 비밀번호(사용 중이라면), 명령어, 서버의 응답—모두 전송 전에 암호화되고, 도착하면 복호화된다.

인증: 내가 나임을 증명하기

비밀번호 인증은 예상대로 작동한다. 방금 만든 세션 키로 암호화한 비밀번호를 전송하면, 서버가 기록과 대조한다. 단순하고 익숙한 방식이지만, 점점 더 권장되지 않는다.

키 기반 인증은 더 흥미롭다. 키 쌍을 생성한다: 철저히 보관해야 할 개인 키, 누구와도 공유할 수 있는 공개 키. 접근하려는 서버에 공개 키를 등록한다.

접속할 때, 서버는 비밀번호를 묻지 않는다. 대신, 무작위 챌린지를 만들어 사용자의 공개 키로 암호화해 보낸다. 짝이 맞는 개인 키만이 이를 복호화할 수 있다. 클라이언트는 개인 키로 챌린지를 복호화하고, 성공했다는 서명을 돌려보낸다. 서버는 그 서명을 검증한다.

개인 키는 절대 사용자 기기를 벗어나지 않는다. 네트워크를 통해 이동하는 일이 없다. 누군가 SSH 세션의 패킷을 전부 캡처하더라도, 개인 키는 결코 드러나지 않는다. 그래서 많은 조직이 비밀번호 인증을 아예 비활성화하는 것이다—키 기반 인증이 훨씬 안전하다.

SSH 사용하기

기본은 간단하다:

ssh username@hostname

SSH의 기본 포트인 22번으로 hostname에 username으로 접속한다. 서버가 다른 포트를 쓴다면 -p 2222를 추가한다. 특정 개인 키를 지정하려면 -i /path/to/key를 추가한다.

접속하면 원격 기기의 명령 프롬프트가 열린다. 명령어를 입력하고, 출력을 확인한다. 끝나면 exit를 입력한다.

하지만 SSH는 원격 셸 제공 이상을 한다.

보안 파일 전송: scp localfile.txt user@server:/path/는 암호화된 터널로 파일을 복사한다. SFTP는 대화형 파일 탐색 기능을 제공하며, 역시 암호화된다.

포트 포워딩: SSH 암호화를 통해 다른 프로토콜을 터널링한다. ssh -L 8080:localhost:80 user@server를 실행하면 서버의 80번 포트가 로컬 8080번 포트로 연결된다—외부에 노출되지 않은 웹 인터페이스에 접근하거나, 자체 암호화가 없는 프로토콜을 보호할 때 유용하다.

원격 명령 실행: ssh user@server 'df -h'는 대화형 세션 없이 명령어를 실행하고 출력을 반환한다. 자동화 스크립트가 원격 기기와 통신하는 방식이 바로 이것이다.

X11 포워딩: 서버에서 그래픽 애플리케이션을 실행하고 로컬 화면에 표시한다. ssh -X user@server로 활성화할 수 있다—다만 요즘은 GUI 처리에 다른 방법을 많이 쓴다.

설정

같은 옵션을 반복해서 입력하는 건 번거롭다. SSH 설정 파일(Unix 계열 시스템의 ~/.ssh/config)이 이를 해결해 준다:

Host myserver
    HostName 192.168.1.50
    User admin
    Port 2222
    IdentityFile ~/.ssh/myserver_key

이제 ssh myserver만 입력하면 모든 옵션이 자동으로 적용된다.

유용한 설정 옵션들:

연결 다중화: 같은 서버에 대한 새 세션에서 기존 연결을 재사용하여 이후 접속 속도를 크게 높인다
킵얼라이브 메시지: 유휴 연결이 타임아웃되지 않도록 유지한다
에이전트 포워딩 (-A): 원격 서버에서 다른 서버로 SSH 접속할 때 로컬 키를 사용할 수 있다—편리하지만 보안 위험이 따른다

보안 관행

SSH는 설계 자체가 안전하지만, 그래도 잘못 사용하면 위험할 수 있다.

호스트 키를 반드시 확인하라. 첫 접속 때 나오는 핑거프린트 경고는 무의미한 절차가 아니다. 확인 없이 넘기면 공격자에게 인증 정보를 넘겨주는 꼴이 될 수 있다. 이전에 접속한 서버의 핑거프린트가 바뀌었다면, 무언가 잘못된 것이다—진행하기 전에 반드시 확인하라.

개인 키를 보호하라. 파일 권한은 600(본인만 읽기 가능)으로 설정하라. 저장 시 암호화를 위해 패스프레이즈를 추가하라. 버전 관리에 커밋하지 마라. 절대 공유하지 마라.

키 기반 인증이 잘 작동하면 비밀번호 인증을 비활성화하라. 공격 표면을 하나 줄이는 것이다.

루트 로그인을 비활성화하라. 일반 계정으로 접속하고, 필요할 때 sudo로 권한을 높여라.

fail2ban 같은 도구를 사용해 인증에 반복적으로 실패하는 IP를 차단하라—무차별 대입 공격을 원천 차단한다.

SSH를 최신 상태로 유지하라. 취약점이 간헐적으로 발견된다. 업데이트로 해결된다.

어디서나 쓰이는 SSH

SSH는 원격 서버 접속의 공통 언어가 되었다. 시스템 관리자들이 일상적으로 쓰고, 배포 파이프라인이 SSH 위에서 돌아간다. Ansible 같은 구성 관리 도구는 SSH를 전송 수단으로 쓴다. GitHub, GitLab 같은 Git 호스팅 플랫폼도 코드 푸시와 풀을 위해 SSH를 지원한다.

대안이 없는 건 아니다—Windows 그래픽 접근에는 RDP, 불안정한 연결에는 Mosh, 각종 독점 솔루션도 있다. 하지만 Unix 계열 시스템에 대한 보안 명령줄 접속이라면, SSH는 수십 년 전에 이미 표준으로 자리잡았고, 지금도 그 자리를 내줄 기미가 없다.

평문 비밀번호를 수학적 우아함으로 대체한 이 프로토콜은 앞으로도 오랫동안 우리 곁에 남을 것이다.

SSH에 대해 자주 묻는 질문

처음 접속할 때 호스트 키 관련 경고가 뜨는 이유는?

SSH에는 서버를 보증해 주는 중앙 기관이 없다. 처음 접속할 때 직접 신뢰를 확립하는 것이다—클라이언트가 서버의 공개 키 핑거프린트를 저장한다. 이후 누군가 해당 서버를 사칭하려 하면, 핑거프린트가 맞지 않아 SSH가 경고를 보낸다. 가장 취약한 순간은 바로 그 첫 번째 접속이다. 보안이 중요한 상황이라면 별도의 채널을 통해 핑거프린트를 확인해야 하는 이유가 여기 있다.

SCP와 SFTP의 차이는 무엇인가요?

둘 다 SSH를 통해 파일을 전송한다. SCP는 더 단순하다—기기 간에 cp처럼 동작한다. SFTP는 더 많은 기능을 제공한다—디렉터리 탐색, 중단된 전송 재개, 파일 조작이 가능한 대화형 세션을 제공한다. 단순한 복사 스크립트에는 SCP로 충분하다. 대화형이거나 복잡한 작업에는 SFTP가 낫다.

SSH 연결을 감청하면 개인 키를 훔칠 수 있나요?

아니다. 그게 바로 핵심이다. 인증 과정에서 개인 키는 네트워크를 통해 전송되지 않는다. 서버가 공개 키로 암호화한 챌린지를 보내면, 클라이언트는 로컬에서 개인 키로 복호화하고 성공했다는 증명만 돌려보낸다. 패킷을 전부 가로채도 개인 키는 알 수 없다.

포트 포워딩은 언제 쓰나요?

외부에 노출되지 않은 서비스에 접근하거나, 암호화가 없는 프로토콜을 보호할 때 쓴다. 데이터베이스 서버는 보안상 로컬호스트에서만 수신 대기하는 경우가 많다—포트 포워딩을 쓰면 마치 로컬에서 접속하는 것처럼 연결할 수 있다. 암호화 없는 레거시 프로토콜은 SSH 터널로 보호할 수 있다. SSH 접근권은 있지만 다른 포트가 막힌 방화벽을 우회할 때도 유용하다.

SSH 설정 팁

SSH 키 인증

Esta página foi útil?

😔

🤨

😃