dropbear ssh server ' lässt mich keine Verbindung herstellen

Ich versuche, ssh-Zugriff auf meinen Router zu erhalten. Derzeit habe ich nur Telnet-Zugriff und habe Dropbear installiert und läuft (mit opkg auf einem mit dem Router verbundenen USB-Laufwerk).

Von Anfang an habe ich einen privaten Schlüssel generiert und ihn entschlüsselt (seitdem dropbear unterstützt dies noch nicht) und den öffentlichen:

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

Ich habe den öffentlichen Schlüssel hochgeladen (authorized_keys ) bis /root/.ssh. Ich habe die Datei auf einen Apache-Server (auf meinem lokalen Computer) gestellt und sie mit wget auf den Router heruntergeladen (damit die heruntergeladene Datei als Eigentümer / Gruppe root wird) und dann die Berechtigungen auf 0600 geändert (für den Client, aber für meinen Benutzer) ).

Wenn ich versuche, darauf zuzugreifen, wird der Fehler „Berechtigung verweigert (öffentlicher Schlüssel)“ angezeigt:

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

Es sei denn, ich “ Ich habe falsch verstanden, was in der Dokumentation ( GitHub-Repo ) steht:

Authentifizierung des öffentlichen Schlüssels des Servers :

Sie können ~ / .ssh / authorized_keys auf die gleiche Weise wie bei OpenSSH verwenden. Fügen Sie einfach die Schlüsseleinträge in diese Datei ein. Sie sollten die folgende Form haben:

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

Sie müssen sicherstellen, dass ~ / .ssh und die Schlüsseldatei, sind nur für den Benutzer beschreibbar. Hüten Sie sich vor der Redakteure das teilte den Schlüssel

Dropbear unterstützt einige Optionen für Einträge mit autorisierten Schlüsseln, siehe Manpage.

Ich habe alles getan, was es sagt, also ich Ich weiß nicht, wo das Problem liegen könnte.

In der Dokumentation wird ein anderer Weg erwähnt:

Authentifizierung des öffentlichen Clients:

Dropbear kann als Client die Authentifizierung mit öffentlichen Schlüsseln durchführen, Sie müssen jedoch OpenSSH-Schlüssel in das Dropbear-Format konvertieren oder sie mit Dropbearkey erstellen.

Wenn Sie einen privaten Schlüssel im OpenSSH-Stil haben ~ / .ssh / id_rsa müssen Sie Folgendes tun:

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

Dropbear unterstützt keine verschlüsselten Hostschlüssel, kann jedoch eine Verbindung zum ssh-agent herstellen.

Dies bedeutet also, dass ich den privaten Schlüssel in einen Dropbear konvertiere Privater Schlüssel, ich kann den Dropbear-Client verwenden, um eine Verbindung zum Dropbear-Server herzustellen:

dropbearconvert openssh dropbear id_rsa id_rsa.db 

Ich werde dies versuchen und prüfen, ob es funktioniert. Auf jeden Fall sollte die Authentifizierung mit öffentlichem Schlüssel des Servers funktionieren.

Kommentare

  • Ermöglicht der dropbear ssh server / config die Root-Anmeldung? Auf mehreren SSH-Servern ist die Root-Anmeldung aus Sicherheitsgründen standardmäßig nicht zulässig.
  • Ich glaube, ich sehe ‚ keine Konfigurationsdatei in (nur die Hostschlüssel), und der Parameter, der dies nicht zulässt, ist -w (wird nicht verwendet).
  • Frage bearbeitet: Befolgen Sie die Schritte, um den SSH-Schlüssel in einen Dropbear zu konvertieren Schlüssel und nichts (wie von Ipor Sircer aus der ersten Antwort vermerkt).
  • Dokumentation im Github-Repo gefunden (‚ kann dort nicht berichten, Probleme sind nicht aktiviert) . Frage erneut bearbeitet. Gleiches Problem noch 🙁

Antwort

Kurze Antwort: Sie führen wahrscheinlich OpenWrt aus und müssen setzen Ihr öffentlicher Schlüssel in /etc/dropbear/authorized_keys anstelle von /root/.ssh/authorized_keys.

Lange Antwort:

Der GitHub Das Repo, auf das Sie verweisen, ist das vom Dropbear-Autor gepflegte Repo. Es besagt, dass ~/.ssh/authorized_keys funktioniert, und laut GitHub ist dies mindestens seit 14 Jahren der Fall. Schauen Sie sich den Code in svr-authpubkey.c fügt dem „pw_dir“ /.ssh/authorized_keys hinzu.

I jedoch hatte das gleiche Problem wie Sie und ich stellte fest, dass die in OpenWrt 18.06.1 bereitgestellte Binärdatei tatsächlich /etc/dropbear/authorized_keys öffnet. Die Verwendung dieser Datei funktioniert für mich

Dieses Verhalten ist in den OpenWrt-Dokumenten dokumentiert.

Wie kommt es?

Da der obige Code diesen Dateinamen nicht alleine erzeugen kann (die .ssh fehlt) und Es gibt nirgendwo einen .ssh Symlink. Ich habe strings für die Binärdatei ausgeführt. Dies zeigte, dass /etc/dropbear/authorized_keys explizit erwähnt wird, kurz vor dem %s/.ssh/authorized_keys, das vom GitHub-Code erwartet werden kann. Ich schließe daraus, dass die OpenWrt-Binärdatei nicht aus denselben Quellen kompiliert wurde … und tatsächlich patcht OpenWrt den Upstream-Code mit diesem Patch . Die verwendete Datei wird in /etc/dropbear/authorized_keys geändert, wenn (und nur wenn) der Zielbenutzer root ist.

Da Sie opkg, ich stelle mir vor, Sie verwenden auch OpenWrt und das ist Ihr Problem. Ich habe Ihrer Frage ein OpenWrt-Tag hinzugefügt.

Antwort

authorized_keys ist eine Datei, kein Verzeichnis.

Eine Beispieldatei für autorisierte Schlüssel:

 # 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

Auch die .ssh/ und alle darin enthaltenen Dateien dürfen nur dem Benutzer gehören und von diesem gelesen werden, in diesem Fall root.

Kommentare

  • Ich habe das gerade behoben, aber immer noch kein Glück 🙁 (siehe aktualisierte Frage).

Antwort

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 

Kommentare

  • Ich habe es geschafft, den privaten Schlüssel zu konvertieren, aber immer noch kein Glück 🙁 (siehe aktualisierte Frage).

Antwort

Sie müssen den SSH-Schlüssel mit dem Dropbearkey-Tool erstellen. 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

Starten Sie dann den dropbear-Daemon neu. Versuchen Sie dann, eine Verbindung herzustellen.

Antwort

Bei einigen Zeigern, die Ihnen helfen können, mithilfe von PKI mit Dropbear eine Verbindung herzustellen, wurde ein Container getestet, der auf Alpine Linux 3.12-Paketen basiert und über einen OpenSSH-Client eine Verbindung herstellt.

  1. Der Benutzer benötigt eine Shell.
  2. Der Benutzer nicht benötigen ein Anmeldekennwort.
  3. Der Benutzer „s ~ darf nicht Gruppe / Welt beschreibbar sein (dh chmod 755 zumindest; Sie sollten 700 für Home-Verzeichnisse verwenden.
  4. Der Benutzer id ~/.ssh und ~/.ssh/authorized_keys darf nur für den Eigentümer zugänglich sein (z. B. 700 im Verzeichnis und 600 in der Datei).
  5. Dort muss sei ein beschreibbares /tmp -Verzeichnis
  6. Die authorized_keys -Einträge haben dasselbe Format wie verwendet von OpenSSH.

Ich mache Container mit von Kirschen gepflückten Dateien aus alpinen Paketen; Ich habe ein ~ 2 MB großes Image, in das ich ssh kann, solange alle oben genannten Anforderungen erfüllt sind.

Antwort

I. Ich bin gerade auf diese Frage gestoßen, als ich nach Gründen gesucht habe, warum die Verbindung über Dropbear zu meinem Server plötzlich nicht mehr funktioniert (funktioniert seit Monaten, wird aber nur gelegentlich alle paar Wochen verwendet).

die Lösung / Erklärung i Schließlich wurde in der Nachricht debug1: send_pubkey_test: no mutual signature algorithm mit erhöhter Ausführlichkeit beim SSH-Verbindungsversuch meines Clients gefunden, was mich zu einem Bitbucket-Fehlerbehebungsartikel a führte >.

In diesem Artikel wird erwähnt. Der RSA-Algorithmus wird auf Betriebssystemen und SSH-Clients aufgrund verschiedener Sicherheitslücken […] als Ursache schnell veraltet und als mögliche Problemumgehungen aufgeführt entweder:

  • Hinzufügen von PubkeyAcceptedKeyTypes +ssh-rsa zur cfg-Datei des Clients (verwenden Sie dies nur als temporäre Problemumgehung wie es Pote ist normalerweise unsicher!)

  • Verwenden Sie den ECDSA- oder ED25519-Algorithmus / die Schlüssel. Jetzt mit der auf meinem System vorhandenen Dropbear-Version konnte ich nur ECDSA verwenden, da ED25519 mir unbekannte Algorithmusfehler auf der Dropbears-Seite gab.

Ich hoffe, dies hilft jemandem, über diese Frage zu stolpern, da ich es sogar schwer gemacht habe. Es ist wahrscheinlich keine Lösung für die ursprüngliche Frage, bitte. vergib.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.