Próbuję uzyskać dostęp ssh do mojego routera. Obecnie mam tylko dostęp przez telnet i zainstalowałem dropbear i działa (używając opkg na napędzie USB podłączonym do routera).
Od samego początku wygenerowałem klucz prywatny i odszyfrowałem go (ponieważ dropbear jeszcze tego nie obsługuje) i publicznego:
cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys Przesłałem klucz publiczny (authorized_keys ) do /root/.ssh. Umieściłem plik na serwerze Apache (na moim komputerze lokalnym) i pobrałem go na router za pomocą wget (aby pobrany plik otrzymał root jako właściciel / grupa), a następnie zmieniłem uprawnienia na 0600 (to samo dla klienta, ale z moim użytkownikiem ).
Kiedy próbuję uzyskać dostęp, pojawia się błąd „Odmowa dostępu (publickey)”:
$ ssh -v -i ~/.ssh/id_rsa [email protected] OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version 2.0, remote software version dropbear debug1: no match: dropbear debug1: Authenticating to 192.168.1.1:22 as "root" debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o debug1: Host "192.168.1.1" is known and matches the RSA host key. debug1: Found key in /home/chazy/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/chazy/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey). Chyba że ja ” m błędnie odczytałem treść dokumentacji ( repozytorium GitHub ):
Autoryzacja klucza publicznego serwera :
Możesz użyć ~ / .ssh / allowed_keys w taki sam sposób jak w OpenSSH, po prostu umieść wpisy kluczy w tym pliku. Powinny one mieć postać:
ssh- RSA AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = ktoś @ hostname
musisz upewnić się, że ~ / .ssh, a plik klucza, są zapisu tylko przez użytkownika. Strzeż redaktorów który podzielił klucz w wielu wierszach.
Dropbear obsługuje niektóre opcje wpisów allowed_keys, zobacz stronę podręcznika.
Zrobiłem wszystko, co mówi, więc nie wiem, gdzie może być problem.
Dokumentacja wspomina o innym sposobie:
Uwierzytelnianie klucza publicznego klienta:
Dropbear może wykonywać uwierzytelnianie klucza publicznego jako klient, ale będziesz musiał przekonwertować klucze w stylu OpenSSH na format Dropbear lub użyć dropbearkey, aby je utworzyć.
Jeśli masz klucz prywatny w stylu OpenSSH ~ / .ssh / id_rsa, musisz to zrobić:
dropbearconvert openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db
Dropbear nie obsługuje zaszyfrowanych kluczy hosta, chociaż może łączyć się z ssh-agent.
Więc to oznacza, że jeśli przekonwertuję klucz prywatny na dropbear klucz prywatny, mogę użyć klienta dropbear do połączenia się z serwerem dropbear:
dropbearconvert openssh dropbear id_rsa id_rsa.db Zamierzam spróbować i zobaczyć, czy to działa. Tak czy inaczej, uwierzytelnianie klucza publicznego serwera powinno działać.
Komentarze
Odpowiedź
Krótka odpowiedź: Prawdopodobnie korzystasz z OpenWrt i musisz umieścić Twój klucz publiczny w /etc/dropbear/authorized_keys zamiast /root/.ssh/authorized_keys.
Długa odpowiedź:
GitHub repozytorium, na które wskazałeś, jest utrzymywane przez autora dropbear; mówi, że ~/.ssh/authorized_keys działa i według GitHub działa od co najmniej 14 lat. Patrząc na kod w svr-authpubkey.c dodaje /.ssh/authorized_keys do „pw_dir”.
Ja jednak , miał ten sam problem co ty i odkryłem, że plik binarny dostarczony w OpenWrt 18.06.1 faktycznie otwiera /etc/dropbear/authorized_keys. U mnie działa ten plik .
To zachowanie jest udokumentowane w dokumentach OpenWrt .
Więc jak to się stało?
Biorąc pod uwagę, że powyższy kod nie może samodzielnie utworzyć tej nazwy pliku (brakuje elementu .ssh) i nigdzie nie ma linku symbolicznego .ssh, uruchomiłem strings na pliku binarnym. To pokazało, że /etc/dropbear/authorized_keys jest wyraźnie wymienione tuż przed %s/.ssh/authorized_keys, którego można się spodziewać po kodzie GitHub. Dochodzę do wniosku, że plik binarny OpenWrt nie jest skompilowany z tych samych źródeł … i rzeczywiście, OpenWrt poprawia kod źródłowy za pomocą tej łatki . Zmienia plik używany do /etc/dropbear/authorized_keys wtedy (i tylko wtedy, gdy) docelowym użytkownikiem jest root.
Ponieważ wspominasz o opkg, wyobrażam sobie, że używasz również OpenWrt i to jest twój problem. Dodałem tag OpenWrt do Twojego pytania.
Odpowiedź
authorized_keys to plik, a nie katalog.
Przykładowy plik Authorized_keys:
# Comments allowed at start of line ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] http://man.he.net/man5/authorized_keys
Również .ssh/ a wszystkie znajdujące się w nim pliki muszą być własnością i mogą być odczytywane tylko przez użytkownika, w tym przypadku root.
Komentarze
- Właśnie to naprawiłem, ale nadal bez powodzenia 🙁 (zobacz zaktualizowane pytanie).
Odpowiedź
man dropbearkeys:
NOTES The program dropbearconvert(1) can be used to convert between Dropbear and OpenSSH key formats. Dropbear does not support encrypted keys. EXAMPLE generate a host-key: # dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key extract a public key suitable for authorized_keys from private key: # dropbearkey -y -f id_rsa | grep "^ssh-rsa " >> authorized_keys Komentarze
- Udało mi się przekonwertować klucz prywatny, ale nadal bez powodzenia 🙁 (patrz zaktualizowane pytanie).
Odpowiedź
Musisz utworzyć klucz ssh za pomocą narzędzia dropbearkey. RSA_KEYFILE = / etc / dropbear / dropbear_rsa_host_key DSS_KEYFILE = / etc / dropbear / dropbear_dss_host_key
dropbearkey -t dss -f $ DSS_KEYFILE
dropbearkey -t rsa -f $ RSA_KEYFILE
Następnie zrestartuj demona dropbear. Następnie spróbuj się połączyć, powinno działać.
Odpowiedź
Niektóre wskazówki, które mogą pomóc w uzyskaniu połączenia za pomocą PKI z Dropbear, przetestowały kontener oparty na pakietach Alpine Linux 3.12, łączący się z klienta OpenSSH.
- Użytkownik potrzebuje powłoki.
- Użytkownik nie potrzebuje potrzebne jest hasło logowania.
- Użytkownik „s
~nie może umożliwia zapis grupowy / światowy (tj przynajmniejchmod 755; powinieneś używać700dla katalogów domowych). - Użytkownik „s
~/.sshi musi być dostępny tylko dla właściciela (np.700w katalogu i600w pliku). - Tam musi być zapisywalnym
/tmpkatalogiem - Wpisy
authorized_keysmają taki sam format jak używany przez OpenSSH.
Tworzę kontenery przy użyciu wybranych plików z pakietów alpine; Mam obraz o rozmiarze ~ 2 MB, do którego mogę przesłać ssh, o ile spełnione są wszystkie powyższe wymagania.
Odpowiedź
I właśnie natknąłem się na to pytanie, szukając powodów, dla których łączenie się przez dropbear z moim serwerem nagle przestało działać (działało od miesięcy, ale sporadycznie używane co kilka tygodni).
rozwiązanie / wyjaśnienie i w końcu znaleziono wiadomość debug1: send_pubkey_test: no mutual signature algorithm ze zwiększoną szczegółowością podczas próby połączenia SSH moich klientów, która doprowadziła mnie do artykułu dotyczącego rozwiązywania problemów z bitbucketem .
w artykule wspomniano jako przyczynę algorytm RSA jest szybko wycofywany z użycia w systemach operacyjnych i klientach SSH z powodu różnych luk w zabezpieczeniach […] i wymienia jako możliwe obejścia albo:
-
dodanie
PubkeyAcceptedKeyTypes +ssh-rsado pliku cfg-klienta (używaj go tylko jako tymczasowe obejście , ponieważ jest pote opcjonalnie niezabezpieczone!) -
użyj algorytmu / kluczy ECDSA lub ED25519. teraz z wersją dropbear obecną w moim systemie mogę tylko używać ECDSA, ponieważ ED25519 dał mi nieznany algorytm błędy po stronie dropbears.
Mam nadzieję, że to pomoże komuś natknąć się na to pytanie, tak jak ja to zrobiłem, chociaż prawdopodobnie nie jest to rozwiązanie pierwotnego pytania, proszę. wybacz.
opt/etc/dropbear(tylko klucze hosta), a parametrem uniemożliwiającym to jest -w (nie używam go).