octombrie 24, 2020
Articles
Niciun comentariu

serverul dropbear ssh a câștigat ' să nu mă conectez

Încerc să obțin acces ssh la routerul meu. În prezent am doar acces telnet și am instalat dropbear și rulează (folosind opkg pe o unitate USB conectată la router).

De la început, ceea ce am făcut a fost să generez o cheie privată și să o decriptez (din moment ce dropbear încă nu acceptă acest lucru) și cea publică: 

cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys

Am încărcat cheia publică (authorized_keys ) la /root/.ssh. Am pus fișierul pe un server Apache (în computerul meu local) și îl descarc pe router folosind wget (astfel fișierul descărcat devine rădăcină ca proprietar / grup) și apoi am schimbat permisiunile la 0600 (același pentru client, dar cu utilizatorul meu ).

Când încerc să accesez, îmi dă o eroare „Permisiune refuzată (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).

Cu excepția cazului în care eu ” citesc greșit ceea ce spune documentația ( GitHub repo ):

autentificarea cheii publice a serverului :

Puteți utiliza ~ / .ssh / awtorizat_keys în același mod ca și cu OpenSSH, pur și simplu introduceți intrările cheie în acel fișier. Acestea ar trebui să aibă forma:

ssh- rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = cineva @ nume de gazdă

trebuie să vă asigurați că ~ / .ssh, și fișierul cheie, sunt scrise doar de către utilizator. Feriți-vă de editori care împarte cheia în mai multe linii.

Dropbear acceptă unele opțiuni pentru intrările autorizate_chei, consultați pagina de manual.

Am făcut tot ceea ce spune, așa că am nu știți unde ar putea fi problema.

Documentația menționează un alt mod:

Autent cheie publică client:

Dropbear poate face autentificarea cheii publice ca client, dar va trebui să convertiți cheile de stil OpenSSH în format Dropbear sau să utilizați dropbearkey pentru a le crea.

Dacă aveți o cheie privată în stil OpenSSH ~ / .ssh / id_rsa, trebuie să faceți:

dropbearconvert openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db

Dropbear nu acceptă tastele gazdă criptate, deși se poate conecta la ssh-agent.

Deci, acest lucru menționează că, dacă convertesc cheia privată într-un dropbear cheie privată, pot folosi clientul dropbear pentru a mă conecta la serverul dropbear: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Voi încerca acest lucru și voi vedea dacă funcționează. Dar oricum, autentificarea cheii publice a serverului ar trebui să funcționeze.

Comentarii

  • Serverul / config-ul dropbear ssh permite autentificarea root? În mod implicit pe mai multe servere ssh, autentificarea root este interzisă pentru securitate.
  • Cred că da, nu ‘ nu văd niciun fișier de configurare în opt/etc/dropbear (numai tastele gazdă), iar parametrul pentru a-l interzice este -w (nu-l folosește).
  • Întrebare editată: a urmat pașii pentru a converti cheia ssh într-un dropbear cheie și nimic (așa cum sa menționat Ipor Sircer din primul răspuns).
  • S-a găsit documentația în repozitia github (‘ nu se poate raporta acolo, problemele nu sunt activate) . Întrebarea a fost editată din nou. Aceeași problemă încă 🙁

Răspuns

Răspuns scurt: probabil că rulați OpenWrt și trebuie să puneți cheia dvs. publică din /etc/dropbear/authorized_keys în loc de /root/.ssh/authorized_keys.

Răspuns lung:

GitHub repo-ul pe care îl indicați este cel menținut de autorul dropbear; se spune că ~/.ssh/authorized_keys funcționează și, conform GitHub, a făcut-o cel puțin de 14 ani. Privind codul din svr-authpubkey.c adaugă /.ssh/authorized_keys la „pw_dir”.

I, totuși , a avut aceeași problemă ca și dvs. și am descoperit că binarul furnizat în OpenWrt 18.06.1 se deschide de fapt /etc/dropbear/authorized_keys. Folosirea acestui fișier funcționează pentru mine .

Acest comportament este documentat în din documentele OpenWrt .

Deci, cum se face?

Având în vedere că codul de mai sus nu poate produce numele fișierului singur (lipsește .ssh) și nu există nicio .ssh link simbolic nicăieri, am rulat strings pe binar. Acest lucru a arătat că /etc/dropbear/authorized_keys este menționat în mod explicit, chiar înainte de %s/.ssh/authorized_keys care se poate aștepta din codul GitHub. Concluzionez că binarul OpenWrt nu este compilat din aceleași surse … și într-adevăr, OpenWrt corecționează codul din amonte cu acest patch . Schimbă fișierul folosit în /etc/dropbear/authorized_keys dacă (și numai dacă) utilizatorul țintă este root.

Deoarece menționați opkg, îmi imaginez că utilizați și OpenWrt și că aceasta este problema dvs. Am adăugat o etichetă OpenWrt la întrebarea dvs.

Răspuns

authorized_keys este un fișier, nu un director.

Un exemplu de fișier autorizat_chei: 

 # 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

De asemenea, .ssh/ și toate fișierele din acesta trebuie să fie deținute și citite numai de utilizator, în acest caz root.

Comentarii

  • Tocmai am remediat asta, dar încă nu am noroc 🙁 (vezi întrebarea actualizată).

Răspuns

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

Comentarii

  • Am reușit să convertesc cheia privată, dar totuși nu am noroc 🙁 (vezi întrebarea actualizată).

Răspuns

Trebuie să creați cheia ssh folosind instrumentul 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

Apoi reporniți daemonul dropbear. Apoi încercați să vă conectați, ar trebui să funcționeze.

Răspuns

Unele indicii care vă pot ajuta să vă conectați utilizând PKI cu Dropbear, au testat un container bazat pe pachete Alpine Linux 3.12, conectându-se de la un client OpenSSH.

  1. Utilizatorul are nevoie de un shell.
  2. Utilizatorul nu are au nevoie de o parolă de conectare.
  3. Utilizatorul „s ~ nu trebuie să să fie scris în grup / lume (adică chmod 755 cel puțin; ar trebui să utilizați 700 pentru directoarele de acasă).
  4. Utilizatorul „s ~/.ssh și ~/.ssh/authorized_keys trebuie să fie accesibil numai proprietarului (de ex. 700 în director și 600 în fișier).
  5. Acolo trebuie fii un director /tmp care se poate scrie;
  6. Intrările authorized_keys sunt în același format ca și cel folosit de OpenSSH.

Realizez containere folosind fișiere culese de cireșe din pachete alpine; Am o imagine de aproximativ 2 MB pe care o pot folosi, atâta timp cât sunt îndeplinite toate cerințele de mai sus.

Răspuns

I tocmai am întâlnit această întrebare în timp ce căutați motive pentru care conectarea prin dropbear la serverul meu a încetat brusc să funcționeze (funcționează de luni de zile, dar este folosită ocazional doar la câteva săptămâni).

soluția / explicația i găsit în cele din urmă a fost în mesajul debug1: send_pubkey_test: no mutual signature algorithm cu o intensitate mai mare a încercării de conectare ssh a clienților mei, ceea ce m-a condus la un articol de depanare a bitbucket .

menționează articolul Algoritmul RSA este depreciat rapid între sistemele de operare și clienții SSH din cauza diferitelor vulnerabilități de securitate […] ca cauză și enumeră posibilele soluții fie:

  • adăugarea PubkeyAcceptedKeyTypes +ssh-rsa la fișierul cfg-client (utilizați acest lucru doar ca soluție temporară deoarece este pote internațional nesigur!)

  • utilizați algoritmul / cheile ECDSA sau ED25519. acum, cu versiunea dropbear prezentă pe sistemul meu, puteam doar folosi ECDSA deoarece ED25519 mi-a dat erori algoritm necunoscut pe partea dropbears.

Sper că acest lucru ajută pe cineva să se împiedice de această întrebare, deoarece am făcut chiar și greu, probabil că nu este o soluție la întrebarea inițială, pls. iartă.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *