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를 호스팅합니다. OS X 10.8.2에서 OpenSSH_5.9p1로, Linux Linux 3.6.10-1-ARCH에서 OpenSSH_6.1p1로 연결을 시도했습니다.

최신 정보

이 문제를 해결하기 위해 OpenSSH_6.1이 ssh 서버로 내장 된 새로운 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 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 기반의 VM을 사용하여 복제 환경을 만들게됩니다. OpenBSD는 OpenSSH를 소유하고 있기 때문에 DNS를 통한 SSHFP가 작동하려면 이상적인 조건이어야합니다. 바인드가 OpenBSD OpenSSH 클라이언트를 제공하는 OpenBSD OpenSSH 서버가 작동하지 않으면 SSHFP가 구현 된대로 깨져서 OpenBSD 포럼으로 이동하여 버그 보고서를 제출할 것입니다. 나는 여전히 분명한 것을 놓치고 있으며 유용한 답변이 주말을 절약 할 수 있기를 바라고 있습니다.

ssh dns bind

— 마이클 야스 모토
소스

명시 적으로 연결하기 위해 연결을 시도 했습니까 www.test.us?

— Ulrich Dangel

예. 죄송합니다. 모든 변형을 시도했다고 언급 했어야합니다. ssh www; ssh www.test.us; ssh www.test.us .; 그들 모두는 같은 반응을 낳습니다.

— Michael Yasumoto 4

Wireshark / tcpdump에서 DNS 서버에서 쿼리되는 내용과 전송되는 응답을 보는 것이 흥미로울 수 있습니다. 정확한 쿼리와 응답을 알면 문제를 찾는 데 도움이됩니다.

— Gert van den Berg

Gert, 나는이 의견 상자에 답변을 넣을 수 없기 때문에 위의 업데이트에 응답했습니다.

— Michael Yasumoto

IP 주소로 직접 연결해보십시오. 연결 ssh하려는 호스트 이름과 일치하지 않는 DNS 레코드로 인해 혼란스러워 보입니다 .

— peterph

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

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

문제 # 2 FQDN을 사용하여 이전 문제를 해결하면 OpenSSH_6.1 인 OpenSSH 클라이언트의 현재 버전을 사용하면 모든 것이 작동합니다. FreeBSD 시스템의 OpenSSH_5.8p2 클라이언트는 새로운 OpenSSH_6.1 서버에 대한 SSHFP 레코드를 찾을 수 있지만 DNS에서 수신 한 지문과 서버에서 수신 한 지문을 일치시킬 수 없습니다. 내 OS X 10.8.2 시스템의 OpenSSH_5.9p1 클라이언트는 FreeBSD 시스템보다 절대 클라이언트 버전이 아니더라도 새 OpenSSH_6.1 서버에 대한 SSHFP 레코드를 검색 할 수도 없습니다. 분명히 존재하지 않는 SSHFP 레코드를 OpenSSH 서버가 리턴 한 지문과 일치시킬 수 없습니다. 마지막으로 FreeBSD 상자의 ssh-keygen은 OpenSSH_6.1 클라이언트에 따라 잘못된 SSHFP 레코드를 생성합니다. OpenSSH_6.1 클라이언트는 MITM 공격에 대해 불평합니다. 서버가 반환 한 지문과 일치하지 않습니다. 해결책은 SSHFP가 작동하려면 OpenSSH 클라이언트와 서버 모두의 현재 버전을 실행해야한다는 것입니다. 클라이언트 또는 서버의 이전 버전을 사용하면 문제가 발생합니다.

최종 생각 DNS와 함께 SSHFP를 사용하는 것은 혼합 OS 환경에서 사용하기에는 너무나 최첨단이며, OpenBSD가 아닌 OS는 포팅 시점에 구식이 아닌 OpenSSH 포터블을 포팅해야하기 때문에 모든 것이 제대로 작동합니다. 3-5 년이 지나면 SSHFP는 다른 OS로 포팅 된 이전 버전조차도 안정적이며 최신 버전과 호환 될 수있을 정도로 안정적입니다.

— 마이클 야스 모토
소스

OS X (10.9)에 6.X 버전의 OpenSSH가 포함되어 있음에도 불구하고 SSHit은 여전히 GitHub에 의해보고 된 OS X 구현이 손상되어 작동하지 않습니다. MacPorts와 같은 다른 OpenSSH 클라이언트로 교체하는 것이 현재 유일한 솔루션입니다.

— Michael Yasumoto

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

Host www
    Hostname www.test.us

시도하십시오 ssh www.test.us.

— HTOIP
소스

죄송합니다. 위의 전체 게시물을 읽지 않은 것 같습니다. FQDN (정규화 된 도메인 이름)을 사용하여 테스트했지만 문제가되지 않았습니다.

— Michael Yasumoto

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

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

— 늑대
소스