SSH: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
K (Korrekturen)
 
Zeile 45: Zeile 45:
== Authentifizierungsmethode ==
== Authentifizierungsmethode ==


Normalerweise möchte man gerne mit Keyfile aithentifizieren. Der Key wird entweder mit der Option <code>-i [keyfile]</code> angegeben oder automatisch durch ausprobieren ermittelt.
Normalerweise möchte man sich gerne mit Keyfile authentifizieren. Der Key wird entweder mit der Option <code>-i [keyfile]</code> angegeben oder automatisch durch ausprobieren ermittelt.


Problem 1: Wenn Keyfiles ausprobiert werden, wird ab einer durch den Server festgelegten Anzahl an Versuchen abgebrochen. Lösung 1: die Option <code>-i</code>
;Problem 1: Wenn Keyfiles ausprobiert werden, wird ab einer durch den Server festgelegten Anzahl (oft 3) an Versuchen abgebrochen.
:Lösung 1a: die Option <code>-i</code> im das Keyfile zu spezifizieren
:Lösung 1b: Der Abbruch findet auch statt wenn <code>.ssh/config</code> das Keyfile in <code>~/.ssh/</code> definiert; dazu hilft ein Unterverzeichnis, z.B. <code>~/.ssh/keys/</code> in dem die Keyfiles abgelegt werden.


Problem 2: Wenn man keinen Key auf dem Server hat wird dann nicht nach Passwort gefragt. Lösung 2: Option <code>-o PreferredAuthentications="password"</code>
<pre>
# [~/.ssh/config]
# few examples
 
Host cider
PubkeyAuthentication no
User k-ot
 
Host git.c3d2.de
IdentityFile ~/.ssh/keys/c3d2-git
 
Host gitlab.com
HostName gitlab.com
IdentityFile ~/.ssh/keys/gitlab.com
RSAAuthentication yes
PreferredAuthentications publickey
IdentitiesOnly yes
User GitLabUserhandle
 
Host ledbeere
User pi
PreferredAuthentications password
PasswordAuthentication yes
 
Host ledbeere
User pi
PreferredAuthentications password
PasswordAuthentication yes
 
</pre>
 
;Problem 2: Wenn man keinen Key auf dem Server hat wird dann nicht nach Passwort gefragt.
:Lösung 2: Option <code>-o PubkeyAuthentication=no</code>; weitere Optionen stehen in <code>man ssh</code>

Aktuelle Version vom 3. März 2017, 07:54 Uhr

SSH-Verbindungen recyceln

In aktuellen SSH-Versionen (ab 4.0) gibt es die Möglichkeit, SSH-Verbindungen wiederzubenutzen: Hat man bereits eine Shell auf einem entfernten Rechner offen und will dann z.B. scp benutzen, um etwas dorthin zu kopieren, wird die gleiche Verbindung benutzt. Dadurch muss man sich nicht noch einmal an dem anderen Rechner authentifizieren, was einiges an Zeit spart. Damit alle zukünftigen SSH-Sitzungen davon profitieren, ein Verzeichnis ~/.ssh/sockets anlegen und dann Folgendes in die ~/.ssh/config schreiben:

Host *
  ControlPath ~/.ssh/sockets/%r@%h:%p
  ControlMaster auto

Leider löscht ssh Socket-Leichen nicht automatisch, sollte einmal ein Prozess sterben, und weigert sich dann, eine weitere Verbindung zum entsprechenden Host aufzubauen. Eine entsprechende Fehlermeldung sieht z.B. so aus:

Control socket connect(/home/frank/.ssh/sockets/toidinamai@172.22.99.2:22): Connection refused
ControlSocket /home/frank/.ssh/sockets/toidinamai@172.22.99.2:22 already exists

In diesem Fall einfach die störende Socket-Datei löschen. Sollte es aus irgend einem Grund nötig sein, eine separate Sitzung aufzubauen, kann man das mit

ssh -o "ControlPath none" user@host

tun.

Achtung: Die erste aufgebaute Sitzung fungiert als Master für alle weiteren. Wird sie geschlossen, sterben auch alle anderen Verbindungen zum gleichen Host.

SSH über Tor Hidden Services / torify SSH

  • Tor starten (Annahme hier: läuft auf 9050/tcp)
  • Folgenden Abschnitt in die ~/.ssh/config packen:
Host *.onion 
  ProxyCommand socat STDIO SOCKS4A:localhost:%h:%p,socksport=9050
  • Um zu aromaster zu ssh'en:
ssh hacker@6kgmplpcyjpesalg.onion

Tor ist leider recht lahm und auch nicht jeder Verbindungsversuch ist erfolgreich.

SSH ins ChaosVPN

Dazu wird ein öffentlich erreichbarer "Gateway" benötigt. In diesem Beispiel soll das example.net sein, dort muss netcat als nc installiert sein.

Folgende Zeilen gehören in die ~/.ssh/config:

Host *.diac24
  ProxyCommand ssh user@example.net "nc $(echo %h|sed -e 's/\.diac24$//' ) %p"

Um nun auf aromaster zu verbinden:

ssh user@172.22.99.2.diac24

Authentifizierungsmethode

Normalerweise möchte man sich gerne mit Keyfile authentifizieren. Der Key wird entweder mit der Option -i [keyfile] angegeben oder automatisch durch ausprobieren ermittelt.

Problem 1
Wenn Keyfiles ausprobiert werden, wird ab einer durch den Server festgelegten Anzahl (oft 3) an Versuchen abgebrochen.
Lösung 1a: die Option -i im das Keyfile zu spezifizieren
Lösung 1b: Der Abbruch findet auch statt wenn .ssh/config das Keyfile in ~/.ssh/ definiert; dazu hilft ein Unterverzeichnis, z.B. ~/.ssh/keys/ in dem die Keyfiles abgelegt werden.
# [~/.ssh/config]
# few examples

Host cider
	PubkeyAuthentication no
	User k-ot

Host git.c3d2.de
	IdentityFile ~/.ssh/keys/c3d2-git

Host gitlab.com
	HostName gitlab.com
	IdentityFile ~/.ssh/keys/gitlab.com
	RSAAuthentication yes
	PreferredAuthentications publickey
	IdentitiesOnly yes
	User GitLabUserhandle

Host ledbeere
	User pi
	PreferredAuthentications password
	PasswordAuthentication yes

Host ledbeere
	User pi
	PreferredAuthentications password
	PasswordAuthentication yes

Problem 2
Wenn man keinen Key auf dem Server hat wird dann nicht nach Passwort gefragt.
Lösung 2: Option -o PubkeyAuthentication=no; weitere Optionen stehen in man ssh