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
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.
- Uživatel potřebuje shell.
- Uživatel není potřebujete přihlašovací heslo.
- Uživatel
~
nesmí být zapisovatelný pro skupinu / svět (tjchmod 755
alespoň; měli byste používat700
pro domácí adresáře). - Uživatelské
~/.ssh
a~/.ssh/authorized_keys
musí být přístupný pouze vlastníkovi (např.700
v adresáři a600
v souboru). - Tam musí být zapisovatelný
/tmp
adresář - 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.
opt/etc/dropbear
(pouze klíče hostitele) a parametr, který jej zakazuje, je -w (nepoužívá se).