SSH 인증·호스트 키와 연결 진단

01TCP 연결 뒤 전송 보안·서버 인증·사용자 인증이 이어진다

• SSHSSH 클라이언트는 먼저 서버의 TCP 포트에 연결하고 버전과 알고리즘을 협상한다.
• 키 교환·세션키 교환으로 세션에 사용할 암호화 자료를 만들고 서버의 host key 서명을 검증하여 접속 상대를 확인한다.
• 사용자 인증이후 그 보호된 전송 위에서 사용자 인증을 수행하고 성공하면 셸·명령·파일 전송 등의 채널을 요청한다.

  • TCP 연결 성공이 곧 사용자 로그인 성공이라는 뜻은 아니다.
• 세션·개인키host key는 서버를 식별하는 장기 키이고 세션 암호화 키와 사용자 개인키는 역할이 다르다.
• known_hosts클라이언트의 known_hosts는 이전에 신뢰한 서버 키를 기억하는 장소다.
• 경고경고가 나타났을 때 기록을 지워 메시지만 없애면 서버 재설치와 중간자 공격을 구분할 증거를 잃는다.

  • 신뢰 가능한 콘솔 등 별도 경로의 지문과 대조한 뒤 의도한 변경인지 판단한다.

02공개키 인증은 개인키를 전송하지 않고 소유를 증명한다

• 개인키·공개키의 위치사용자 개인키는 클라이언트에 두고 대응하는 공개키만 서버 계정의 authorized_keys에 등록한다.
• 세션·개인키클라이언트는 현재 세션에 결합된 인증 데이터에 개인키로 서명하고 서버는 허용된 공개키로 서명을 검증한다.
• 공개키공개키 파일을 갖고 있다는 사실만으로 서명을 만들 수 없으므로 공개키의 배포와 개인키의 보호가 다른 목적이다.
• authorized_keysauthorized_keys에는 매번 생성되는 서명이나 개인키를 저장하지 않는다.
• Passphrase의 보호 범위개인키 passphrase는 저장된 키 파일 보호에 관여한다.

  • 접속할 때 쓰는 계정 암호와 같은 것이 아니다.
• ssh-agentssh-agent는 잠금 해제된 키로 서명 작업을 대신할 수 있지만 agent forwarding은 원격 호스트에서 그 서명 기능을 사용할 경로를 열 수 있으므로 별도 신뢰 판단이 필요하다.
• 자동화 계정의 키자동화 계정의 키는 사람이 쓰는 관리자 키와 분리하여 허용 출발지·명령·권한·회수 범위를 줄일 수 있다.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 첫 줄: 사용자 공개키 지문, 둘째 줄: 서버 호스트키 지문
# 서로 다른 키이며 각 파일이 존재하는 해당 시스템에서 조회한다.

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

03계정 홈·권한·StrictModes가 키 선택에 미치는 영향

• sshdsshd는 대상 계정의 실제 홈과 설정된 AuthorizedKeysFile 경로에서 허용 키를 찾는다.
• 사용자 이름사용자 이름이 root라고 홈이 /home/root인 것은 아니므로 계정 데이터베이스를 기준으로 한다.
• StrictModes 검사.ssh 디렉터리와 authorized_keys가 다른 사용자에게 쉽게 수정될 수 있으면 공격자가 자기 키를 추가할 수 있어 StrictModes 같은 검사가 소유권·쓰기 권한을 살핀다.
• 키 파일의 모드·소유자보통 .ssh는 0700, authorized_keys는 0600처럼 보호하고 적절한 소유자를 둔다.

  • 상위 홈 경로와 SELinux 컨텍스트도 의미가 있다.
• Windows 관리자 키 경로Windows OpenSSH의 관리자 계정은 별도 administrators_authorized_keys와 ACL 정책을 사용할 수 있어 Linux 경로·chmod를 그대로 적용하지 않는다.
• 개인키서버에 사용자 개인키를 만들어 남긴 뒤 압축 배포하는 방식은 개인키의 복사본과 전달 경로를 늘리므로 클라이언트 생성과 공개키 등록으로 분리한다.

getent passwd learner
namei -l /home/learner/.ssh/authorized_keys
stat -c "%A %U:%G %n" /home/learner/.ssh /home/learner/.ssh/authorized_keys

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

04SSH 설정 파일과 실제 연결 조건

• PubkeyAuthenticationPort와 ListenAddress는 리스너, PubkeyAuthentication과 PasswordAuthentication은 인증 방식, AllowUsers·AllowGroups·Deny 계열은 계정 허용 범위와 관계된다.
• Include·Match 조건Include로 여러 파일을 읽을 수 있고 Match 블록은 사용자·출발지 같은 조건에서 다른 정책을 적용한다.

  • 파일 한 줄만 읽어서 최종 동작을 판단하기 어려운 이유다.
• sshd -Tsshd -t는 구문과 필요한 조건을 검사하고 sshd -T는 해석된 설정을 보여 준다.
• 연결별 적용 설정 조회-C로 연결 조건을 주면 해당 Match가 적용된 결과를 볼 수 있다.
• 사용자 키 선택클라이언트에서 IdentitiesOnly=yes와 -i를 지정하면 agent의 여러 키를 무작정 시도하는 대신 지정한 키로 범위를 좁힐 수 있다.
• ssh-keygen -Assh-keygen -A는 기본 위치에 없는 host key를 생성하는 동작이며 모든 사용자 키를 초기화하는 명령이 아니다.

sudo sshd -t
sudo sshd -T -C user=learner,host=client.example,addr=192.0.2.20
ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 learner@server.example

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

08인증 뒤 채널·원격 명령·포워딩이 만들어지는 과정

• SSH·세션하나의 SSH 전송 연결 위에는 셸 세션, 명령 실행, 파일 전송 또는 포트 전달 같은 논리 채널을 만들 수 있다.
• ssh server commandssh server command는 원격에서 지정 명령을 실행하고 표준 출력·오류와 종료 상태를 받아오는 형태다.
• PTY와 자동화대화형 터미널 할당 여부에 따라 화면 제어·프롬프트·출력 버퍼링이 달라질 수 있어 자동화는 명령 실행과 interactive shell을 구분한다.
• 포워딩로컬 포워딩은 클라이언트가 지정 포트에서 받은 연결을 SSH를 통해 서버 쪽 목적지로 연결한다. 원격 포워딩은 서버 쪽에 리스너를 만드는 반대 배치이고 각 방향의 bind 주소와 AllowTcpForwarding 같은 서버 정책이 노출 범위를 결정한다.
• SSHSSH의 암호화가 터널 끝의 별도 프로토콜에 무제한 권한을 주는 것은 아니다.
• 키 교환·사용자 인증연결·키 교환·host key·사용자 인증·채널 요청 중 어느 단계에서 실패했는지를 -vvv와 서버 로그로 나누어 읽는다.

09자동화와 최소 권한

• 자동화용 계정자동화용 계정은 필요한 대상과 명령에만 접근하도록 구성한다.
• 자동화 자격증명의 분리일반 관리 계정의 광범위한 권한과 비밀번호를 코드에 넣으면 하나의 파일 유출이 여러 시스템의 문제로 이어질 수 있다.
• timeout·결과 확인연결 시간 제한과 명령 결과 확인도 필요하다.
• SSHSSH 에이전트 전달이나 포트 전달은 유용하지만 추가 접근 경로를 만들 수 있다.
• 포워딩의 접근 경계필요한 기능만 사용하고 어느 시스템이 키를 이용한 인증이나 내부 서비스 연결을 요청할 수 있는지 이해해야 한다.

ssh -V

설치된 OpenSSH 클라이언트 버전을 조회한다. 원격 연결은 하지 않는다.

10서버를 확인한 뒤 사용자를 인증하기

• SSH클라이언트가 SSH 서버에 연결하면 프로토콜 협상과 키 교환 과정에서 서버의 호스트 키와 관련 증명을 확인한다.
• 호스트 키클라이언트는 신뢰된 호스트 키 정보와 일치하는지 판단하여 지금 연결한 서버가 기대한 대상인지 검증한다.
• 암호화된 연결암호화된 연결을 만들 수 있다는 사실과 올바른 서버에 연결했다는 사실은 다르다.
• 최초 호스트 키 신뢰처음 보는 키는 신뢰할 별도 경로로 지문을 확인하고, 기존 키가 바뀌었으면 서버 재설치·키 교체와 공격 가능성을 구분해야 한다.
• 공개키·개인 키사용자 공개키 인증에서는 클라이언트가 개인 키를 서버에 보내는 대신 해당 키를 사용할 수 있음을 서명 등으로 증명한다.
• 공개키서버는 그 사용자에게 허용된 공개키와 정책으로 이를 검증한다.
• authorized_keys일반적인 authorized_keys는 서버 계정에 허용할 공개키의 목록이고, known_hosts는 클라이언트가 서버 신원을 확인하기 위한 정보다.

  • 같은 공개키 형식을 볼 수 있어도 두 파일의 방향이 반대다.
• 세션인증 성공 뒤에도 계정·세션·명령 실행 제한에 따라 실제 셸이나 작업이 거부될 수 있다.

1. 연결·키 교환네트워크 연결 뒤 지원 방식과 세션 키 교환을 협상한다.
2. 서버 신원 증명서버 호스트 키와 관련 서명을 클라이언트가 확인한다.
3. 신뢰된 키와 대조기억한 호스트 키 또는 별도 신뢰 근거와 일치하는지 판단한다.
4. 사용자 서명 제시개인 키를 보내지 않고 사용자 키 사용 능력을 증명한다.
5. 허용 키 확인해당 계정의 공개키와 제한 정책에 따라 서명을 검증한다.
6. 인증 후 세션 처리인증 결과와 계정·세션 정책에 따라 요청한 작업을 시작한다.

11오류 메시지를 단계에 맞춰 해석하기

• 전송 연결 실패시간 초과나 연결 거절은 사용자 키를 검토하기 전에 주소·포트·경로·리스닝·방화벽을 확인할 단서다.
• 서버 신원 불일치호스트 키 불일치는 사용자 비밀번호 오류가 아니라 서버 신원 확인 단계의 문제다.
• 공개키공개키 인증 거부에서는 계정 이름, 제시한 키, 서버 허용 목록과 파일 소유권·권한, 정책을 확인한다.
• 클라이언트클라이언트가 여러 키를 제시하면 시도 제한 때문에 예상 키에 도달하기 전에 실패할 수도 있으므로 실제 제시 순서도 관찰할 수 있다.
• 대화형·자동화 환경자동화에서는 처음 연결한 호스트를 무조건 신뢰하는 정책을 기본으로 삼지 않는다.
• 자동화의 접속 신뢰검증된 호스트 키 저장소, 비밀 공급 경로, 계정 권한과 접속 대상을 관리한다.
• 접속 후 명령 대기연결은 됐지만 명령이 멈춘 경우에는 비대화형 환경·권한 상승 입력·출력 버퍼·시간 제한을 구분한다.
• 디버그 로그디버그 로그를 공유할 때 사용자 이름과 경로 등 운영 정보를 정리한다.
• 개인 키에이전트 전달은 개인 키 파일을 복사하지 않더라도 원격 쪽에서 인증 동작을 요청할 능력을 줄 수 있으므로 별도의 신뢰 판단이 필요하다.