POOOLING FOREST
SSH 키, 뺏겨도 안전할 수 있을까? 하드웨어 터치가 필요한 이유 - 단순히 SSH 키를 파일로 관리하는 것을 넘어, 하드웨어 보안 키를 활용한 '터치 인증'이 왜 현대 개발 환
Engineering & Tech

SSH 키, 뺏겨도 안전할 수 있을까? 하드웨어 터치가 필요한 이유

단순히 SSH 키를 파일로 관리하는 것을 넘어, 하드웨어 보안 키를 활용한 '터치 인증'이 왜 현대 개발 환경에서 필수적인 생존 도구가 되었는지 이야기해 봅니다.

김영태

테크리드

안녕하세요. 풀링포레스트 풀스택 개발자 김테크입니다.

서버에 접속하거나 깃허브(GitHub)에 코드를 푸시할 때마다 제 노트북 옆에 꽂힌 작은 USB 키가 반짝거립니다. 저는 습관처럼 손가락을 뻗어 그 키를 톡 건드립니다. 이 사소한 '터치' 한 번이 제 하루의 평화를 지켜준다는 사실을 알기 때문입니다. 오늘은 단순히 SSH 키를 파일로 관리하는 것을 넘어, 하드웨어 보안 키를 활용한 '터치 인증'이 왜 현대 개발 환경에서 필수적인 생존 도구가 되었는지 이야기해 보려 합니다.

솔직히 고백하자면, 저도 몇 년 전까지는 SSH 키 관리에 무심했습니다. ~/.ssh 폴더에 id_rsa 파일을 고이 모셔두고, 비밀번호(Passphrase)만 길게 설정하면 안전하다고 믿었으니까요. "나는 맥(Mac)이나 리눅스를 쓰니까 윈도우 기반 악성코드 따위는 남의 일이야"라는 안일한 생각도 한몫했습니다. 하지만 개발자 도구가 점점 복잡해지고 공급망 공격(Supply Chain Attack)이 정교해지면서 상황은 완전히 달라졌습니다.

어느 날 보안 관련 아티클을 읽다가 등골이 서늘해지는 경험을 했습니다. 우리가 흔히 쓰는 패키지 매니저나 무심코 실행한 스크립트를 통해 침투한 맬웨어는, 암호화된 SSH 키 파일 자체를 노리지 않을 수도 있습니다. 대신 메모리에 로드된 키를 가로채거나, 이미 열려 있는 SSH 에이전트 소켓을 이용해 제 권한을 도용할 수 있다는 내용이었죠. 즉, 내 컴퓨터가 뚫리면 내 서버 인프라 전체가 뚫리는 셈이었습니다. 아무리 키를 주기적으로 교체(Rotation)한다고 해도, 교체한 그 순간 다시 탈취당한다면 무슨 소용이 있을까요?

그때부터 저는 '하드웨어 터치' 기반의 인증을 도입했습니다. 핵심은 간단합니다. SSH 키를 생성할 때 FIDO2나 U2F 같은 하드웨어 보안 키(예: YubiKey 등)와 연동하는 것입니다. 기술적으로는 ed25519-sk 같은 키 타입을 사용하게 되는데, 여기서 -sk는 Security Key를 의미합니다.

이 방식의 가장 큰 장점은 '물리적 존재(User Presence)'를 요구한다는 점입니다.

해커가 제 노트북에 원격으로 접속해 맬웨어를 심었다고 가정해 봅시다. 해커가 제 SSH 키를 이용해 서버에 접속을 시도합니다. 하지만 접속은 거부됩니다. 왜냐고요? 제 노트북 옆에서 반짝이는 하드웨어 키를 물리적으로 터치해 줄 '제 손가락'이 해커에게는 없기 때문입니다.

물론 처음 도입할 때는 꽤 귀찮았습니다. ssh-keygen -t ed25519-sk 명령어로 키를 새로 발급받아야 했고, 서버 쪽의 OpenSSH 버전이 이를 지원하는지 확인도 필요했습니다. 무엇보다 매번 커밋을 푸시할 때마다 손을 뻗어야 한다는 게 번거롭게 느껴졌죠.

하지만 트러블슈팅 과정에서 배운 점이 더 많습니다. 한 번은 원격 근무 중 집에 하드웨어 키를 두고 카페에 나갔다가 아무 작업도 못 하고 돌아온 적이 있습니다. 그때 뼈저리게 느꼈습니다. "아, 이 키가 없으면 나조차도 내 인프라에 접근할 수 없구나. 그렇다면 공격자도 절대 못 들어오겠구나." 그 불편함이 역설적으로 가장 강력한 보안의 증거가 된 셈입니다.

실무에서 이를 적용하려면 몇 가지 고려할 점이 있습니다.

  1. 백업 키의 중요성: 하드웨어 키를 분실하면 대책이 없습니다. 반드시 두 개 이상의 하드웨어 키를 등록해두거나, 안전한 금고에 별도의 비상용 키를 보관해야 합니다.

  2. 호환성 확인: 레거시 장비나 오래된 OS를 사용하는 서버는 ed25519-sk 타입을 지원하지 않을 수 있습니다. 인프라 팀으로서 전체 서버의 OpenSSH 버전을 관리하는 것이 선행되어야 했습니다.

지금은 그 작은 깜박임이 저에게 "주인님, 지금 문을 열어도 될까요?"라고 묻는 신호처럼 느껴집니다. 그 신호에 응답해 터치하는 순간, 저는 제 코드가, 그리고 우리 회사의 인프라가 안전하다는 확신을 얻습니다.

개발자 여러분, ~/.ssh 폴더에 잠들어 있는 텍스트 파일만 믿고 계시진 않나요? 맬웨어는 날로 진화하고 있고, 개발자의 노트북은 가장 매력적인 공격 대상입니다. 이제는 물리적인 터치로 여러분의 의도를 증명해야 할 때입니다. 그 작은 습관 하나가 훗날 발생할지도 모를 거대한 재앙을 막아줄 테니까요.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.