wohin mit privatem Schlüssel eines anderen RasPi

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    ich möchte von RasPi A aus mittels wget auf Daten von RasPi B zugreifen.

    Dazu habe ich auf RasPi B ein Schlüsselpaar generiert und den öffentlichen Schlüssel in die Datei

    Code
    /home/pi/.ssh/authorized_keys

    gelegt.

    Das Paar funktioniert mit Putty, nachdem ich eine Kopie des privaten Schlüssels entsprechend bearbeitet habe.

    Danach habe ich die unbearbeitete Kopie auf RasPi A gelegt. Aber ich finde keine Anleitung, wo ich ihn einbinden soll, dass der RasPi A automatisch auf RasPi B zugreifen kann.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Gib mal man ssh ein und dann / private key. Mit n (next) dann durch die manpage. Dort sind diverse Orte für die Schlüssel gelistet. Das müsste eigentlich helfen.

  • Vermutlich meint er rsync. Dabei ist es niemals nötig, einen privaten Schlüssen von dem Rechner wegzubewegen, wo er generiert wurde. Dafür ist eigentlich (immer) der öffentliche Schlüssel gedacht.

  • Der private Schlüssel bleibt dort, wo er ist.

    Der hat auf einem anderen System oder im Zugriffsbereich eines anderen Benutzers auf dem gleichen System NICHTS zu suchen.

    Der öffentliche Schlüssel wird in die Datei "authorized_keys" das entfernten Benutzers auf dem entfernten System kopierte, auf das und mit dem man sich verbinden will.

    Computer ..... grrrrrr

  • Entschuldigung, dass ich mit Infos knausrig war.

    Ich habe einen RasPi (bei mir RasPi B), auf dem seit Jahren verschiedenste Temperaturen gemessen und in einer RRDtool Datenbank geloggt werden.

    Als neues Projekt überlege ich, meine vorhandene Rolladensteuerung auf einem anderen RasPi (A) mittels ioBroker zu ersetzen. Ich habe in allen interessanten Räumen Dallas Sensoren an (B) angeschlossen und möchte mit (A) auf diese Infrastruktur zurück greifen. Das ist das große Ziel.

    Entweder, ich hole mir alle 15min die jeweilige Datei /sys/devices/w1_bus_master1/28-0000060a858a/w1_slave von (B) auf (A) rüber oder greife nach Möglichkeit mittels des Moduls Parser direkt den Temperaturwert ab.

    Aber dazu muss RasPi (A) erst mal auf die Dateiauf (B) zugreifen dürfen. Das ist mein Anliegen.

    Ich (Nichtnetzwerker) dachte, wenn man ein Schlüsselpaar ohne Passphrase erzeugt, kann damit (A) automatisiert auf (B) zugreifen. Alles spielt sich im heimischen LAN ab.

    Aber vielleicht gibt es für eine solche Aufgabe auch einen besseren Lösungsweg.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Alles spielt sich im heimischen LAN ab.

    Im LAN könntest Du auch telnet oder ein (nicht verschlüsseltes) vpn benutzen. Z. B.:

    Code
    apt-cache policy telnetd-ssl vtun

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo, ich bin verwirrt :(

    Ich habe mich an die Anleitung auf https://www.kollino.de/raspberrypi/ss…binden-via-ssh/

    gehalten.

    Mittels

    Code
    ssh-keygen -t rsa -b 2048 -C "xyz"

    habe ich das Schlüsselpaar "id_rsa" und "id_rsa.pub" erzeugt. Der Inhalt der "id_rsa.pub" wurde in die Datei "authorized_keys" kopiert. Und die Datei "id_rsa" wurde auf den RasPi (A) kopiert, der später auf (B) zugreifen soll.

    Ist das jetzt falsch rum?

    Ich bin verwirrt, weil wenn ich die "id_rsa" mit puttyGen bearbeite und auf meinen Windows-PC lege, kann ich damit mit KiTTy auf den RasPi (B) zugreifen. Ich dachte, ähnlich funktioniert das auch mit dem Zugriff von RasPi (A) aus.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Mittels

    Code
    ssh-keygen -t rsa -b 2048 -C "xyz"

    habe ich das Schlüsselpaar "id_rsa" und "id_rsa.pub" erzeugt. Der Inhalt der "id_rsa.pub" wurde in die Datei "authorized_keys" kopiert. Und die Datei "id_rsa" wurde auf den RasPi (A) kopiert, der später auf (B) zugreifen soll.

    Ist das jetzt falsch rum?

    Nein, da ist nix falsch rum... das ist richtig so. id_rsa.pub ist der öffentliche Public-Key für den Remote-Host. Diese Datei wird kopiert oder umbenannt nach "authorized_keys"... wobei das nicht zwingend notwendig ist. Du kannst id_rsa.pub stattdessen auch in der sshd.conf direkt verwenden. Das ist derzeit nur per default auf "authorized_keys" gesetzt, wobei hier die Betonung auf "keys", also Mehrzahl liegt. Das heisst, man kann in "authorized_keys" auch mehrere Pub-Keys eintragen, wenn man unterschiedliche Clients mit jeweils eigenem Private-Key hat.

    Die Datei "id_rsa ist also der private Schlüssel (ein Static-Key), mit dem sich ein Client quasi authentifiziert und die schließlich zur Entschlüsselung herangezogen wird. Das ist so ein bisschen irritierend, wenn doch der öffentliche Schlüssel auf dem eigentlich zu schützenden privaten Server liegt. Der Hintergrund ist dabei ganz einfach, jeder, der den öffentlichen Schlüssel (Pubkey) besitzt, kann die Daten verschlüsseln. Aber nur der, der den Private-Key hat, kann die Daten wieder entschlüsseln.... ist so'n bisschen verdrehte Logik, aber letztendlich genial.

    Ich habs bei mir jedoch einfach gemacht, auf dem Server liegt nur ein Pubkey, einfach versymlinkt auf die authorizedkeys, die Clients verwenden alle den gleichen Private-Key. Die Zugänge sind sowieso nur Lan-Intern möglich. Wenn man jedoch die Möglichkeit haben will, einen bestimmten Client auf dem Server auszusperren, muss für jeden Client eine eigenes Key-Paar erzeugt werden und dann geht s nur über die "authorized_keys". Ich brauch das allerdings nicht.

    Das hier ist hilfreich: https://www.ssh.com/ssh/public-key-authentication

    HTH

  • Wieviele Rechner sind denn im Spiel? Wenn Du den öffentlichen Schlüssel auf den Rechner (B) in die authorizes Keys kopierst und den privaten auf den Rechner (A), auf welchem Rechner wurde denn das Schluesselpaar erzeugt?

    Eigentlich erzeigt man das Schluesselpaar auf (A) und laesst den privaten Schluessel da liegen und kopiert ihn niemals auf einen anderen Rechner. Dann waeren nur zwei Rechner im Spiel. Normalerweise erzeugt man dann auf (B) auch ein Schluesselpaar, laesst alles som wie es ssh-keygen angelegt hat.

    Dann funktioniert die Kommunikation/Filetransfer von B --> A genau dann, wenn auf A der öffentliche Schluessel von B im authorized-keys steht.

  • ..., auf welchem Rechner wurde denn das Schluesselpaar erzeugt?

    Auf dem Rechner (A) (d. h. auf dem SSH-Client).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Was vollkommen unerheblich ist....

    Wie meinst Du das? Es ist doch der SSH-Client, der sich am Server anmelden/authentifizieren will, warum soll er dann nicht auch das Schlüsselpaar generieren?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • weil es vollkommen egal ist, auf welchem Rechner ein Key erstellt wurde, solange die keys anschließend an die richtigen Stellen kopiert wurden.

    Und welcher key wohin gehört wurde dem TE nun mehrfach erklärt.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • weil es vollkommen egal ist, auf welchem Rechner ein Key erstellt wurde, solange die keys anschließend an die richtigen Stellen kopiert wurden.

    Ja, aber durch solche Aussagen entstehen Verwirrungen und es werden solche Fragen, wie in diesem Thread gestellt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Wie meinst Du das? Es ist doch der SSH-Client, der sich am Server anmelden/authentifizieren will, warum soll er dann nicht auch das Schlüsselpaar generieren?

    Weil man genausogut sagen könnte "Es ist doch der Server, der wichtig ist und der deswegen die Anmeldung als höchstwertige Instanz erlauben soll, also muss der auch das Key-Paar erstellen". 

    llutz hat also auch meiner Meinung nach Recht... es geht imho nicht darum, sich an eine unnütze Regel zu halten, sondern darum, das System zu verstehen. Stell Dir vor, jemand käme auf die Idee und würde sagen "Man dürfe als Fahrer nur auf der linken Seite in sein Auto einsteigen"... ich schätze mal, da würden die Engländer schön blöd gucken, wenn sie das so machen müssten... oder der deutsche, der sich in GB einen Leihwagen nimmt. Wenn man hingegen die Systematik verstanden hat, wirds im Anschluß dann auch viel einfacher.

    jm2c

  • Weil man genausogut sagen könnte "Es ist doch der Server, der wichtig ist und der deswegen die Anmeldung als höchstwertige Instanz erlauben soll, also muss der auch das Key-Paar erstellen".

    Und genau so gut kann man sagen, dass wenn es der Server ist der die Anmeldung erlauben soll, der Client etwas tun muss damit der Server ihn authentifizieren kann. Und das tut der Client, indem er dem Server den von ihm (als Client) generierten Pubkey zur Verfügung stellt. Auch wenn der Server den Pubkey bekommen hat bzw. kennt, kann er noch immer entscheiden, ob die Anmeldung akzeptiert wird oder nicht akzeptiert wird.

    BTW: Soll der Server etwa auch das Passwort zum Schutz des private Key, für den Client festlegen?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • BTW: Soll der Server etwa auch das Passwort zum Schutz des private Key, für den Client festlegen?

    Ich bin hierbei der Meinung, dass das eigentlich zu trivial ist, um das langatmig zu debattieren. Ich halte beide Wege nicht für falsch... und ich selber gehe sogar einen dritten Weg, indem ich benötige Keys auf einer Key-Signing-Machine erstelle und sie dann explizit auf Zielgeräte verteile.

  • Oje, da hab ich was angerichtet ;)

    Auf (B) liegen die interessierenden Daten, auf die (A) zugreifen will.

    Auf (B) habe ich das Schlüsselpaar generiert. rpi444hatte das falsch vermutet. Ist aber eigentlich auch egal, wenn ich das richtig verstanden habe.

    Auch alle Fälle liegt der öffentliche Schlüssel "id_rsa.pub" in der authorized_key von (B)

    Der private Schlüssel "id_rsa" liegt jetzt auf (A). Und da komme ich zum Ausgang meiner eigentlichen Frage.

    Wo kann ich den einbinden / ablegen, damit (A) auf (B) zugreifen kann?

    Ich hoffe, dass ich den Parser auf (A) dann so konfigurieren kann:

    http:/ /die_IP_von_B/weg_zu_Datei

    Aber erst mal muss geklärt werden, dass (A) auf (B) zugreifen kann.

    PS. Danke ThomasL für die Erläuterung, warum der private Schlüssel veröffentlicht wird und der öffentliche Schlüssel "zuHause" bleiben soll. Ich glaube, jetzt kann ich es mir merken.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!