SSH

클라우드에 서버를 띄우면 그 서버 앞에 물리적으로 앉을 수 없습니다. 네트워크를 통해 명령을 보내야 하는데, 1990년대까지 주류였던 Telnet이나 rlogin은 입력하는 비밀번호와 명령이 평문으로 네트워크를 흘러갑니다. 공유 네트워크나 인터넷을 거치는 순간 패킷 캡처 도구 하나면 서버 관리 비밀번호를 그대로 읽을 수 있습니다. 서버가 수십 대로 늘고 인터넷 구간을 거쳐야 하는데, 매번 콘솔에 물리적으로 붙는 것도 현실적이지 않습니다. 암호화 없는 원격 접속은 서버 관리 권한을 인터넷에 그냥 열어두는 것과 다름없었습니다.

인터넷 초기에는 Telnet, rlogin, FTP 같은 평문 프로토콜이 원격 접속의 전부였습니다. 네트워크가 대학이나 연구소 내부에 한정돼 있을 때는 도청 위험이 크지 않았지만, 인터넷이 공개 인프라로 확산되면서 상황이 달라졌습니다. 패킷 스니핑으로 서버 관리 비밀번호가 유출되는 사고가 반복됐고, 서버 접근 권한 탈취는 전체 시스템 장악으로 이어졌습니다. 이 보안 위협이 현실 운영 비용이 되면서 원격 접속 트래픽 전체를 암호화하는 프로토콜이 시급해졌습니다. SSH는 1995년 그 필요에 응답해 등장했고, Telnet과 rlogin을 빠르게 대체하며 서버 관리의 표준이 됐습니다.

SSH 연결은 TCP 22번 포트에 일반적인 TCP 세션을 여는 것에서 시작합니다. 연결이 맺어지면 클라이언트와 서버가 프로토콜 버전을 확인하고, Diffie-Hellman 키 교환으로 이번 세션에만 쓸 대칭키를 양쪽이 공유합니다. 이 과정에서 서버는 자신의 호스트 키를 제시하고, 클라이언트는 이전에 저장해둔 키와 맞는지 비교해 서버가 교체됐거나 위조됐는지 확인합니다. 키 교환이 끝나면 이후의 모든 데이터는 암호화된 채널 안에서 이동합니다. 그다음 사용자 인증이 이뤄집니다. 비밀번호 방식은 비밀번호가 암호화된 채널을 통해 서버로 가지만, 공개키 인증은 비밀번호 자체가 네트워크를 지나가지 않습니다. 클라이언트가 자신의 비밀키로 서명한 값을 보내면 서버가 등록된 공개키로 검증하는 방식입니다. 인증이 통과되면 하나의 암호화된 연결 위에 여러 채널을 동시에 열 수 있어서, 셸 세션을 유지하면서 파일을 전송하거나 포트 포워딩을 추가할 수 있습니다.

SSH와 TLS는 둘 다 암호화된 통신 채널을 만들지만 목적과 범위가 다릅니다. TLS는 HTTP, 이메일, 데이터베이스 연결처럼 특정 애플리케이션 프로토콜을 암호화하는 범용 보안 계층입니다. 어떤 프로토콜이든 TLS 위에 올릴 수 있습니다. SSH는 원격 서버 관리에 특화되어 셸 접속, 파일 전송, 포트 포워딩, 사용자 인증을 하나의 프로토콜 안에 통합합니다. 웹 트래픽 암호화에는 TLS가 적합하고, 서버에 접속해 명령을 실행하거나 파일을 옮기는 운영 작업에는 SSH가 맞습니다. 둘은 대체 관계가 아니라 용도가 다른 암호화 계층으로 보는 것이 정확합니다. SSH 터널링과 VPN을 비교하자면, SSH는 특정 서버 접속이나 포트 포워딩처럼 가볍고 목적이 뚜렷한 상황에 적합하고, VPN은 네트워크 전체를 하나의 사설망처럼 이어야 할 때 씁니다.

SSH는 클라우드 인스턴스 접속, 온프레미스 서버 운영, CI/CD 배포 자동화, 원격 파일 전송처럼 서버를 직접 다루는 운영 작업 전반에서 기본 도구로 쓰입니다. 공개키 인증을 설정하면 비밀번호 없이 접속할 수 있어 자동화 파이프라인과 잘 맞고, 포트 포워딩을 이용하면 외부에 노출하지 않은 내부 서비스에 임시로 접근하는 터널을 만들 수 있습니다. 다만 SSH 포트가 열려 있다는 것은 서버 관리 권한에 가까이 갈 수 있는 경로가 존재한다는 뜻이기도 합니다. 22번 포트를 전체 인터넷에 열어 두면 무차별 로그인 시도의 대상이 되기 쉽습니다. 퇴사한 직원의 공개키가 서버에 그대로 남아 있는 경우도 실제 운영에서 드물지 않습니다. SSH를 안전하게 쓰려면 접속 자체보다, 누구의 키를 어떤 서버에 등록하고 어떤 IP에서만 허용할지를 함께 설계해야 합니다.