október 24, 2020
Articles
Nincs hozzászólás

A dropbear ssh szerver nem engedett ' t engedni, hogy csatlakozzam

Ssh hozzáférést próbálok elérni az útválasztómhoz. Jelenleg csak telnet-hozzáférésem van, és telepítettem a dropbear-ot, és futok (az opkg-t használom a routerhez csatlakoztatott USB-meghajtón).

Kezdetektől fogva privát kulcsot generáltam és visszafejtettem (mivel a dropbear még nem támogatja ezt) és a nyilvános: 

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

Töltöttem fel a nyilvános kulcsot (authorized_keys ) /root/.ssh címre. A fájlt egy Apache szerverre tettem (a helyi számítógépemre), és a wget használatával letöltöttem az útválasztóra (így a letöltött fájl tulajdonosként / csoportként gyökeret kap), majd megváltoztattam a jogosultságokat 0600-ra (ugyanaz az ügyfélnél, de a felhasználómnál ).

Amikor megpróbálok hozzáférni, “Engedély megtagadva (publickey)” hibát kap: 

$ 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).

Hacsak nem ” félreolvastam, amit a dokumentáció ( GitHub repo ) mond:

A szerver nyilvános kulcsának hitelesítése :

A ~ / .ssh / Authored_keys kulcsokat ugyanúgy használhatja, mint az OpenSSH esetén, csak a kulcs bejegyzéseket kell beletenni abba a fájlba. A következő formátumúaknak kell lenniük:

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

győződjön meg arról, hogy a ~ / .ssh, és a kulcs fájlt, csak írható, a felhasználó által. Vigyázni kell, mert a szerkesztők amelyek megosztották a kulcsot több sorba.

A Dropbear támogat néhány beállítást a Author_Key bejegyzésekhez, lásd a manpage-ot.

Mindent megtettem, amit mondott, ezért nem tudom, hol lehet a probléma.

A dokumentáció egy másik módszert említ:

Az ügyfél nyilvános kulcsának hitelesítése:

A Dropbear képes nyilvános kulcs hitelesítésre kliensként, de az OpenSSH stíluskulcsokat át kell alakítania Dropbear formátumba, vagy a dropbearkey használatával létre kell hoznia őket.

Ha rendelkezik OpenSSH stílusú magánkulccsal ~ / .ssh / id_rsa, tenned kell:

dropbearconvert >

A Dropbear nem támogatja a titkosított gazdaállományokat, bár csatlakozhatnak az ssh-agenthez.

Tehát ez azt állítja, hogy ha a magánkulcsot dropbearré konvertálom privát kulcs, használhatom a dropbear klienst a csatlakozáshoz a dropbear kiszolgálóhoz: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Megpróbálom kipróbálni, hogy működik-e. De mindenképp a kiszolgáló nyilvános kulcsának hitelesítésének működnie kell. Alapértelmezés szerint több ssh-kiszolgálón a root bejelentkezés biztonsága miatt tilos.

  • Szerintem igen, nem látok ‘ egyetlen konfigurációs fájlt sem a (csak a gazdagépkulcsok), és a tiltásának paramétere a -w (nem használja).
  • Szerkesztett kérdés: kövesse a lépéseket az ssh kulcs dropbearré való átalakításához kulcs és semmi (amint azt Ipor Sircer megjegyezte az első válaszból).
  • Dokumentációt talált a github repóban (ott ‘ nem jelenthet, a problémák nem engedélyezettek) . A kérdést újra szerkesztették. Ugyanaz a probléma még 🙁

    • Válasz

    Rövid válasz: Valószínűleg az OpenWrt-et futtatja, és telepítenie kell nyilvános kulcsa a /etc/dropbear/authorized_keys fájlban a /root/.ssh/authorized_keys helyett.

    Hosszú válasz:

    A GitHub a repo, amelyre rámutat, a dropbear szerző által fenntartott; azt mondja, hogy a ~/.ssh/authorized_keys működik, és a GitHub szerint legalább 14 évig ezt tette. div id = “afb87f4326”>

    svr-authpubkey.c hozzáadja a/.ssh/authorized_keyselemet a “pw_dir” könyvtárhoz.

    Én azonban , ugyanaz a problémája volt, mint neked, és rájöttem, hogy az OpenWrt 18.06.1 verziójában megadott bináris fájl valójában megnyílik /etc/dropbear/authorized_keys. A fájl használata nekem .

    Ezt a viselkedést az az OpenWrt dokumentumaiban dokumentálják.

    Hogyhogy?

    Tekintettel arra, hogy a fenti kód nem képes önmagában előállítani a fájlnevet (a .ssh hiányzik), és sehol nincs .ssh symlink, a binárison futottam strings. Ez azt mutatta, hogy a /etc/dropbear/authorized_keys -t kifejezetten megemlítik, közvetlenül a %s/.ssh/authorized_keys előtt, amely a GitHub-kódtól elvárható. Arra a következtetésre jutottam, hogy az OpenWrt bináris fájl nem ugyanazokból a forrásokból áll össze … sőt, az OpenWrt az upstream kódot ezzel a javítással javítja. Megváltoztatja a használt fájlt /etc/dropbear/authorized_keys fájlra, ha (és csak akkor), ha a célfelhasználó root.

    Mivel megemlíti a opkg, azt képzelem, hogy te is OpenWrt-t használsz, és hogy ez a te problémád. Hozzáadtam egy OpenWrt címkét a kérdésedhez.

    Válasz

    authorized_keys fájl, nem könyvtár.

    Példa a felhatalmazott_kulcs fájlra: 

     # 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

    A .ssh/ és az összes benne lévő fájlnak csak a felhasználónak kell lennie, és olvashatónak, ebben az esetben root.

    Megjegyzések

    • Csak kijavítottam, de még mindig nem volt szerencsém 🙁 (lásd a frissített kérdést).

    Válasz

    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

    Megjegyzések

    • Sikerült átalakítanom a magánkulcsot, de mégsem volt szerencsém 🙁 (lásd a frissített kérdést).

    Válasz

    Az ssh kulcsot a dropbearkey eszközzel kell létrehozni. 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

    Ezután indítsa újra a dropbear démonot. Ezután próbáljon meg csatlakozni, működnie kell.

    Válasz

    Néhány mutató, amely segíthet a PKI és a Dropbear használatában, ez egy Alpine Linux 3.12 csomagokon alapuló tárolót tesztelt, OpenSSH kliensről csatlakozva.

    1. A felhasználónak shellre van szüksége.
    2. A felhasználónak nem bejelentkezési jelszóra van szükség.
    3. A “s ~ felhasználónak nem szabad legyen csoport / világ írható (azaz chmod 755 legalábbis; a (z) 700 alkalmazást az otthoni könyvtárakhoz kell használnia.
    4. A “s ~/.ssh és ~/.ssh/authorized_keys csak a tulajdonosok számára érhető el (pl. 700 a könyvtárban és 600 a fájlban).
    5. Ott írható /tmp könyvtár legyen
    6. A authorized_keys bejegyzések a használt formátumban vannak az OpenSSH által.

    Tárolókat készítek alpesi csomagokból származó, cseresznyével szedett fájlok felhasználásával; Van egy ~ 2 MB méretű képem, amibe belekerülhetek, amíg a fenti követelmények mindegyike teljesül.

    Válasz

    I épp erre a kérdésre bukkantam, miközben okokat kerestem, miért hirtelen abbahagyta a kapcsolatot a dropbear-on keresztül a szerveremmel (hónapok óta működik, de csak alkalmanként használta pár hetente).

    a megoldás / magyarázat i végül megtalálható volt a debug1: send_pubkey_test: no mutual signature algorithm üzenetben, megnövekedett bőbeszédűséggel az ügyfelek ssh kapcsolati kísérletében, amely egy bitbucket hibaelhárítási cikkhez vezetett .

    a cikk megemlíti Az RSA algoritmust gyorsan elavulják az operációs rendszerek és az SSH-kliensek a különböző biztonsági rések miatt […] okként, és felsorolja a lehetséges megoldásokat. vagy:

    • PubkeyAcceptedKeyTypes +ssh-rsa hozzáadása az ügyfelek cfg-fájljához (csak ideiglenes megoldás mivel ez a pote általában bizonytalan!)

    • használja az ECDSA vagy az ED25519 algoritmust / kulcsokat. most a rendszeremen található dropbear verzióval csak az ECDSA-t használhatom, mivel az ED25519 ismeretlen algoritmus hibákat adott a dropbears oldalán.

    Remélem, hogy ez segít valakinek megbotlani ebben a kérdésben, mivel még keményen is tettem, valószínűleg nem jelent megoldást az eredeti kérdésre, pls. megbocsáss.

    Vélemény, hozzászólás?

    Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük