Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howtos:ssh [2017/09/20 12:35] – [Schritt 5: nicht öffentliche Services lokal nutzen] 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 75: / Zeile 75: @@
       LocalForward    3210 server:3128
       IdentityFile    ~/.ssh/rsakey
-Damit haben wir die Passwort Abrage des Servers deaktiviert und müssen nun die Passphrase des Zertifikats eingeben. Damit haben wir aber leider nur die eine Passwortabfrage durch eine andere ersetzt.
+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 Zertifikate 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:
+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;
@@ Zeile 97: / Zeile 97: @@
 **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: Das Zertifikat auch von server.example.com aus benutzen ====
+==== 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 Zertifikats 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. \\
+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:
@@ Zeile 127: / Zeile 127: @@
+==== 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