Dropbear ssh server nebude moci ' připojit

Snažím se získat ssh přístup k mému routeru. V současné době mám pouze přístup k telnetu a nainstaloval jsem dropbear a běží (pomocí opkg na USB disku připojeném k routeru).

Od začátku jsem vygeneroval soukromý klíč a dešifroval ho (protože Dropbear to zatím nepodporuje) a veřejný:

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

Nahrál jsem veřejný klíč (authorized_keys ) do /root/.ssh. Vložil jsem soubor na server Apache (do mého místního počítače) a stáhl jsem ho na router pomocí wget (aby se stažený soubor zakořenil jako vlastník / skupina) a poté změnil oprávnění na 0600 (stejné pro klienta, ale s mým uživatelem ).

Když se pokusím o přístup, zobrazí se mi chyba „Povolení odepřeno (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). 

Pokud ne “ nesprávné čtení toho, co říká dokumentace ( GitHub repo ):

Auth public key auth :

Můžete použít ~ / .ssh / authorized_keys stejným způsobem jako u OpenSSH, stačí do tohoto souboru vložit klíčové položky. Měly by mít tvar:

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

musíte se ujistit, že ~ / .ssh a soubor klíče, lze zapisovat pouze uživatel. Pozor editorů který rozdělil klíč do více řádků.

Dropbear podporuje některé možnosti pro položky authorized_keys, viz manuálová stránka.

Udělal jsem všechno, co říká, takže jsem nevím, kde by mohl být problém.

Dokumentace uvádí jiný způsob:

Ověřování veřejného klíče klienta:

Dropbear může provádět ověření veřejného klíče jako klient, ale budete muset převést klíče stylu OpenSSH do formátu Dropbear nebo je vytvořit pomocí dropbearkey.

Pokud máte soukromý klíč ve stylu OpenSSH ~ / .ssh / id_rsa, musíte udělat:

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

Dropbear nepodporuje šifrované hostitelské klíče, i když se může připojit k ssh-agent.

Takže toto je to, že když převádím soukromý klíč na dropbear soukromý klíč, mohu se pomocí klienta Dropbear připojit k serveru Dropbear:

dropbearconvert openssh dropbear id_rsa id_rsa.db 

Zkusím to a uvidíme, jestli to funguje. Ale stejně by měl fungovat veřejný klíč serveru.

Komentáře

  • Umožňuje dropbear ssh server / config přihlášení rootem? Ve výchozím nastavení je na několika serverech ssh z důvodu bezpečnosti rootování zakázáno.
  • Myslím, že ano, ‚ nevidím žádný konfigurační soubor v opt/etc/dropbear (pouze klíče hostitele) a parametr, který jej zakazuje, je -w (nepoužívá se).
  • Otázka upravena: postupujte podle pokynů k převodu klíče ssh na dropbear klíč a nic (jak poznamenal Ipor Sircer z první odpovědi).
  • Nalezena dokumentace v repo github (nelze ‚ tam nahlásit, problémy nejsou povoleny) . Otázka byla znovu upravena. Stejný problém 🙁

Odpověď

Krátká odpověď: Pravděpodobně používáte OpenWrt a musíte dát váš veřejný klíč v /etc/dropbear/authorized_keys místo /root/.ssh/authorized_keys.

Dlouhá odpověď:

The GitHub repo, na které ukážete, je udržováno autorem dropbear; říká, že ~/.ssh/authorized_keys funguje a podle GitHubu to dělá minimálně 14 let. Při pohledu na kód v svr-authpubkey.c přidává /.ssh/authorized_keys do „pw_dir“.

Já však , měl stejný problém jako vy, a zjistil jsem, že binární soubor poskytovaný v OpenWrt 18.06.1 je ve skutečnosti otevírá /etc/dropbear/authorized_keys. Použití tohoto souboru funguje pro mě .

Toto chování je dokumentováno v dokumentech OpenWrt .

Tak jak to?

Vzhledem k tomu, že výše uvedený kód nedokáže sám vytvořit tento název souboru (chybí .ssh) a nikde neexistuje .ssh symbolický odkaz, běžel jsem strings na binární soubor. To ukázalo, že /etc/dropbear/authorized_keys je výslovně zmíněn těsně před %s/.ssh/authorized_keys, který lze očekávat od kódu GitHub. Dospěl jsem k závěru, že binární soubor OpenWrt není kompilován ze stejných zdrojů … a OpenWrt skutečně opravuje upstreamový kód pomocí této opravy . Změní soubor použitý na /etc/dropbear/authorized_keys pokud (a pouze pokud) je cílovým uživatelem root.

Protože zmiňujete opkg, představuji si, že také používáte OpenWrt, a že to je váš problém. Přidal jsem k vaší otázce značku OpenWrt.

Odpověď

authorized_keys je soubor, nikoli adresář.

Ukázkový soubor 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

Také .ssh/ a všechny soubory v něm musí vlastnit a číst pouze uživatel, v tomto případě root.

Komentáře

  • Právě jsem to opravil, ale stále nemám štěstí 🙁 (viz aktualizovanou otázku).

Odpověď

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 

Komentáře

  • Podařilo se mi převést soukromý klíč, ale stále nemám štěstí 🙁 (viz aktualizovaná otázka).

Odpovědět

Musíte vytvořit klíč ssh pomocí nástroje 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

Poté restartujte démona dropbear. Zkuste se připojit, mělo by to fungovat.

Odpověď

Některé ukazatele, které vám mohou pomoci připojit se pomocí PKI s Dropbear, testovaly kontejner založený na balíčcích Alpine Linux 3.12, který se připojuje z klienta OpenSSH.

  1. Uživatel potřebuje shell.
  2. Uživatel není potřebujete přihlašovací heslo.
  3. Uživatel ~ nesmí být zapisovatelný pro skupinu / svět (tj chmod 755 alespoň; měli byste používat 700 pro domácí adresáře).
  4. Uživatelské ~/.ssh a ~/.ssh/authorized_keys musí být přístupný pouze vlastníkovi (např. 700 v adresáři a 600 v souboru).
  5. Tam musí být zapisovatelný /tmp adresář
  6. Položky authorized_keys jsou ve stejném formátu, jaký se používá od OpenSSH.

Dělám kontejnery pomocí třešní vybraných souborů z alpských balíčků; Mám obrázek ~ 2 MB, do kterého můžu ssh zařadit, pokud jsou splněny všechny výše uvedené požadavky.

Odpověď

I právě jsem narazil na tuto otázku při hledání důvodů, proč připojení přes dropbear k mému serveru najednou přestalo fungovat (funguje už měsíce, ale jen příležitostně se používá každých pár týdnů).

řešení / vysvětlení i konečně nalezen byl ve zprávě debug1: send_pubkey_test: no mutual signature algorithm se zvýšenou výřečností při pokusu o připojení ssh mých klientů, což mě vedlo k článku o řešení problémů s bitbucketem .

tento článek zmiňuje Algoritmus RSA je rychle zastaralý v operačních systémech a klientech SSH kvůli různým bezpečnostním zranitelnostem […] jako příčina a uvádí seznam možných řešení buď:

  • přidání PubkeyAcceptedKeyTypes +ssh-rsa do souboru cfg klienta (použijte pouze jako dočasné řešení tak, jak je to možné ncionálně nejistá!)

  • použijte algoritmus / klíče ECDSA nebo ED25519. nyní s dropbear verzí přítomnou v mém systému jsem mohl pouze použít ECDSA, protože ED25519 mi dal neznámý algoritmus chyby na straně dropbears.

Doufám, že to někomu pomůže klopýtnout o tuto otázku, protože jsem se dokonce snažil, pravděpodobně to není řešení původní otázky, pls. odpustit.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *