oktober 24, 2020
Articles
Geen reacties

dropbear ssh-server heeft ' t me geen verbinding laten maken

Ik probeer ssh-toegang tot mijn router te krijgen. Momenteel heb ik alleen telnet-toegang en heb ik dropbear geïnstalleerd en is het actief (met opkg op een usb-stick die op de router is aangesloten).

Vanaf het begin heb ik een privésleutel gegenereerd en deze gedecodeerd (sinds dropbear ondersteunt dit nog niet) en de openbare: 

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

Ik heb de openbare sleutel geüpload (authorized_keys ) naar /root/.ssh. Ik plaatste het bestand op een Apache-server (op mijn lokale computer) en download het op de router met wget (zodat het gedownloade bestand root wordt als eigenaar / groep) en veranderde vervolgens de rechten in 0600 (hetzelfde voor de client maar met mijn gebruiker ).

Wanneer ik toegang probeer te krijgen, krijg ik de foutmelding “Toestemming geweigerd (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).

Tenzij ik ” m verkeerd gelezen wat de documentatie ( GitHub-opslagplaats ) zegt:

Verificatie van server met openbare sleutel :

Je kunt ~ / .ssh / geautoriseerde_keys op dezelfde manier gebruiken als met OpenSSH, plaats gewoon de sleutelvermeldingen in dat bestand. Ze zouden de volgende vorm moeten hebben:

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

U moet ervoor zorgen dat ~ / .ssh, en de sleutel bestand, zijn alleen beschrijfbaar door de gebruiker. pas op voor de redactie die de sleutel splitsen in meerdere regels.

Dropbear ondersteunt enkele opties voor invoer met geautoriseerde_toetsen, zie de manpage.

Ik deed alles wat het zegt, dus ik weet niet waar het probleem zou kunnen zijn.

De documentatie vermeldt een andere manier:

Verificatie openbare sleutel van client:

Dropbear kan als client authenticatie met openbare sleutel uitvoeren, maar je zult OpenSSH-stijlsleutels naar Dropbear-formaat moeten converteren, of dropbearkey gebruiken om ze te maken.

Als je een OpenSSH-stijl privésleutel hebt ~ / .ssh / id_rsa, je moet het volgende doen:

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

Dropbear ondersteunt geen versleutelde hostkeys, maar kan wel verbinding maken met ssh-agent.

Dus dit menu is dat als ik de privésleutel converteer naar een dropbear private key, kan ik de dropbear-client gebruiken om verbinding te maken met de dropbear-server: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Ik ga dit proberen en kijken of het werkt. Maar goed, Server public key auth zou moeten werken.

Reacties

  • Staat de dropbear ssh server / config root login toe? Standaard is root-login op verschillende ssh-servers om veiligheidsredenen niet toegestaan.
  • Ik denk van wel, ik zie ‘ geen configuratiebestand in opt/etc/dropbear (alleen de hostsleutels), en de parameter om het niet toe te staan is -w (niet gebruiken).
  • Vraag bewerkt: volg de stappen om de ssh-sleutel om te zetten in een dropbear key en niets (zoals opgemerkt door Ipor Sircer vanaf het eerste antwoord).
  • Documentatie gevonden in de github-repo (kan ‘ daar rapporteren, problemen zijn niet ingeschakeld) . Vraag opnieuw bewerkt. Nog hetzelfde probleem 🙁

Answer

Kort antwoord: u gebruikt waarschijnlijk OpenWrt en u moet uw openbare sleutel in /etc/dropbear/authorized_keys in plaats van /root/.ssh/authorized_keys.

Lang antwoord:

De GitHub repo waarnaar je verwijst, is degene die wordt onderhouden door de auteur van dropbear; er staat dat ~/.ssh/authorized_keys werkt, en volgens GitHub doet het dat al minstens 14 jaar. Kijkend naar de code in svr-authpubkey.c het voegt /.ssh/authorized_keys toe aan de “pw_dir”.

Ik echter , had hetzelfde probleem als jij, en ik ontdekte dat het binaire bestand in OpenWrt 18.06.1 eigenlijk /etc/dropbear/authorized_keys opent. Het gebruik van dat bestand werkt voor mij .

Dit gedrag wordt gedocumenteerd in de OpenWrt-documenten .

Hoe komt dat dan?

Gezien het feit dat de bovenstaande code die bestandsnaam niet zelf kan produceren (de .ssh ontbreekt) en er is nergens een .ssh symlink, ik heb strings op het binaire bestand uitgevoerd. Dat toonde aan dat /etc/dropbear/authorized_keys expliciet wordt genoemd, net voor de %s/.ssh/authorized_keys die kan worden verwacht van de GitHub-code. Ik concludeer dat het OpenWrt-binaire bestand niet uit dezelfde bronnen is gecompileerd … en inderdaad, OpenWrt patcht de upstream-code met deze patch . Het verandert het gebruikte bestand in /etc/dropbear/authorized_keys als (en alleen als) de doelgebruiker root is.

Aangezien je opkg, ik kan me voorstellen dat je ook OpenWrt gebruikt, en dat dit jouw probleem is. Ik heb een OpenWrt-tag aan je vraag toegevoegd.

Answer

authorized_keys is een bestand, geen directory.

Een voorbeeld van een Authorized_keys-bestand: 

 # 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

Ook de .ssh/ en alle bestanden erin moeten eigendom zijn van en alleen gelezen kunnen worden door de gebruiker, in dit geval root.

Reacties

  • Ik heb dat net opgelost maar nog steeds geen geluk 🙁 (zie bijgewerkte vraag).

Antwoord

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

Reacties

  • Het is me gelukt om de privésleutel om te zetten, maar nog steeds geen geluk 🙁 (zie bijgewerkte vraag).

Antwoord

U moet een ssh-sleutel maken met de tool 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

Start vervolgens de dropbear-daemon opnieuw. Probeer vervolgens verbinding te maken, het zou moeten werken.

Antwoord

Enkele tips die u kunnen helpen om verbinding te maken met PKI met Dropbear, dit testte een container op basis van Alpine Linux 3.12-pakketten, die verbinding maakte vanaf een OpenSSH-client.

  1. De gebruiker heeft een shell nodig.
  2. De gebruiker heeft dat niet een inlogwachtwoord nodig.
  3. De gebruiker “s ~ mag niet be group / world beschrijfbaar (bijv chmod 755 het, tenminste; je zou 700 voor homedirectorys moeten gebruiken).
  4. De gebruiker “s ~/.ssh en ~/.ssh/authorized_keys moet alleen eigenaar-toegankelijk zijn (bijv. 700 in de directory en 600 in het bestand).
  5. Daar moet een beschrijfbare /tmp directory zijn
  6. De authorized_keys -vermeldingen hebben dezelfde indeling als gebruikt door OpenSSH.

Ik maak containers met behulp van door kersen geselecteerde bestanden uit alpine pakketten; Ik heb een afbeelding van ~ 2 MB waar ik in kan sshen zolang aan alle bovenstaande vereisten wordt voldaan.

Antwoord

I kwam deze vraag net tegen terwijl ik op zoek was naar redenen waarom het verbinden via dropbear met mijn server plotseling stopte met werken (werkt al maanden maar wordt slechts af en toe om de paar weken gebruikt).

de oplossing / uitleg i uiteindelijk gevonden was in het bericht debug1: send_pubkey_test: no mutual signature algorithm met verhoogde breedsprakigheid bij de ssh-verbindingspoging van mijn client die me naar een bitbucket-artikel voor probleemoplossing .

dat artikel noemt Het RSA-algoritme wordt snel verouderd in besturingssystemen en SSH-clients vanwege verschillende beveiligingsproblemen […] als oorzaak en geeft een lijst van mogelijke tijdelijke oplossingen. ofwel:

  • PubkeyAcceptedKeyTypes +ssh-rsa toevoegen aan het cfg-bestand van de klant (gebruik dit alleen als een tijdelijke oplossing zoals het is ongebruikelijk onveilig!)

  • gebruik ECDSA of ED25519 algoritme / sleutels. nu met de dropbear-versie aanwezig op mijn systeem kon ik alleen ECDSA gebruiken omdat ED25519 me onbekende algoritme -fouten gaf aan de dropbears-kant.

Ik hoop dat dit iemand helpt die over deze vraag struikelt, want ik deed het, zelfs als het waarschijnlijk geen oplossing is voor de oorspronkelijke vraag, pls. vergeef.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *