SSH1과 SSH2 차이: 현대 OpenSSH에서 확인할 보안 기준

SSH1과 SSH2는 같은 protocol의 설정 단계가 아니라 서로 호환되지 않는 두 protocol version이다. SSH1은 역사적으로 telnet·rlogin보다 안전한 remote access를 제공했지만 protocol 설계의 한계와 알려진 공격 때문에 현재 사용 대상이 아니다. 현대 OpenSSH를 운영한다면 “SSH2로 migration”보다 지원 중인 software와 SSH protocol 2의 실제 설정을 어떻게 검증할지가 핵심이다.

SSH2는 무엇이 달라졌나

SSH protocol 2 architecture는 세 층을 분리한다.

층	역할
Transport layer	server host authentication, key exchange, encryption, integrity
User authentication	client user가 누구인지 server에 인증
Connection protocol	하나의 encrypted connection 안에서 shell·exec·port forwarding channel을 multiplexing

이 구분 덕분에 algorithm negotiation, user authentication, logical channel을 독립된 protocol로 발전시킬 수 있다. “SSH2는 AES와 SHA-2를 써서 SSH1보다 강하다” 정도로만 비교하면 host key 검증과 인증 policy, forwarding 같은 더 중요한 경계를 놓친다.

SSH1의 문제를 특정 cipher 하나로 해결할 수도 없다. protocol 1과 2는 packet format과 key exchange, integrity 설계가 다르다. 오래된 장비가 SSH1만 지원한다면 production server의 보안 수준을 낮추기보다 isolated management network와 교체 계획을 세우는 편이 맞다.

현재 Client가 무엇을 지원하는지 확인하기

먼저 installed OpenSSH version과 지원 algorithm을 조회한다.

ssh -V
ssh -Q kex
ssh -Q cipher
ssh -Q mac
ssh -Q key

ssh -Q 목록은 client binary가 구현한 algorithm이다. 특정 host에 실제로 적용될 effective configuration은 별도로 본다.

ssh -G example.com | grep -E '^(hostname|port|user|ciphers|macs|kexalgorithms|hostkeyalgorithms) '

지원 목록에 있다는 사실이 negotiation 결과나 권장 여부를 뜻하지 않는다. 실제 connection은 client와 server의 공통 목록에서 우선순위에 따라 정해진다. 장애 분석이 필요할 때만 ssh -vv로 negotiation을 확인하고, log에 username·hostname·path 등 민감 정보가 들어갈 수 있음을 고려한다.

SSH1을 끄는 설정을 새로 추가해야 하나

과거 OpenSSH에는 Protocol 2 같은 설정이 있었지만 현재 release에서는 protocol 1 support 자체가 제거됐다. 최신 OpenSSH에 obsolete directive를 추가하는 방식보다 다음을 확인한다.

• package와 OS가 support 중인지
• server banner와 client debug log가 protocol 2 negotiation을 보이는지
• configuration에 제거된 option이 남아 start를 방해하지 않는지
• network appliance나 legacy client가 별도 SSH implementation을 쓰는지

server의 effective setting은 권한이 있는 환경에서 sshd -T로 확인할 수 있고, 변경한 config는 reload 전에 sshd -t로 syntax와 key file을 검사한다. OS마다 config include와 service control 방식이 다르므로 command를 복사해 즉시 reload하지 않는다.

공개 키 인증을 안전하게 전환하는 순서

key-based authentication은 private key를 client에 유지하면서 server가 signature를 검증한다. 새 key를 만들 때는 용도별 filename을 분리한다.

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_work

Ed25519 지원이나 compliance requirement가 맞지 않는 환경에서는 조직 crypto policy와 current OpenSSH documentation에 맞는 algorithm을 고른다. RSA라고 모두 같은 것도 아니다. RSA key size, signature algorithm, server·client version을 함께 봐야 한다.

전환 순서는 lockout을 피하도록 잡는다.

1. 새 key pair를 만들고 private key의 permission과 backup 범위를 정한다.
2. public key만 target account의 authorized_keys에 등록한다.
3. 기존 session을 닫지 않은 채 별도 terminal에서 public key login을 검증한다.
4. emergency access와 console path를 확인한다.
5. sshd -t와 effective config를 확인한다.
6. 필요한 account부터 password authentication을 단계적으로 줄인다.
7. 실패·성공 login log와 alert를 확인한다.

private key를 server, chat, ticket에 붙이지 않는다. passphrase와 hardware-backed FIDO authenticator는 key 탈취 위험을 더 줄일 수 있다.

Host Key 확인을 건너뛰지 않기

SSH transport가 암호화돼도 client가 잘못된 server의 host key를 받아들이면 man-in-the-middle 공격을 막을 수 없다. 첫 연결의 fingerprint는 server console이나 관리 plane처럼 별도 trusted channel에서 확인한다.

StrictHostKeyChecking=no와 /dev/null known-hosts 조합을 automation의 만능 해결책으로 쓰지 않는다. 새 host를 자동 등록해야 한다면 trust bootstrap, host certificate, DNS SSHFP와 DNSSEC, configuration management 중 환경에 맞는 방법을 설계한다.

host key가 바뀌었다는 warning이 나오면 단순히 기존 entry를 지우기 전에 다음을 확인한다.

• server rebuild나 host key rotation이 예정된 변경인가
• 접속한 IP·DNS·jump host가 맞는가
• 같은 address를 여러 host가 공유하는가
• network interception 징후가 없는가

Server 설정은 한 줄보다 조합이 중요하다

다음은 바로 적용할 완성 config가 아니라 review할 핵심 항목 예시다.

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy

PasswordAuthentication no는 public key login과 emergency path를 확인한 뒤 적용해야 한다. MFA를 PAM keyboard-interactive로 구성한다면 KbdInteractiveAuthentication과 AuthenticationMethods 조합이 필요할 수 있어 무조건 끄면 안 된다.

추가로 본다.

• AllowUsers, AllowGroups, Match block의 실제 scope
• agent·TCP·X11 forwarding이 정말 필요한 account인지
• PermitOpen, DisableForwarding, restricted authorized_keys option
• idle session과 connection rate 제한
• root login과 shared account 제거
• key rotation, revocation, offboarding 절차
• bastion과 private network의 책임 경계

IP allowlist는 attack surface를 줄이지만 stolen key와 trusted network 내부 공격까지 해결하지 않는다. public key, MFA, least privilege, log monitoring을 함께 본다.

network 접속 자체가 실패할 때는 Network Troubleshooting 명령어 흐름, SSH가 의존하는 TCP connection은 TCP·UDP와 Socket State에서 이어서 확인할 수 있다.

자주 묻는 질문

SSH2면 무조건 안전한가

아니다. obsolete software, 약한 algorithm 허용, host key 미검증, stolen private key, 과도한 forwarding·권한이 있으면 SSH2 위에서도 침해될 수 있다.

RSA key는 전부 폐기해야 하나

key type 이름만으로 결정하지 않는다. key size와 signature algorithm, OpenSSH version, compliance policy를 함께 본다. 새 환경에서는 current default와 organization policy를 우선한다.

Port를 22에서 바꾸면 보안이 크게 좋아지나

무작위 scan noise는 줄 수 있지만 authentication과 authorization control을 대신하지 않는다. 방화벽·private access·key·MFA·monitoring이 우선이다.

참고 자료

• RFC 4251: The Secure Shell Protocol Architecture
• OpenSSH ssh manual
• OpenSSH ssh_config manual
• OpenSSH sshd_config manual
• OpenSSH ssh-keygen manual