Định cấu hình dấu vân tay ssh trên dns để thay thế đã biết

Các bản ghi SSHFP đã được tạo trên máy chủ ssh như sau và sau đó được thêm vào vùng trong liên kết:

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

Các bản ghi cần thiết có thể được lấy từ máy khách ssh qua DNS như được hiển thị:

$ 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

Tuy nhiên, ssh trên máy khách không tìm thấy chúng khi kết nối:

$ 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)?

Bất kỳ ý tưởng như tại sao điều này là thất bại? Tôi biết rằng DNSSEC là bắt buộc để đảm bảo an toàn và tôi sẽ nhận được cảnh báo vì DNSSEC hiện chưa được bật. Tôi hy vọng sẽ làm cho điều này hoạt động mà không có DNSSEC trước khi tôi bắt đầu giải quyết vấn đề đó như là một vấn đề bổ sung.

Máy chủ ssh là FreeBSD 9.1 với OpenSSH_5.8p2_hpn13v11 và cũng đang lưu trữ DNS bằng BIND 9.8.3-P4. Tôi đã thử kết nối từ OS X 10.8.2 với OpenSSH_5.9p1 cũng như Arch Linux 3.6.10-1-ARCH với OpenSSH_6.1p1.

Cập nhật

Trong một nỗ lực tiếp theo để khắc phục sự cố này, tôi đã đứng lên một máy ảo OpenBSD 5.2 mới có OpenSSH_6.1 được tích hợp trong nó như một máy chủ ssh. Vì tất cả các triển khai khác của máy chủ OpenSSH chỉ là các cổng của OpenBSD, nên chắc chắn điều này sẽ hoạt động. Trên máy chủ, tôi tạo các bản ghi 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

Tôi thêm chúng vào máy chủ liên kết FreeBSD và tải lại tên. Sau đó kiểm tra xem tôi có thể truy cập vào hồ sơ không:

$ 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

Các hồ sơ rõ ràng đang được phục vụ qua DNS, vì vậy tôi cố gắng sử dụng 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)? 

Tại thời điểm này, tôi nghĩ an toàn khi loại bỏ các máy khách và máy chủ ssh là điểm thất bại. Thay vào đó tôi sẽ tập trung máy chủ DNS. Trừ khi ai đó có gợi ý về nơi cần tìm, tôi đoán tôi bị mắc kẹt với việc chụp gói và đào qua chúng để tìm manh mối.

Cập nhật2

Được rồi, đây là kết quả chụp gói tin của tôi. ssh www; thất bại với tiêu chuẩn

No matching host key fingerprint found in DNS.

và việc chụp gói cho thấy DNS không trả về bản ghi cho việc tra cứu.

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

So sánh với ssh www.test.us; mà cũng thất bại với tin nhắn

No matching host key fingerprint found in DNS.

tuy nhiên việc chụp gói cho thấy DNS thực sự trả về bản ghi.

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`

Đầu tiên, có một chút bối rối rằng thông báo lỗi là giống nhau cho cả hai trường hợp. Tôi có thể thêm một số bản ghi để sửa trường hợp 1 trong đó không có bản ghi nào được trả về, nhưng vấn đề lớn là trường hợp 2. DNS hoạt động và các bản ghi SSHFP đang được trả về máy khách ssh. Không có gói nào được gửi sau phản hồi truy vấn DNS và máy khách ssh ngay lập tức hiển thị thông báo không có dấu vân tay phù hợp. Điều này có nghĩa là tất cả các máy khách ssh tôi đang kiểm tra bị hỏng hoặc dấu vân tay được lưu trữ trong DNS là sai và không khớp. Tôi nghi ngờ đó là khách hàng vậy tại sao dấu vân tay trong DNS lại sai? Dấu vân tay được tạo ra từ các công cụ ssh tích hợp ssh-keygen như được mô tả ở phần đầu của bài đăng này. Ngoài ra, vấn đề không được giúp đỡ bởi thực tế là dấu vân tay được hiển thị ở các định dạng khác nhau tùy thuộc vào ngữ cảnh.

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

Có ai có bất kỳ đề xuất nào về lý do tại sao đầu ra dấu vân tay từ ssh-keygen -r không khớp với các khóa công khai được trả về bởi cùng một máy chủ ssh không?

Cập nhật3

Tôi xuống lựa chọn cuối cùng của tôi. Trừ khi ai đó chỉ cho tôi đi đúng hướng trước cuối tuần, tôi sẽ dành thứ bảy của mình để tạo một môi trường trùng lặp bằng cách sử dụng VM hoàn toàn dựa trên OpenBSD. Vì OpenBSD sở hữu OpenSSH, đây sẽ phải là điều kiện lý tưởng để SSHFP qua DNS hoạt động. Nếu máy chủ OpenBSD OpenSSH có liên kết phục vụ máy khách OpenBSD OpenSSH không hoạt động, thì SSHFP bị hỏng khi được triển khai và tôi sẽ chuyển mọi thứ đến diễn đàn OpenBSD và có thể gửi báo cáo lỗi. Tôi vẫn hy vọng rằng tôi đang thiếu một cái gì đó rõ ràng và một câu trả lời hữu ích sẽ cứu được cuối tuần của tôi.

Rõ ràng vấn đề của tôi được gây ra bởi hai vấn đề khác nhau.

Vấn đề # 1 SSHFP không hỗ trợ sử dụng đường dẫn tìm kiếm. Vì vậy, nếu bạn thêm "domain example.com" vào /etc/resolv.conf thì bạn sẽ mong ssh myhost hoạt động với SSHFP vì ssh thông thường sẽ phân giải chính xác tên thành myhost.example.com. Rõ ràng các nhà phát triển OpenBSD nhận thức được vấn đề kể từ khi một bản vá được phát hành 2 năm trước nhưng nó không bao giờ được áp dụng. Thay vào đó, một hack ssh_config đã được đề xuất nhưng nó cũng không hoạt động. Vì vậy, giải pháp cho vấn đề đầu tiên là FQDN phải luôn được sử dụng với SSHFP.

Vấn đề 2 Sử dụng FQDN để giải quyết vấn đề trước đó, mọi thứ sẽ hoạt động nếu tôi sử dụng phiên bản hiện tại của ứng dụng khách OpenSSH là OpenSSH_6.1. Máy khách OpenSSH_5.8p2 trên hệ thống FreeBSD của tôi có thể tìm thấy các bản ghi SSHFP cho máy chủ OpenSSH_6.1 mới, nhưng nó không thể khớp với dấu vân tay mà nó nhận được từ DNS với máy chủ nhận được từ máy chủ. Máy khách OpenSSH_5.9p1 trên máy OS X 10.8.2 của tôi thậm chí không thể truy xuất các bản ghi SSHFP cho máy chủ OpenSSH_6.1 mới mặc dù là phiên bản máy khách không bao giờ so với máy FreeBSD. Rõ ràng là nó không thể khớp các bản ghi SSHFP không tồn tại với dấu vân tay được trả về bởi máy chủ OpenSSH. Cuối cùng, ssh-keygen trên hộp FreeBSD tạo ra các bản ghi SSHFP xấu theo các máy khách OpenSSH_6.1 phàn nàn về một cuộc tấn công MITM vì chúng không ' t khớp với dấu vân tay được trả về bởi máy chủ. Giải pháp có vẻ là bạn phải chạy phiên bản hiện tại của cả máy khách và máy chủ OpenSSH để SSHFP hoạt động. Sử dụng phiên bản cũ hơn của máy khách hoặc máy chủ sẽ yêu cầu sự cố.

Những suy nghĩ cuối cùng Sử dụng SSHFP với DNS dường như quá khó để sử dụng trong môi trường HĐH hỗn hợp và có mọi thứ "chỉ hoạt động" do các HĐH không phải OpenBSD phải chuyển sang OpenSSH đã hết hạn vào thời điểm nó được chuyển. Có lẽ trong 3-5 năm, SSHFP sẽ đủ ổn định để ngay cả các phiên bản cũ hơn được chuyển sang các HĐH khác cũng sẽ ổn định và tương thích với phiên bản mới nhất.

Tên máy chủ của SSH máy chủ đang kết nối phải khớp chính xác với tên máy chủ trong bản ghi SSHFP. Đó là, nó không đủ chỉ cho hai tên máy chủ để phân giải đến cùng một địa chỉ IP. Do đó, ssh wwwsẽ không hoạt động đối với SSHFP dành cho www.test.us., trừ khi www có trong cấu hình SSH của bạn như thế này:

Host www
    Hostname www.test.us

Hãy thử ssh www.test.us.

Bạn cần cung cấp tên tệp của khóa chung của dịch vụ bạn đang tạo bản ghi DNS cho. Nếu không, nó sẽ sử dụng (các) tệp khóa công khai cá nhân của bạn từ .ssh / *. Pub làm dự phòng mặc định.

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