Ottobre 24, 2020
Articles
Nessun commento

Il server dropbear ssh ha vinto ' per consentirmi di connettermi

Sto cercando di ottenere laccesso ssh al mio router. Attualmente ho solo accesso telnet e ho installato dropbear ed è in esecuzione (utilizzando opkg su ununità USB collegata al router).

Fin dallinizio, quello che ho fatto è stato generare una chiave privata e decrittografarla (da allora dropbear non lo supporta ancora) e quella pubblica: 

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

Ho caricato la chiave pubblica (authorized_keys ) a /root/.ssh. Ho messo il file su un server Apache (nel mio computer locale) e lo scarico sul router usando wget (così il file scaricato diventa root come proprietario / gruppo) e poi ho cambiato i permessi in 0600 (lo stesso per il client ma con il mio utente ).

Quando provo ad accedere, viene visualizzato il messaggio di errore “Permission denied (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).

A meno che io ” sto leggendo male cosa dice la documentazione ( GitHub repo ):

Autenticazione della chiave pubblica del server :

Puoi usare ~ / .ssh / authorized_keys nello stesso modo di OpenSSH, basta inserire le voci chiave in quel file. Dovrebbero essere nel formato:

ssh- rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = qualcuno @ hostname

È necessario assicurarsi che ~ / .ssh, e il file di chiave, sono scrivibili solo dallutente. Attenzione ai redattori che ha diviso la chiave in più righe.

Dropbear supporta alcune opzioni per le voci authorized_keys, vedere la manpage.

Ho fatto tutto quello che dice, quindi ho non so dove potrebbe essere il problema.

La documentazione menziona un altro modo:

Autenticazione chiave pubblica client:

Dropbear può eseguire lautenticazione della chiave pubblica come client, ma dovrai convertire le chiavi in stile OpenSSH nel formato Dropbear o utilizzare dropbearkey per crearle.

Se hai una chiave privata in stile OpenSSH ~ / .ssh / id_rsa, devi fare:

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

Dropbear non supporta le chiavi host crittografate sebbene possa connettersi a ssh-agent.

Quindi questo menu è che se converto la chiave privata in dropbear chiave privata, posso usare il client dropbear per connettermi al server dropbear: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Vado a provare e vedere se funziona. Comunque, lautenticazione della chiave pubblica del server dovrebbe funzionare.

Commenti

  • Il server / config ssh dropbear consente laccesso come root? Per impostazione predefinita su diversi server ssh, laccesso root non è consentito per sicurezza.
  • Penso di sì, non ‘ non vedo alcun file di configurazione in opt/etc/dropbear (solo le chiavi host) e il parametro per non consentirlo è -w (non lo si utilizza).
  • Domanda modificata: sono stati seguiti i passaggi per convertire la chiave ssh in dropbear chiave e niente (come notato da Ipor Sircer dalla prima risposta).
  • Documentazione trovata nel repository github (può ‘ t segnalare lì, i problemi non sono abilitati) . Domanda modificata di nuovo. Ancora lo stesso problema 🙁

Risposta

Risposta breve: probabilmente stai utilizzando OpenWrt e devi inserire la tua chiave pubblica in /etc/dropbear/authorized_keys invece di /root/.ssh/authorized_keys.

Risposta lunga:

GitHub Il repository a cui si punta è quello gestito dallautore dropbear; dice che ~/.ssh/authorized_keys funziona e secondo GitHub lo ha fatto almeno per 14 anni. Guardando il codice in svr-authpubkey.c aggiunge /.ssh/authorized_keys a “pw_dir”.

Io, tuttavia , ha avuto lo stesso problema che hai tu e ho scoperto che il file binario fornito in OpenWrt 18.06.1 effettivamente apre /etc/dropbear/authorized_keys. Usare quel file funziona per me .

Questo comportamento è documentato in la documentazione di OpenWrt .

Allora come mai?

Dato che il codice precedente non può produrre quel nome file da solo (manca il .ssh) e non è presente alcun .ssh collegamento simbolico da nessuna parte, ho eseguito strings sul file binario. Ciò ha mostrato che /etc/dropbear/authorized_keys è menzionato esplicitamente, subito prima del %s/.ssh/authorized_keys che ci si può aspettare dal codice GitHub. Concludo che il binario OpenWrt non è compilato dalle stesse fonti … e in effetti, OpenWrt patcha il codice a monte con questa patch . Modifica il file utilizzato in /etc/dropbear/authorized_keys se (e solo se) lutente di destinazione è root.

Dato che hai menzionato opkg, immagino che tu stia usando anche OpenWrt e che questo sia il tuo problema. Ho aggiunto un tag OpenWrt alla tua domanda.

Risposta

authorized_keys è un file, non una directory.

Un esempio di file 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

Anche .ssh/ e tutti i file in esso contenuti devono essere di proprietà e leggibili solo dallutente, in questo caso root.

Commenti

  • Lho appena risolto ma ancora senza fortuna 🙁 (vedi domanda aggiornata).

Risposta

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

Commenti

  • Sono riuscito a convertire la chiave privata, ma ancora senza fortuna 🙁 (vedi domanda aggiornata).

Risposta

Devi creare una chiave ssh utilizzando lo strumento 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

Quindi riavvia il demone dropbear. Quindi prova a connetterti, dovrebbe funzionare.

Risposta

Alcuni suggerimenti che possono aiutarti a connetterti usando PKI con Dropbear, questo ha testato un contenitore basato su pacchetti Alpine Linux 3.12, che si connette da un client OpenSSH.

  1. Lutente ha bisogno di una shell.
  2. Lutente no è necessaria una password di accesso.
  3. Lutente “s ~ non deve essere scrivibile dal gruppo / mondo (es chmod 755 almeno; dovresti utilizzare 700 per le directory home).
  4. Lutente “s ~/.ssh e ~/.ssh/authorized_keys deve essere accessibile solo dal proprietario (ad es. 700 nella directory e 600 nel file).
  5. Lì deve essere una /tmp directory
  6. scrivibile Le voci authorized_keys hanno lo stesso formato utilizzato da OpenSSH.

Sto creando contenitori usando file selezionati da pacchetti alpine; Ho unimmagine di ~ 2 MB in cui posso eseguire lSSH purché tutti i requisiti di cui sopra siano soddisfatti.

Risposta

I mi sono appena imbattuto in questa domanda mentre cercavo i motivi per cui la connessione tramite dropbear al mio server ha smesso di funzionare allimprovviso (funziona da mesi ma viene utilizzata solo occasionalmente ogni due settimane).

la soluzione / spiegazione i finalmente trovato era nel messaggio debug1: send_pubkey_test: no mutual signature algorithm con maggiore dettaglio sul tentativo di connessione ssh dei miei clienti che mi ha portato a un articolo sulla risoluzione dei problemi di bitbucket .

quellarticolo menziona Lalgoritmo RSA viene rapidamente deprecato tra i sistemi operativi e i client SSH a causa di varie vulnerabilità di sicurezza […] come causa ed elenca come possibili soluzioni alternative o:

  • aggiungendo PubkeyAcceptedKeyTypes +ssh-rsa al file cfg del client (usalo solo come soluzione temporanea poiché è possibile ntionally insecure!)

  • usa algoritmo / chiavi ECDSA o ED25519. ora con la versione dropbear presente sul mio sistema potevo solo usare ECDSA poiché ED25519 mi dava errori algoritmo sconosciuto sul lato dropbears.

Spero che questo aiuti qualcuno a inciampare su questa domanda come ho fatto anche io, probabilmente non è una soluzione alla domanda originale, per favore. perdona.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *