Jeg prøver å få ssh tilgang til ruteren min. Foreløpig har jeg bare telnetilgang, og jeg installerte dropbear og kjører (bruker opkg på en USB-stasjon som er koblet til ruteren).
Fra begynnelsen var det jeg gjorde å generere en privat nøkkel og dekryptere den (siden dropbear støtter ikke dette ennå) og den offentlige:
cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys
Jeg lastet opp den offentlige nøkkelen (authorized_keys
) til /root/.ssh
. Jeg legger filen på en Apache-server (på min lokale datamaskin) og laster den ned på ruteren ved hjelp av wget (slik at den nedlastede filen blir rot som eier / gruppe) og endret deretter tillatelsene til 0600 (samme for klienten, men med brukeren min.
Når jeg prøver å få tilgang, gir det meg en «Tillatelse nektet (offentlig nøkkel)» -feil:
$ 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).
Med mindre jeg » m leser feil hva dokumentasjonen ( GitHub repo ) sier:
Serverenhetens offentlige nøkkel :
Du kan bruke ~ / .ssh / autoriserte_taster på samme måte som med OpenSSH, bare legg nøkkeloppføringene i den filen. De skal ha formen:
ssh- rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = noen @ vertsnavn
Du må sørge for at ~ / .ssh, og nøkkelfilen, er bare skrivbar av brukeren. Vokt dere for redaktører som delte nøkkelen i flere linjer.
Dropbear støtter noen alternativer for autoriserte_nøkler, se manpage.
Jeg gjorde alt det står, så jeg vet ikke hvor problemet kan være.
Dokumentasjonen nevner en annen måte:
Offentlig klientnøkkel auth:
Dropbear kan utføre godkjenning av offentlig nøkkel som klient, men du må konvertere OpenSSH-stilnøkler til Dropbear-format, eller bruke dropbearkey for å opprette dem.
Hvis du har en privat nøkkel i OpenSSH-stil ~ / .ssh / id_rsa, du må gjøre:
dropbearconvert openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db
Dropbear støtter ikke krypterte vertsnøkler, men kan koble til ssh-agent.
Så dette menes at hvis jeg konverterer den private nøkkelen til en dropbear privat nøkkel, kan jeg bruke dropbear-klienten til å koble til dropbear-serveren:
dropbearconvert openssh dropbear id_rsa id_rsa.db
Jeg skal prøve dette og se om det fungerer. Men uansett, skal serverenes nøkkelautentisering fungere.
Kommentarer
Svar
Kort svar: Du kjører sannsynligvis OpenWrt, og du må sette din offentlige nøkkel i /etc/dropbear/authorized_keys
i stedet for /root/.ssh/authorized_keys
.
Langt svar:
GitHub repo du peker på er den som vedlikeholdes av dropbear-forfatteren; det står at ~/.ssh/authorized_keys
fungerer, og ifølge GitHub har det gjort det i minst 14 år. Ser på koden i svr-authpubkey.c det legger til /.ssh/authorized_keys
til «pw_dir».
Jeg imidlertid , hadde det samme problemet som du har, og jeg oppdaget at binærprogrammet i OpenWrt 18.06.1 faktisk åpner /etc/dropbear/authorized_keys
. Å bruke den filen fungerer for meg .
Denne oppførselen er dokumentert i OpenWrt-dokumentene .
Så hvordan kommer det?
Gitt at koden ovenfor ikke kan produsere filnavnet alene (.ssh
mangler) og det er ingen .ssh
symlink hvor som helst, jeg løp strings
på binær. Det viste at /etc/dropbear/authorized_keys
er nevnt eksplisitt, rett før %s/.ssh/authorized_keys
som kan forventes fra GitHub-koden. Jeg konkluderer med at OpenWrt binær er ikke kompilert fra de samme kildene … og faktisk lapper OpenWrt oppstrøms koden med denne oppdateringen . Den endrer filen som brukes til /etc/dropbear/authorized_keys
hvis (og bare hvis) målbrukeren er root.
Siden du nevner opkg
, jeg forestiller meg at du også bruker OpenWrt, og at dette er problemet ditt. Jeg har lagt til en OpenWrt-tag i spørsmålet ditt.
Svar
authorized_keys
er en fil, ikke en katalog.
Et eksempel på autoriserte_keys-fil:
# 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
Også .ssh/
og alle filene i den må kun eies og leses av brukeren, i dette tilfellet root
.
Kommentarer
- Jeg fikset det bare, men likevel ikke lykke 🙁 (se oppdatert spørsmål).
Svar
mann 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
Kommentarer
- Jeg klarte å konvertere den private nøkkelen, men likevel ikke lykke 🙁 (se oppdatert spørsmål).
Svar
Du må opprette ssh-nøkkel ved hjelp av dropbearkey-verktøyet. 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 deretter dropbear-demonen på nytt. Prøv deretter å koble til, den skal fungere.
Svar
Noen pekere som kan hjelpe deg med å bli koblet til ved hjelp av PKI med Dropbear. Dette testet en container basert på Alpine Linux 3.12-pakker, som kobles fra en OpenSSH-klient.
- Brukeren trenger et skall.
- Brukeren trenger ikke det trenger passord for pålogging.
- Brukeren «s
~
må ikke være skrivbar for gruppe / verden (dvs.chmod 755
i det minste; du burde bruke700
til hjemmekataloger). - Brukeren «s
~/.ssh
og~/.ssh/authorized_keys
må bare være eier-tilgjengelig (f.eks.700
i katalogen og600
på filen). - Der må være en skrivbar
/tmp
katalog -
authorized_keys
oppføringene er i samme format som brukt av OpenSSH.
Jeg lager containere ved hjelp av kirsebærplukkede filer fra alpine pakker; Jeg har et ~ 2MB bilde som jeg kan ssh inn så lenge alle kravene ovenfor er oppfylt.
Svar
I nettopp kom over dette spørsmålet mens jeg lette etter årsaker til at tilkobling via dropbear til serveren min sluttet å fungere plutselig (har jobbet i flere måneder, men bare noen ganger brukt hvert par uker).
løsningen / forklaringen i endelig funnet var i meldingen debug1: send_pubkey_test: no mutual signature algorithm
med økt ordlyd på klientene mine ssh-tilkoblingsforsøk som førte meg til en feilsøkingsartikkel for bitbucket .
at artikkelen nevner RSA-algoritmen blir raskt avviklet på tvers av operativsystemer og SSH-klienter på grunn av ulike sikkerhetsproblemer […] som årsak og lister opp mulige løsninger enten:
-
å legge til
PubkeyAcceptedKeyTypes +ssh-rsa
til CFG-filene til klientene (bare bruk dette som en midlertidig løsning som den er pote nasjonalt usikker!) -
bruk ECDSA eller ED25519 algoritme / nøkler. nå med dropbear-versjonen på systemet mitt kunne jeg bare bruke ECDSA da ED25519 ga meg ukjent algoritme feil på dropbears-siden.
Håper dette hjelper noen som snubler over dette spørsmålet, ettersom jeg gjorde det vanskelig, det er sannsynligvis ikke en løsning på det opprinnelige spørsmålet, pls. tilgi.
opt/etc/dropbear
(bare vertsnøklene), og parameteren for å ikke tillate den er -w (bruker den ikke).