SSH와 Telnet 차이: 원격 접속에서 Telnet을 운영에 쓰면 안 되는 이유

SSH와 Telnet은 모두 원격 terminal이라는 맥락에서 함께 언급되지만 security model은 전혀 다르다. “보안이 중요하면 SSH, 편리함이 중요하면 Telnet”처럼 선택 가능한 두 대안으로 놓으면 안 된다.

운영 server와 network 장비의 관리 접속에는 SSH처럼 authentication, confidentiality와 integrity를 제공하는 protocol을 사용해야 한다. Telnet은 protocol 실습이나 격리된 legacy 대응 외에는 관리 채널로 권장할 수 없다.

Telnet이 제공하는 것

RFC 854의 Telnet은 TCP connection 위에서 data와 Telnet control 정보를 주고받고, 서로 다른 terminal 표현을 Network Virtual Terminal, NVT로 맞추는 protocol이다.

terminal input
    ↓
Telnet NVT와 option negotiation
    ↓
TCP connection

원격 terminal interoperability가 설계의 중심이지 현대적인 secure channel이 중심이 아니다. 기본 Telnet protocol에는 다음 보장이 없다.

• traffic confidentiality
• message integrity
• server host-key authentication
• 안전한 user credential 보호

같은 VLAN이나 사내 LAN에 있다는 사실도 안전한 경계를 만들지 않는다. 내부 오염 단말, 잘못된 routing·mirroring, 침해된 network 장비와 lateral movement를 고려하면 평문 관리 traffic은 그대로 위험하다.

SSH가 추가하는 보안 경계

SSH architecture는 transport, user authentication, connection protocol을 나눠 secure channel을 만든다.

1. key exchange로 shared secret과 session key material을 만든다.
2. server host key로 접속 대상의 identity를 확인한다.
3. encryption과 integrity protection을 적용한다.
4. public key, password 등 협상된 방식으로 user를 인증한다.
5. 하나의 secure connection에서 shell, command, forwarding channel을 다룬다.

SSH를 사용한다고 자동으로 안전한 것은 아니다. host key verification을 끄거나 private key를 노출하고 오래된 algorithm을 강제로 허용하면 중요한 방어가 사라진다.

가장 먼저 확인할 것은 host key다

SSH의 첫 연결에서 보이는 host-key fingerprint는 단순 경고창이 아니다. 지금 연결한 server가 기대한 server인지 확인하는 정보다.

운영 환경에서는 fingerprint를 다음과 같이 별도 신뢰 경로로 배포한다.

• configuration management로 known_hosts 사전 배포
• asset inventory나 보안 포털에 fingerprint 게시
• console·관리 채널에서 server fingerprint 교차 확인
• host key rotation 절차와 변경 이력 관리

ssh-keyscan 결과를 바로 신뢰하면 안 된다. network에서 받은 key를 같은 network 결과만 보고 승인하면 on-path attacker를 구분하지 못한다. ssh-keyscan은 key 수집 도구이지 identity 검증 도구가 아니다.

known_hosts가 이미 안전하게 배포됐다는 전제에서 다음처럼 strict verification과 명시한 identity만 사용할 수 있다.

ssh \
  -o StrictHostKeyChecking=yes \
  -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519 \
  ops@example.com

StrictHostKeyChecking=yes이면 unknown 또는 변경된 host key를 자동 승인하지 않는다. IdentitiesOnly=yes는 agent가 제공하는 여러 key 대신 명시한 identity 범위로 시도를 제한한다.

private key file의 경로를 지정했다고 passphrase와 file permission 관리가 끝나는 것은 아니다. 가능하면 hardware-backed key나 조직의 short-lived certificate, 중앙 접근 통제와 audit을 함께 검토한다.

Python SSH code에서도 자동 승인을 피한다

Paramiko 예제에서 자주 보이는 AutoAddPolicy()는 처음 본 host key를 검증 없이 known-host set에 추가한다. test가 편해 보여도 MITM 방어를 약화한다.

known_hosts가 사전 배포된 환경에서는 unknown key를 거부하는 쪽이 안전하다.

from pathlib import Path

import paramiko

client = paramiko.SSHClient()
client.load_system_host_keys()
client.set_missing_host_key_policy(paramiko.RejectPolicy())

client.connect(
    hostname="example.com",
    username="ops",
    key_filename=str(Path.home() / ".ssh" / "id_ed25519"),
    look_for_keys=False,
    allow_agent=False,
)

stdin, stdout, stderr = client.exec_command("uname -a")
print(stdout.read().decode("utf-8"))
client.close()

code에 password나 private-key passphrase를 문자열로 넣지 않는다. automation이라면 secret manager, short-lived credential과 실행 주체의 최소 권한을 설계한다. 명령도 사용자 입력을 그대로 이어 붙이지 말고 allowlist와 parameter validation을 둔다.

port 확인에 Telnet을 쓰지 않아도 된다

Telnet client를 “TCP port가 열렸는지 보는 도구”로만 쓰는 경우가 있다. protocol에 맞는 도구를 쓰면 더 정확한 결과를 얻는다.

TCP 연결 가능 여부

nc -vz example.com 22

연결 성공은 해당 service가 정상 동작하거나 인증이 안전하다는 뜻이 아니다. TCP handshake가 가능하다는 1차 증거다.

TLS handshake와 certificate

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  </dev/null

HTTP request

curl -v https://example.com/health

application protocol을 이해하는 tool을 쓰면 DNS, TCP, TLS, HTTP 중 어디에서 실패했는지 더 잘 분리할 수 있다.

Telnet만 지원하는 legacy 장비가 남아 있다면

현실적으로 교체 전인 장비가 Telnet만 제공할 수 있다. 이 경우 Telnet을 안전하다고 부르는 대신 위험을 격리하고 종료 계획을 둔다.

1. 일반 user network와 분리된 management network에 둔다.
2. VPN·bastion·console server처럼 암호화된 진입점을 앞에 둔다.
3. source IP와 operator를 ACL로 최소화한다.
4. 재사용 password와 외부 계정 credential을 쓰지 않는다.
5. session recording과 network monitoring을 적용한다.
6. firmware update, SSH 지원 여부와 장비 교체 일정을 문서화한다.

이 조치는 Telnet 자체를 암호화하지 않는다. 노출 범위와 체류 시간을 줄이는 보상 통제다. protocol 학습은 localhost나 외부 network와 분리된 lab에서만 진행한다.

SSH 운영 checklist

• SSH protocol 1과 낡은 algorithm을 활성화하지 않았는가?
• host key를 out-of-band로 검증하고 rotation을 관리하는가?
• password login이 필요한 계정과 public-key·certificate 정책을 구분했는가?
• root direct login과 불필요한 port forwarding을 제한했는가?
• private key의 permission, passphrase와 폐기 절차가 있는가?
• bastion·session audit·command authorization이 필요한 환경인가?
• 실패 login과 host-key 변경을 monitoring하는가?
• emergency access도 만료·review되는가?

SSH와 Telnet의 차이는 encryption 유무 한 줄로 끝나지 않는다. SSH는 연결 대상 확인, user 인증, traffic 암호화와 무결성을 하나의 protocol architecture로 제공한다. Telnet에는 그 경계가 없으므로 운영 관리 접속의 선택지로 두지 않는 것이 맞다.

network troubleshooting command 정리에서는 DNS·TCP·TLS·application 계층을 나눠 확인하는 흐름을 볼 수 있다. SSH1과 SSH2 차이 및 보안 설정은 SSH 내부 version과 algorithm 정책으로 이어진다.

참고 자료

• RFC 854: Telnet Protocol Specification
• RFC 4251: SSH Protocol Architecture
• RFC 4252: SSH Authentication Protocol
• RFC 4253: SSH Transport Layer Protocol
• RFC 9142: SSH key-exchange 권고
• OpenBSD ssh_config manual
• Paramiko host keys documentation