Yritän saada ssh-pääsyn reitittimelleni. Tällä hetkellä minulla on vain telnet-yhteys ja olen asentanut dropbearin ja olen käynnissä (käyttäen opkg: ta reitittimeen liitetyssä USB-asemassa).
Alusta asti tein yksityisen avaimen ja puroin sen salauksen (koska dropbear ei tue tätä vielä) ja julkinen:
cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys Latasin julkisen avaimen (authorized_keys ) /root/.ssh. Laitoin tiedoston Apache-palvelimelle (paikalliseen tietokoneeseeni) ja ladoin sen reitittimeen wget-sovelluksella (jotta ladattu tiedosto pääsee root-tiedostoon omistajana / ryhmänä) ja muutin sitten oikeudet 0600: een (sama asiakkaalle, mutta käyttäjäni kanssa ).
Kun yritän käyttää, se antaa minulle virheen ”Käyttöoikeus evätty (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). Ellei minä ” Luin väärin mitä dokumentaatio ( GitHub repo ) sanoo:
Palvelimen julkisen avaimen todennus :
Voit käyttää ~ / .ssh / authorisoituja avaimia samalla tavalla kuin OpenSSH: n kanssa, laita vain avaimen merkinnät tiedostoon. Niiden tulisi olla muotoa:
ssh- rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = joku @ hostname
Sinun on varmistettava, että ~ / .ssh, ja avain tiedoston, vain kirjoitettavissa käyttäjä. Varo toimittajat joka jakoi avaimen useisiin riveihin.
Dropbear tukee joitain vaihtoehtoja valtuutettujen avainten merkinnöille, katso sivua.
Tein kaiken, mitä se sanoo, joten älä tiedä missä ongelma voisi olla.
Asiakirjoissa mainitaan toinen tapa:
Asiakkaan julkisen avaimen todennus:
Dropbear voi tehdä julkisen avaimen todennuksen asiakkaana, mutta sinun on muunnettava OpenSSH-tyyliset avaimet Dropbear-muotoon tai käytettävä dropbear-avainta niiden luomiseen.
Jos sinulla on OpenSSH-tyylinen yksityinen avain ~ / .ssh / id_rsa, sinun on tehtävä:
dropbearconvert muuntaa openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db
Dropbear ei tue salattuja isäntänäppäimiä, vaikka se voi muodostaa yhteyden ssh-agenttiin.
Joten tämä valitsee, että jos muunnan yksityisen avaimen dropbeariksi yksityinen avain, voin käyttää dropbear-asiakasohjelmaa muodostaaksesi yhteyden dropbear-palvelimeen:
dropbearconvert openssh dropbear id_rsa id_rsa.db Yritän kokeilla tätä ja nähdä, toimiiko se. Mutta joka tapauksessa, palvelimen julkisen avaimen todennuksen pitäisi toimia.
Kommentit
vastaus
Lyhyt vastaus: Käytät todennäköisesti OpenWrt -ohjelmaa ja sinun on asennettava julkinen avain kohdassa /etc/dropbear/authorized_keys /root/.ssh/authorized_keys: n sijaan.
Pitkä vastaus:
GitHub repo, johon osoitat, on dropbear-kirjoittajan ylläpitämä; se sanoo, että ~/.ssh/authorized_keys toimii, ja GitHubin mukaan se on tehnyt niin ainakin 14 vuoden ajan. div id = ”afb87f4326”>
svr-authpubkey.c se lisää/.ssh/authorized_keys”pw_dir” -kansioon.
I kuitenkin , oli sama ongelma kuin sinulla, ja huomasin, että OpenWrt 18.06.1: ssä annettu binaari todella avaa /etc/dropbear/authorized_keys. Tiedoston käyttäminen toimii minulle .
Tämä ongelma on dokumentoitu OpenWrt-asiakirjoissa .
Joten miten?
Ottaen huomioon, että yllä oleva koodi ei pysty tuottamaan kyseistä tiedostonimeä yksin (.ssh puuttuu) ja .ssh -symbolilinkkiä ei ole missään, juoksin strings binaarissa. Tämä osoitti, että /etc/dropbear/authorized_keys mainitaan nimenomaisesti juuri ennen %s/.ssh/authorized_keys -tunnistetta, joka voidaan odottaa GitHub-koodilta. Katson, että OpenWrt-binaaria ei ole koottu samoista lähteistä … ja todellakin, OpenWrt korjaa ylävirran koodin tällä korjaustiedostolla . Se muuttaa käytetyn tiedoston muotoon /etc/dropbear/authorized_keys, jos (ja vain jos) kohdekäyttäjä on pääkäyttäjä.
Koska mainitset opkg, luulen, että käytät myös OpenWrt: tä ja että tämä on sinun ongelmasi. Olen lisännyt kysymykseesi OpenWrt-tunnisteen.
Vastaus
authorized_keys on tiedosto, ei hakemisto.
Esimerkki valtuutettujen avainten tiedostosta:
# 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
Myös .ssh/ ja kaikkien sen tiedostojen on oltava vain käyttäjän omistuksessa ja luettavissa, tässä tapauksessa root.
Kommentit
- Korjasin vasta, mutta silti ei onnea 🙁 (katso päivitetty kysymys).
Vastaa
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 Kommentit
- Onnistuin muuntamaan yksityisen avaimen, mutta silti ei onnea 🙁 (katso päivitetty kysymys).
Vastaa
Sinun on luotava ssh-avain dropbearkey-työkalulla. 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
Käynnistä sitten dropbear-daemon uudelleen. Yritä sitten muodostaa yhteys, sen pitäisi toimia.
Vastaa
Jotkut osoittimet, jotka saattavat auttaa sinua muodostamaan yhteyden PKI: n ja Dropbearin kanssa, testasivat Alpine Linux 3.12 -paketteihin perustuvaa säilöä, joka muodosti yhteyden OpenSSH-asiakkaasta.
- Käyttäjä tarvitsee kuoren.
- Käyttäjä ei tarvitset kirjautumissalasanan.
- Käyttäjä ”s
~ei saa olla kirjoitettavissa ryhmään / maailmaan (tschmod 755ainakin se; sinun pitäisi käyttää700kotihakemistoihin). - Käyttäjä ”s
~/.sshja~/.ssh/authorized_keyson oltava vain omistajan käytettävissä (esim.700hakemistossa ja600tiedostossa). - Siellä on olla kirjoitettava
/tmphakemisto -
authorized_keys-merkinnät ovat samassa muodossa kuin käytetyt kirjoittanut OpenSSH.
Teen kontteja käyttämällä kirsikalla poimittuja tiedostoja alppipaketeista; Minulla on ~ 2 Mt kuva, johon voin ssh: n tehdä niin kauan kuin kaikki yllä olevat vaatimukset täyttyvät.
Vastaa
I törmäsin juuri tähän kysymykseen etsimällä syitä, miksi dropbearin kautta muodostettu yhteys palvelimelleni lakkasi toimimasta yhtäkkiä (on toiminut kuukausia, mutta käyttää vain satunnaisesti muutaman viikon välein).
ratkaisu / selitys i vihdoin löydetty löytyi viestistä debug1: send_pubkey_test: no mutual signature algorithm, jossa asiakkaani ssh-yhteysyritys oli lisääntynyt, mikä johti minut bitbucket-vianetsintäartikkeliin .
kyseisessä artikkelissa mainitaan RSA-algoritmi on nopeasti vanhentunut kaikissa käyttöjärjestelmissä ja SSH-asiakkaissa useiden tietoturva-aukkojen […] vuoksi syynä ja luettelo mahdollisista ratkaisuista joko:
-
PubkeyAcceptedKeyTypes +ssh-rsalisääminen asiakkaiden cfg-tiedostoon (käytä tätä vain nimellä väliaikainen kiertotapa , koska se on pote tavallisesti epävarma!) -
käytä ECDSA- tai ED25519-algoritmia / avaimia. nyt järjestelmässäni olevan dropbear-version kanssa voisin vain käyttää ECDSA: ta, koska ED25519 antoi minulle tuntemattomia algoritmeja virheitä dropbear-puolella.
Toivottavasti tämä auttaa jotakuta kompastumaan kysymykseen, koska tein jopa kovaa, se ei todennäköisesti ole ratkaisu alkuperäiseen kysymykseen, pls. anteeksi.
opt/etc/dropbear(vain isäntäavaimet), ja sen kieltävä parametri on -w (ei käytä sitä).