Cloud Visualizer
← 전체 목록
🔐

SSH

프로토콜원격 서버에 암호화된 셸 접속과 파일 전송을 제공하는 프로토콜

아키텍처 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

클라우드에 서버를 띄우거나 원격 머신을 관리해야 할 때, 그 서버 앞에 직접 앉을 수는 없습니다. 네트워크를 통해 명령을 보내야 하는데, 과거의 Telnet이나 rlogin 같은 방식은 입력하는 비밀번호와 명령어가 평문으로 네트워크를 흘러갑니다. 공유 네트워크나 인터넷을 거치는 순간 누구든 그 트래픽을 가로채서 읽을 수 있고, 서버 관리 권한이 곧바로 노출됩니다. 서버가 한두 대일 때는 물리적 접근으로 넘길 수 있지만, 수십 대의 클라우드 인스턴스를 운영하면서 매번 콘솔에 붙는 것은 현실적이지 않습니다. SSH는 원격 접속의 모든 트래픽을 암호화해서, 네트워크를 신뢰할 수 없는 환경에서도 서버를 안전하게 관리할 수 있게 만든 프로토콜입니다.

왜 이런 방식이 등장했나요?

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

안에서 어떻게 동작하나요?

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

무엇과 헷갈리나요?

SSH와 TLS는 둘 다 암호화된 통신 채널을 만드는 프로토콜이지만 목적과 적용 범위가 다릅니다. TLS는 웹 브라우저와 서버 사이의 HTTP, 이메일, 데이터베이스 연결처럼 특정 애플리케이션 프로토콜을 암호화하는 범용 보안 계층입니다. SSH는 원격 서버 관리에 특화되어 셸 접속, 파일 전송, 포트 포워딩, 사용자 인증까지 하나의 프로토콜 안에서 모두 해결합니다. 웹 트래픽 암호화에는 TLS(HTTPS)가 적합하고, 서버에 원격으로 들어가 명령을 실행하거나 파일을 옮기는 운영 작업에는 SSH가 맞습니다. 둘은 대체 관계보다는 용도가 다른 암호화 계층으로 보는 편이 정확합니다.

언제 쓰나요?

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

서버 관리파일 전송터널링자동화