☰

Known_hosts를 대체하기 위해 DNS에서 SSH 지문을 구성하지 못했습니다.

tag-icon • tag-icon ssh dns bind
Known_hosts를 대체하기 위해 DNS에서 SSH 지문을 구성하지 못했습니다.

SSHFP 레코드는 SSH 서버에서 다음과 같이 생성된 후 바인드의 영역에 추가됩니다.

$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9

필요한 레코드는 다음과 같이 DNS를 통해 SSH 클라이언트에서 얻을 수 있습니다.

$ dig www.test.us any
;; QUESTION SECTION:
;www.test.us.           IN  ANY

;; ANSWER SECTION:
www.test.us.        120 IN  SSHFP   1 1 AD04DFAF343A93BEEB939EED1612168F7EADBED7
www.test.us.        120 IN  SSHFP   2 1 432209C72C4F0E99546D601DD96C04CE804191F9
www.test.us.        120 IN  A   192.168.1.50

그러나 클라이언트의 SSH는 연결할 때 이를 찾을 수 없습니다.

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes www
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/test/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to www [192.168.1.50] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11
debug1: match: OpenSSH_5.8p2_hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c
DNS lookup error: name does not exist
The authenticity of host 'www (192.168.1.50)' can't be established.
RSA key fingerprint is 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

왜 이것이 실패하는지에 대한 아이디어가 있습니까? 보안을 유지하려면 DNSSEC가 필요하다는 것을 알고 있으며 현재 DNSSEC가 활성화되어 있지 않기 때문에 경고를 받아야 합니다. 먼저 DNSSEC 없이 이 작업을 수행한 다음 이 문제 해결을 시작하고 싶습니다.

SSH 서버는 OpenSSH_5.8p2_hpn13v11이 포함된 FreeBSD 9.1이며 BIND 9.8.3-P4를 사용하여 DNS를 호스팅합니다. OpenSSH_5.9p1을 사용하여 OS X 10.8.2에서 연결을 시도하고 OpenSSH_6.1p1을 사용하여 Arch Linux 3.6.10-1-ARCH에서 연결을 시도했습니다.

고쳐 쓰다

이 문제를 해결하기 위해 SSH 서버로 OpenSSH_6.1이 내장된 새 OpenBSD 5.2 VM을 설정했습니다. OpenSSH 서버의 다른 모든 구현은 OpenBSD 서버의 포트일 뿐이므로 이는 확실히 작동합니다. 서버에서 SSHFP 레코드를 생성합니다.

# ssh-keygen -r vm1.test.us.  
vm1.test.us. IN SSHFP 1 1 419c5338920e11183380d81f002fc998389b944f
vm1.test.us. IN SSHFP 1 2 cb5bbbf5aef231f57a1a4dcf1e790f1be032b124d0d591023f33cfd5f91ec556
vm1.test.us. IN SSHFP 2 1 0fdf92ce946b5cfee5f96a3e1ef710edc50280ff
vm1.test.us. IN SSHFP 2 2 f2ee7334ee9f9a426f51f20af8f4bc7155d567c9d38a6bffaa6c643af405711e
vm1.test.us. IN SSHFP 3 1 b5e94320f0bc0b46cc6627ca7221679a65c79962
vm1.test.us. IN SSHFP 3 2 60704213a0bbd8dae813d113bfe4ae190a780b89836e6e1c567b7cfde89805f8

FreeBSD 바인딩 서버에 추가하고 이름을 다시 로드했습니다. 그런 다음 레코드에 액세스할 수 있는지 테스트합니다.

$ host -t any vm1
vm1.test.us has SSHFP record 1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us has SSHFP record 1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us has SSHFP record 2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us has SSHFP record 2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us has SSHFP record 3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us has SSHFP record 3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us has address 192.168.1.60


$ dig -t any vm1.test.us
;; QUESTION SECTION:
;vm1.test.us.           IN  ANY

;; ANSWER SECTION:
vm1.test.us.        120 IN  SSHFP   1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us.        120 IN  SSHFP   2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us.        120 IN  SSHFP   2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us.        120 IN  SSHFP   3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us.        120 IN  SSHFP   3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us.        120 IN  SSHFP   1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us.        120 IN  A   192.168.1.60

레코드는 분명히 DNS를 통해 제공되므로 ssh를 사용해 보았습니다.

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes root@vm1
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to vm1 [192.168.1.60] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f
DNS lookup error: name does not exist
The authenticity of host 'vm1 (192.168.1.60)' can't be established.
RSA key fingerprint is d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

이 시점에서는 실패 지점인 SSH 클라이언트와 서버를 제거하는 것이 안전하다고 생각합니다. 대신 DNS 서버에 중점을 두겠습니다. 누군가가 어디를 봐야 할지 제안하지 않는 한, 패킷을 캡처하여 단서를 찾기만 하면 될 것 같습니다.

업데이트 2

좋아요, 여기 패킷 캡처가 있습니다. SSH www가 표준을 충족하지 않습니다.

No matching host key fingerprint found in DNS.

패킷 캡처는 DNS가 조회 레코드를 반환할 수 없음을 보여줍니다.

mbp13.test.us   www.test.us DNS Standard query 0x1c5e  SSHFP www
www.test.us   mbp13.test.us DNS Standard query response 0x1c5e No such name

SSH www.test.us와 비교하면 메시지와 함께 실패합니다.

No matching host key fingerprint found in DNS.

그러나 패킷 캡처는 DNS가 실제로 레코드를 반환하고 있음을 보여줍니다.

mbp13.test.us   www.test.us DNS Standard query 0x0ebd  SSHFP www.test.us
www.test.us   mbp13.test.us DNS Standard query response 0x0ebd  SSHFP SSHFP`

우선, 오류 메시지는 두 경우 모두 동일하므로 약간 혼란스럽습니다. 레코드가 반환되지 않는 사례 1을 수정하기 위해 일부 레코드를 추가할 수 있지만 가장 큰 문제는 사례 2입니다. DNS가 작동 중이고 SSHFP 레코드가 SSH 클라이언트로 반환되고 있습니다. DNS 쿼리 응답 후에는 패킷이 전송되지 않으며 SSH 클라이언트는 일치하지 않는 지문 메시지를 즉시 표시합니다. 이는 테스트 중인 모든 SSH 클라이언트가 손상되었거나 DNS에 저장된 지문이 잘못되어 일치하지 않음을 의미합니다. 클라이언트 문제인 것 같습니다. DNS의 지문이 잘못된 이유는 무엇입니까? 지문은 이 문서의 시작 부분에 설명된 대로 내장 SSH 도구인 ssh-keygen에서 생성됩니다. 또한 지문이 상황에 따라 다른 형식으로 나타나는 것도 문제에 도움이 되지 않습니다. 동일한 형식으로 표시되면 DNS에 저장된 레코드가 연결된 SSH 서버에서 반환된 키 지문과 다르다는 것을 쉽게 알 수 있습니다.

DNS record format:      ad04dfaf343a93beeb939eed1612168f7eadbed7
ssh client mesg format: 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c

ssh-keygen -r의 지문 출력이 동일한 SSH 서버에서 반환된 공개 키와 일치하지 않는 이유에 대한 제안이 있는 사람이 있습니까?

업데이트 3

나에게는 마지막 선택이 하나 남았다. 주말 전에 누군가 나에게 올바른 방향을 알려주지 않는 한, 나는 완전한 OpenBSD 기반 가상 머신을 사용하여 토요일에 복제 환경을 만들 것입니다. OpenBSD는 OpenSSH를 소유하고 있으므로 이는 DNS를 통한 SSHFP가 작동하는 데 이상적입니다. OpenBSD OpenSSH 클라이언트를 제공하는 바인딩이 있는 OpenBSD OpenSSH 서버가 작동하지 않으면 SSHFP가 구현에서 손상된 것입니다. 콘텐츠를 OpenBSD 포럼으로 이동하고 버그 보고서를 제출할 수도 있습니다. 나는 여전히 내가 뭔가 분명한 것을 놓치고 있고 유용한 답변이 내 주말을 절약할 수 있기를 바라고 있습니다.

답변1

분명히 내 문제는 두 가지 다른 문제로 인해 발생합니다.

질문 1 SSHFP는 검색 경로 사용을 지원하지 않습니다. 따라서 /etc/resolv.conf에 "domain example.com"을 추가하면 일반 ssh가 이름을 myhost.example.com으로 올바르게 확인하므로 ssh myhost가 SSHFP와 작동할 것으로 예상할 수 있습니다. 분명히 OpenBSD 개발자들은 2년 전 패치가 출시된 이후 이 문제를 알고 있었지만 적용한 적은 없었습니다. 대신 ssh_config 핵을 사용하는 것이 권장되었지만 그것도 작동하지 않는 것 같습니다. 따라서 첫 번째 문제에 대한 해결책은 FQDN을 항상 SSHFP와 함께 사용해야 한다는 것입니다.

질문 #2 이전 문제를 해결하기 위해 FQDN을 사용하는 경우 OpenSSH 클라이언트의 현재 버전(예: OpenSSH_6.1)을 사용하면 모든 것이 잘 작동합니다. 내 FreeBSD 시스템의 OpenSSH_5.8p2 클라이언트는 새 OpenSSH_6.1 서버에 대한 SSHFP 레코드를 찾을 수 있지만 DNS에서 받은 지문과 서버에서 받은 지문을 일치시킬 수 없습니다. 내 OS X 10.8.2 시스템의 OpenSSH_5.9p1 클라이언트는 새 OpenSSH_6.1 서버에 대한 SSHFP 레코드를 검색할 수도 없습니다. 이는 FreeBSD 시스템에 존재하지 않았던 클라이언트 버전임에도 마찬가지입니다. 분명히 존재하지 않는 SSHFP 레코드와 OpenSSH 서버에서 반환된 지문을 일치시킬 수 없습니다. 마지막으로, FreeBSD 시스템의 ssh-keygen은 서버에서 반환된 지문과 일치하지 않기 때문에 MITM 공격에 대해 불평하는 OpenSSH_6.1 클라이언트에 따라 잘못된 SSHFP 레코드를 생성합니다. 해결책은 SSHFP가 제대로 작동하려면 현재 버전의 OpenSSH 클라이언트 및 서버를 실행해야 한다는 것 같습니다. 이전 버전의 클라이언트나 서버를 사용하면 문제가 발생할 수 있습니다.

마지막 생각들 SSHFP와 DNS를 사용하는 것은 혼합 OS 환경에서 사용하기에는 너무 최첨단이며 모든 것이 "작동"하기에는 너무 최첨단입니다. 왜냐하면 OpenBSD가 아닌 운영 체제는 OpenSSH 휴대용 버전을 포팅해야 하기 때문입니다. 포팅. 아마도 3~5년 안에 SSHFP는 다른 운영 체제로 포팅된 이전 버전도 안정적이고 최신 버전과 호환될 만큼 충분히 안정적일 것입니다.

답변2

SSH를 연결하는 서버의 호스트 이름은 SSHFP 레코드의 호스트 이름과 정확히 일치해야 합니다. 즉, 두 개의 호스트 이름을 동일한 IP 주소로 확인하는 것만으로는 충분하지 않습니다. 따라서 ssh wwwwww가 다음과 같이 SSH 구성에 포함되어 있지 않으면 SSHFP는 www.test.us에서 작동하지 않습니다.

Host www
    Hostname www.test.us

노력하다 ssh www.test.us.

답변3

DNS 레코드를 생성하려는 서비스의 공개 키 파일 이름을 제공해야 합니다. 그렇지 않으면 .ssh/*.pub의 개인 공개 키 파일을 기본 대체 파일로 사용합니다.

ssh-keygen -r vm1.test.us -f /etc/ssh/ssh_host_rsa_key.pub

관련 정보