Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howtos:ssh [2017/09/19 10:08] – [Schritt 2: geht das auch ohne Passwort] morquai
+++ howtos:ssh [2022/02/18 08:09] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 31: / Zeile 31: @@
 wird man freundlich nach dem Passwort gefragt.
 ==== Schritt 2: geht das auch ohne Passwort ====
-Natürlich muss der Benutzer sich ausweisen, dafür ist aber nicht unbedingt ein Passwort erforderlich. Ein Zertifikat (also eine Art Ausweis) reicht auch aus, muss aber erstmal angelegt werden. Ich empfehle DRINGEND den Schlüssel mit einem Passwort ("passphrase") geschützt wird. Eine Benutzung des Zertifikats ist nur möglich, wenn man das Passwort eingegeben hat. Die Generierung eines solchen Zertifikats geschieht mit dem Befehl:
+Natürlich muss der Benutzer sich ausweisen, dafür ist aber nicht unbedingt ein Passwort erforderlich. Ein SSH Key (eine Art Ausweis) reicht auch aus, muss aber erstmal angelegt werden. Ich empfehle DRINGEND den Schlüssel mit einem Passwort ("passphrase") geschützt wird. Eine Benutzung des SSH Keys ist dann nur möglich, wenn man das Passwort eingegeben hat. Die Generierung eines solchen SSH Keys geschieht mit dem Befehl:
   ssh-keygen -t rsa -b 2048 -f <dateiname>
 Lässt man "-f <dateiname>" weg, wird eine Datei Namens "id_rsa" angelegt.
@@ Zeile 54: / Zeile 54: @@
     |     .o..        |
     +----[SHA256]-----+
-Zur Sicherheit besteht der Schlüssel aus zwie Teilen, einem öffentlichen, der zur Verschlüsselung dient, und einem privaten Teil, der der Entschlüsselung dient. Der obige Befehl hat zwei Dateien angelegt, "/tmp/rsakey" (der private Teil) und /tmp/rsakey.pub (der öffentliche Teil). \\
+Zur Sicherheit besteht der Schlüssel aus zwie Teilen, einem öffentlichen, der zur Verschlüsselung dient, und einem privaten Teil, der der Entschlüsselung dient. Der obige Befehl hat zwei Dateien angelegt, "/tmp/rsakey" (der private Teil) und /tmp/rsakey.pub (der öffentliche Teil). Die beiden Teile werden Public Key und Private Key genannt. \\
-Um sich zu authentifizieren muss auf dem Server der öffentliche Teil und auf dem Client der private Teil "eingetragen" sein. Auf dem Client gehört die Datei nach ~/.ssh/id_rsa. Die Datei darf nur für den Benutzer lesbar sein, genau wie das ~/.ssh Verzeichnis auch. Der öffentliche Schlüssel darf von jedermann (daher öffentlich) gelesen werden.
+Um sich zu authentifizieren muss auf dem Server der Public Key und auf dem Client der Private Key "eingetragen" sein. Auf dem Client gehört die Datei nach ~/.ssh/id_rsa. Die Datei darf nur für den Benutzer lesbar sein, genau wie das ~/.ssh Verzeichnis auch. Der Public Key darf von jedermann (daher öffentlich) gelesen werden.
   mv /tmp/rsakey* ~/.ssh
   ls -ld / /home/ /home/user/ /home/user/.ssh /home/user/.ssh/rsa*
@@ Zeile 64: / Zeile 64: @@
     -rw-------    1 user     gruppe         1679 Aug 30 2016  /home/user/.ssh/rsakey
     -rw-r--r--    1 user     gruppe         1679 Aug 30 2016  /home/user/.ssh/rsakey.pub
-Damit haben wir auf der Client Seite erstmal alles erledigt und können nun der öffentliche Teil des Zertifikates auf den Server packen. Die einfachste Methde ist der folgende Befehl
+Damit haben wir auf der Client Seite erstmal alles erledigt und können nun der Public Key auf den Server packen. Die einfachste Methde ist der folgende (siehe unsere .ssh/config) Befehl
-  ssh-copy-id -i /home/user/.ssh/rsakey.pub
+  ssh-copy-id -i /home/user/.ssh/rsakey.pub server.example.com
+Dabei wird, letztmalig, das Passwort des Benutzers "user" auf dem Server abgefragt. Jetzt passen wir noch die .ssh/config an, weil unsere Datei nicht "id_rsa" (einer der Default Werte) heißt.
+  Host server1
+      HostName        server1.example.com
+      Port            921
+      User            username
+      DynamicForward  3129
+      LocalForward    1234 server2:80
+      LocalForward    3210 server:3128
+      IdentityFile    ~/.ssh/rsakey
+Damit haben wir die Passwort Abrage des Servers deaktiviert und müssen nun die Passphrase des SSH Keys eingeben. Damit haben wir aber leider nur die eine Passwortabfrage durch eine andere ersetzt.
+==== Schritt 3: Eine Passwortabfrage pro Tag ====
+Die openssh Entwickler sind anscheinend ziemlich faule Gesellen. Im Paket openssh befindet sich auch ein Agent, der die Aufgabe hat sich die SSH Keys im RAM zu merken und bei Bedarf zur Verfügung zu stellen. Die Ablage im RAM erfolgt natürlich nach allen Regeln der Sicherheit. Unter Linux (auch Cygwin) wird der Agent folgendermaßen benutzt:
+  ssh-agent
+    SSH_AUTH_SOCK=/tmp/ssh-YYMhp1JPZkWu/agent.25166028; export SSH_AUTH_SOCK;
+    SSH_AGENT_PID=10682402; export SSH_AGENT_PID;
+    echo Agent pid 10682402;
+Damit ist der Agent gestartet und die Befehle, die eine Benutzung ermöglichen, werden ausgegeben. Der Agent bleibt bis zum nächsten Reboot aktiv, also können wir die Befehle in eine Datei schreiben und dann in der aktuellen Shell ausführen. Nennen wir die Datei ~/ssh-agent-vars.sh und füllen sie mit Inhalt. Anschliessend führen wir sie in der aktuellen Shell aus.
+  SSH_AUTH_SOCK=/tmp/ssh-YYMhp1JPZkWu/agent.25166028; export SSH_AUTH_SOCK;
+  SSH_AGENT_PID=10682402; export SSH_AGENT_PID;
+  echo Agent pid 10682402;
+Und nun die Ausführung, der Punkt am Anfang signalisiert, das das Script in der aktuellen Shell ausgeführt wird:
+  . ~/ssh-agent-vars.sh
+Nachdem der Agent gestartet wurde und die Benutzung eingerichtet ist, müssen wir nun dem Agenten den Private Key zur Verfügung stellen
+  ssh-add ~/.ssh/rsakey
+Der Agent fordert uns auf die Passphrase einzugeben und kann nun die Aufgabe, den Private Key bei Bedarf zur Verfügung zu stellen, übernehmen. Die Anmeldung kann nun ohne jede Passwort Abfrage gemacht werden.
+  ssh server.example.com
+Geschafft. die Passworteingabe ist ab nun nicht mehr erforderlich. Wir müssen nur nach einen Reboot daran denken den Agenten erneut zu starten und die ausgegebenen Befehle in die Datei ~/ssh-agent-vars.sh zu schreiben. Auch der Private Key muss einmalig wieder geladen werden. \\
+Wenn wir eine neue Shell starten muss natürlich auch hier die ~/ssh-agent-vars.sh in der aktuellen Shell ausgeführt werden. Man kann dies in der ~/.bashrc hinterlegen.
+**Hinweis: wer PuTTY und openssh unter Cygwin parallel benutzt sollte sich die Benutzung von PAGEANT (PuTTY) und die Zusammenarbeit mit ssh-pageant (openssh unter Cygwin) anschauen. [[https://mplx.eu/tech/ssh-key-agents-linux-windows-cygwin|Hier ein Link zum Einstieg]] **
+==== Schritt 4: Den SSH Key auch von server.example.com aus benutzen ====
+Oft findet man eine ganze Serverlandschaft, auf der man sich anmelden kann. Wenn man erst einmal den öffentlichen Teil des SSH Keys auf allen Servern hinterlegt hat, kann man sich vom Client aus auf jedem Server ohne weiteres Passwort anmelden. Wenn man nun aber von einem zum anderen Server springen will, wird man wieder nach dem Passwort gefragt, denn der Agent läuft ja nur auf unserem Client. Eine unverzeihliche Sünde ist es nun den Private Key auf die Server in der Domain example.com zu kopieren. \\
+**Ein Private Key darf den Client NIEMALS verlassen.**\\
+Natürlich hat openssh hier eine Lösung parat, denn der ssh-agent kann noch mehr. Der Private Key kann in einer ganze Kette aufeinander folgende SSH Sessions benutzt werden. Der Schalter "-A" sorgt dafür, das der Private Key durch alle ssh Instanzen weiter gereicht wird:
+  client: ssh -A server.example.com
+  server.example.com: ssh server2.example.com
+Auch der auf "server.example.com" abgesetzte ssh Befehl erforder kein Passwort, der ssh-agent befriedigt die Anfrage des Private Keys problemlos, sofern mittels "ssh-copy-id" der öffentliche Schlüssel auf server2.example.com bereitgestellt wurde. Die Entsprechung in der .ssh/config lautet
+  host *
+    ForwardAgent yes
+Und wieder etwas gelernt, man kann für die Definitionen in der .ssh/config Wildcards ("*" und "?") verwenden. Aber Achtung: Es werden alle Definitionen in allen Gruppen angewendet, auf die die Wildcards zutreffen.
+==== Schritt 5: nicht öffentliche Services lokal nutzen ====
+Was ist damit gemeint? Auf server.example.com läuft ein WebServer, der aus dem Internet nicht erreichbar ist, den wir aber auf unserem Client ansprechen wollen. Ein WebServer wird auf Port 80 (unverschlüsselt) oder 443 (verschlüsselt) angesprochen. Dieser Port wird aber von einer Firewall geblockt. Die Lösung lautet: Port Forwarding, was mit openssh kein Problem ist.
+  ssh -L 1234:localhost:443 server.example.com
+Was will uns der Dichter damit sagen? Die SSH Session wird überredet, auf dem Client den Port 1234 zu öffnen und jeglichen Traffic auf diesem Port an den Port 443 auf server.example.com ("localhost", aus dessen Sicht) weiterzuleiten. Im Browser reicht nun die Eingabe von
+  https://localhost:1234
+um den Webserver zu erreichen. \\
+Der Eintrag in der .ssh/config lautet
+  LocalForward    1234 localhost:443
+Verwirrend? Das liegt an der Doppelnutzung von "localhost". Dieser Rechnername "localhost" bezieht sich immer auf den Rechner, auf dem er interpretiert wird. In dem SSH Command wird "localhost" aus Sicht von "server.example.com" interpretiert, im Browser, der ja auf dem Client läuft, wird es natürlich als "Client" interpretiert. \\
+Aber in der Serverlandschaft hinter server.example.com laufen mehrere WebServer, für jeden einzelnen ein Port Forwarding einzurichten ist wohl ein wenig aufwendig. Aber natürlich hat openssh alles zur Hand. Wir richten uns einfach einen Socks Proxy ein, den wir im Browser eintragen und schon stehen alle WebServer mit einem einzigen Eintrag im SSH Command zur Verfügung.
+  ssh -D 3128 server.example.com
+Wie immer was es das schon. Nur noch im Browse die Proxy Einstellungen einstellen und die alle Webserver, die server.example.com erreichen kann, stehen zur Verfügung. Unschön ist das Verhalten, wenn man Namen statt IP-Adressen benutzt. Normalerweise sprechen wir Webseiten nach dem Schema <hostname>.<domain> (z.B. www.google.de) an. Der DNS nimmt uns die Arbeit ab, die Namen in IP Adressen zu übersetzen. Da das DNS Protokoll auf UDP basiert, ssh aber nur TCP zur Verfügung stellt, müssen die Namen entweder im öffentlichen DNS auflösbar sein oder in der lokalen Hosts Datei gepflegt sein. \\
+Ach ja, wie sieht denn der Eintrag in der .ssh/config aus?
+  DynamicForward  3128
+==== Fazit: Beispiel einer .ssh/config ====
+  # Ersteinmal die Einstellungen, die für alle Rechner gelten sollen
+  Host *
+    # ssh-agent soll die private Keys zur Verfügung stellen
+    ForwardAgent yes
+    # Bei Ungereimtheiten mit Host Keys wollen wir gefragt werden
+    StrictHostKeyChecking ask
+    # den Wert mancher Variablen wollen wir mitschleppen, hier diejenigen,
+    # die sich auf die Sprachumgebung beziehen
+    SendEnv LANG LC_*
+    # Wo steht nochmal unser Private Key?
+    IdentityFile    ~/.ssh/rsakey
+  # Nun zu Server.example.com
+  # Da die für alle Hosts geltenden Einstellungen hier ebenfalls gültig sind, brauchen wir nur
+  # anzugeben, was sich ändert oder was hinzukommt
+  Host Server.example.com
+    # wie lautet unser Benutzename
+    User user
+    # unser netter Socks 5 Proxy
+    DynamicForward  3128
+    # Der lokale Forward um den Webserver auf server.example.com zu erreichen
+    # ist ja eigentlich unnötig, denn wir haben ja einen Dynamic Forward
+    LocalForward    1234 localhost:443
+  # Hier mal ein Beispiel für mehrere Server
+  Host *.example.com
+    User user
+Die Grundlagen sind gelegt und die meisten Fragen beantwortet. Weitergehende HowTo's zu SSH folgen....

OnkelHartwig Zuhause

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge