Rekordy SSHFP zostały wygenerowane na serwerze ssh w następujący sposób, a następnie dodane do strefy w powiązaniu:
$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9
Wymagane rekordy można pobrać z klienta ssh przez DNS, jak pokazano:
$ 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
Jednak ssh na kliencie nie może ich znaleźć podczas łączenia:
$ 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)?
Wszelkie pomysły, dlaczego to się nie udaje? Wiem, że DNSSEC jest wymagany, aby był bezpieczny i że powinienem otrzymać ostrzeżenie, ponieważ DNSSEC nie jest obecnie włączony. Mam nadzieję, że zacznę działać bez DNSSEC, zanim zacznę rozwiązywać ten problem jako dodatkowy problem.
Serwer ssh to FreeBSD 9.1 z OpenSSH_5.8p2_hpn13v11 i hostuje również DNS przy użyciu BIND 9.8.3-P4. Próbowałem połączyć się z OS X 10.8.2 z OpenSSH_5.9p1, a także Arch Linux 3.6.10-1-ARCH z OpenSSH_6.1p1.
Aktualizacja
W kolejnej próbie rozwiązania tego problemu stworzyłem nową maszynę wirtualną OpenBSD 5.2 z wbudowanym OpenSSH_6.1 jako serwer ssh. Ponieważ wszystkie inne implementacje serwera OpenSSH są tylko portami OpenBSD, na pewno powinno to działać. Na serwerze generuję rekordy 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
Dodaję je do serwera powiązań FreeBSD i ładuję ponownie o nazwie. Następnie sprawdź, czy mogę uzyskać dostęp do rekordów:
$ 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
Rekordy są wyraźnie obsługiwane przez DNS, więc próbuję użyć 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)?
W tym momencie myślę, że można bezpiecznie wyeliminować klientów i serwery ssh jako punkt awarii. Zamiast tego skupię się na serwerze DNS. Chyba, że ktoś ma sugestię, gdzie szukać, chyba utknąłem przy przechwytywaniu pakietów i kopaniu ich w poszukiwaniu wskazówek.
Aktualizacja 2
Okej, oto wyniki moich przechwyceń pakietów. ssh www; zawodzi ze standardem
No matching host key fingerprint found in DNS.
a przechwytywanie pakietów pokazuje, że DNS nie zwraca rekordu dla wyszukiwania.
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
Porównaj z ssh www.test.us; co również kończy się niepowodzeniem z komunikatem
No matching host key fingerprint found in DNS.
jednak przechwytywanie pakietów pokazuje, że DNS faktycznie zwraca rekord.
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`
Po pierwsze, trochę niepokojące jest to, że komunikat o błędzie jest taki sam w obu przypadkach. Mogę dodać niektóre rekordy, aby naprawić przypadek 1, w którym nie są zwracane żadne rekordy, ale dużym problemem jest przypadek 2. DNS działa, a rekordy SSHFP są zwracane do klienta ssh. Żadne pakiety nie są wysyłane po odpowiedzi na zapytanie DNS, a klient ssh natychmiast wyświetla niepasujący komunikat o odcisku palca. Oznacza to, że albo wszyscy klienci ssh, z którymi testuję, są uszkodzeni lub odcisk palca przechowywany w DNS jest niepoprawny i nie pasuje. Wątpię, czy to klienci, więc dlaczego odcisk palca w DNS jest nieprawidłowy? Odciski palców zostały wygenerowane z wbudowanych narzędzi ssh-keygen ssh, jak opisano na samym początku tego postu. Problemowi nie pomaga również fakt, że odciski palców są wyświetlane w różnych formatach w zależności od kontekstu.
DNS record format: ad04dfaf343a93beeb939eed1612168f7eadbed7
ssh client mesg format: 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c
Czy ktoś ma jakieś sugestie, dlaczego odciski palców z ssh-keygen -r nie pasują do kluczy publicznych zwróconych przez ten sam serwer ssh?
Aktualizacja 3
Jestem na ostatniej opcji. O ile ktoś nie wskaże mi właściwego kierunku przed weekendem, spędzę sobotę na tworzeniu zduplikowanego środowiska przy użyciu maszyn wirtualnych całkowicie opartych na OpenBSD. Ponieważ OpenBSD jest właścicielem OpenSSH, muszą to być idealne warunki do działania SSHFP przez DNS. Jeśli serwer OpenBSD OpenSSH z powiązaniem obsługujący klienta OpenBSD OpenSSH nie działa, wówczas SSHFP jest uszkodzony jako zaimplementowany i przeniosę rzeczy na fora OpenBSD i ewentualnie zgłoś błąd. Nadal mam nadzieję, że brakuje mi czegoś oczywistego i że pomocna odpowiedź uratuje mi weekend.
www.test.us?sshjest zdezorientowany przez rekordy DNS niepasujące do nazwy hosta, do której próbujesz się dostać.Odpowiedzi:
Najwyraźniej moje problemy były spowodowane dwoma różnymi problemami.
Problem nr 1 SSHFP nie obsługuje korzystania ze ścieżek wyszukiwania. Więc jeśli dodasz „domain example.com” do /etc/resolv.conf, możesz oczekiwać, że ssh myhost będzie współpracował z SSHFP, ponieważ zwykłe ssh poprawnie rozwiąże nazwę na myhost.example.com. Najwyraźniej deweloperzy OpenBSD zdają sobie sprawę z tego problemu, ponieważ łatka została wydana 2 lata temu, ale nigdy nie została zastosowana. Zamiast tego zasugerowano włamanie ssh_config, ale to też nie działa. Rozwiązaniem pierwszego problemu jest to, że nazwa FQDN musi zawsze być używana z SSHFP.
Problem nr 2 Używając nazw FQDN do rozwiązania poprzedniego problemu, wszystko działa, jeśli użyję bieżącej wersji klienta OpenSSH, czyli OpenSSH_6.1. Klient OpenSSH_5.8p2 w moim systemie FreeBSD jest w stanie znaleźć rekordy SSHFP dla nowego serwera OpenSSH_6.1, ale nie jest w stanie dopasować odcisku palca otrzymanego z DNS z tym, który otrzymuje z serwera. Klient OpenSSH_5.9p1 na moim komputerze z systemem OS X 10.8.2 nie jest w stanie nawet pobrać rekordów SSHFP dla nowego serwera OpenSSH_6.1, mimo że nigdy nie jest wersją klienta niż maszyna FreeBSD. Oczywiście nie jest w stanie dopasować nieistniejących rekordów SSHFP do odcisku palca zwróconego przez serwer OpenSSH. Wreszcie, ssh-keygen na FreeBSD produkuje złe rekordy SSHFP według klientów OpenSSH_6.1, którzy narzekają na atak MITM, ponieważ nie „ t pasuje do odcisku palca zwróconego przez serwer. Wydaje się, że rozwiązaniem jest uruchomienie bieżącej wersji klienta i serwera OpenSSH, aby SSHFP działał. Korzystanie ze starszej wersji klienta lub serwera wymaga problemów.
Ostatnie przemyślenia Używanie SSHFP z DNS jest najwyraźniej zbyt nowatorskie, aby można je było stosować w mieszanym środowisku systemu operacyjnego i wszystko „po prostu działa”, ponieważ systemy operacyjne inne niż OpenBSD muszą przenosić przenośny OpenSSH, który jest nieaktualny do czasu jego przeniesienia. Być może za 3-5 lat SSHFP będzie wystarczająco stabilny, aby nawet starsze wersje, które są przeniesione do innych systemów operacyjnych, były również stabilne i kompatybilne z najnowszą wersją.
źródło
Nazwa hosta serwera SSH, z którym się łączy, musi dokładnie odpowiadać nazwie hosta w rekordzie SSHFP. Oznacza to, że rozpoznawanie dwóch nazw hostów na tym samym adresie IP jest niewystarczające. Dlatego
ssh wwwnie będzie działać dla SSHFP, które są dla www.test.us., chyba że www jest w konfiguracji SSH w następujący sposób:Spróbować
ssh www.test.us.źródło
Musisz podać nazwę pliku klucza publicznego usługi, dla której tworzysz rekordy DNS. W przeciwnym razie użyje twoich osobistych plików kluczy publicznych z .ssh / *. Pub jako domyślnej rezerwowej.
źródło