Ssh: Unterschied zwischen den Versionen

Aus CodicaTipps
Zur Navigation springen Zur Suche springen
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 110: Zeile 110:
 
als Parameter für SSH wird das [http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html Host-Key-Checking von SSH umgangen], '''Risiko: Das ermöglicht Man-in-the-Middle-Attacken.'''
 
als Parameter für SSH wird das [http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html Host-Key-Checking von SSH umgangen], '''Risiko: Das ermöglicht Man-in-the-Middle-Attacken.'''
  
−
Man kann dies für spezifische Hosts auch dauerhaft in der (notfalls anzulegenden) Datei <code>/home/USER/.shh/config</code> festlegen<ref>Siehe http://linuxcommando.blogspot.de/2008/10/how-to-disable-ssh-host-key-checking.html</code>:
+
Man kann dies für spezifische Hosts auch dauerhaft in der (notfalls anzulegenden) Datei <code>/home/USER/.shh/config</code> festlegen<ref>Siehe http://linuxcommando.blogspot.de/2008/10/how-to-disable-ssh-host-key-checking.html</ref>:
  
 
   Host 192.168.0.*
 
   Host 192.168.0.*
Zeile 123: Zeile 123:
  
 
Siehe auch diese [http://www.symantec.com/connect/articles/ssh-host-key-protection Erläuterung des Host-Key-Checkings].
 
Siehe auch diese [http://www.symantec.com/connect/articles/ssh-host-key-protection Erläuterung des Host-Key-Checkings].
 +
 +
== SSH mit anderem Port ==
 +
 +
Wenn man auf einen SSH-Server zugreifen will, der nicht auf dem Standardport läuft, haben die verschiedenen Client-Programme unterschiedliche Arten, diesen Port zu akzeptieren:
 +
* mit dem Kommandozeilenparameter <code>--port</code> oder <code>-p</code>
 +
* in der URL <code>SERVERNAME:PORT</code>
 +
* über <code>/etc/ssh/config</code> oder <code>~/.ssh/config</code>
 +
  Host XY
 +
    HostName SERVERNAME
 +
    Port PORT
 +
 +
== dauerhafte SSH Verbindungen ==
 +
 +
Will man ein SSH-Terminal gelegentlich wieder aufrufen, hilft dafür das Paket <code>screen</code>.
 +
 +
Dieses stellt ein virtuelles Terminal dar, das auf mehreren Clients angezeigt werden kann. Falls dabei die falsche <code>$TERM</code>-Variable angezeigt wird, kann man dies richtigstellen:
 +
  export TERM=xterm
 +
  
 
== SSH hinter Firewall ==
 
== SSH hinter Firewall ==
Zeile 134: Zeile 152:
 
Dabei bitte Passwort des entfernten Rechners angeben, obwohl das des localhost angefordert wird.
 
Dabei bitte Passwort des entfernten Rechners angeben, obwohl das des localhost angefordert wird.
  
−
Sitzt man selbst hinter einer Firewall am Rechner in der Arbeit A, hat aber einen Rechner I im Internet zur Verfügung muss mann zusätzlich zum obigen Einrichten eines Reverse-Tunnels von H zu I noch einen Forward-Tunnel von A zu I einrichten<ref>Vergleiche http://openbook.galileocomputing.de/linux/linux_kap21_003.html#dodtp09514538-0f5b-4580-9745-a2c1ca551a6d</ref>
+
Sitzt man selbst hinter einer Firewall am Rechner in der Arbeit A, hat aber einen Rechner I im Internet zur Verfügung muss man zusätzlich zum obigen Einrichten eines Reverse-Tunnels von H zu I noch einen Forward-Tunnel von A zu I einrichten.<ref>Vergleiche http://openbook.galileocomputing.de/linux/linux_kap21_003.html#dodtp09514538-0f5b-4580-9745-a2c1ca551a6d</ref> Dazu gibt man auf Rechner A Folgendes ein:
 
   ssh -C -f -N -L2223:localhost:2222 ip.of.I
 
   ssh -C -f -N -L2223:localhost:2222 ip.of.I
  
Zeile 140: Zeile 158:
 
   ssh -p 2223 localhost
 
   ssh -p 2223 localhost
  
 +
Hinweis: Zur Fehlersuche oder um einen [[Systemd]]-Service einzurichten, kann man das "-f" in den obigen Befehlen weglassen. Es führt dazu, dass SSH nach dem Verbindungsaufbau "forkt", also im Hintergrund weiterarbeitet.
 +
 +
== SSH über mehrere Rechner ==
 +
 +
Szenario: Man ist auf Rechner A, kann auf Rechner C aber nicht direkt von A sich einloggen, sondern nur von Rechner B, den man über Port 234.
 +
 +
Dann kann man auf Rechner A ausführen:
 +
  ssh -p 234 B
 +
 +
Und in der sich öffnenden SSH-Shell von Rechner B
 +
  ssh C
 +
 +
Oder - und das ist der Trick hier - man nutzt die <code>ProxyJump</code>-Anweisung in der .ssh/config:
 +
 +
  Host C
 +
      ProxyJump B:234
 +
 +
Siehe auch
 +
* https://superuser.com/questions/96489/an-ssh-tunnel-via-multiple-hops
 +
 +
== Autovervollständigung in der Shell ==
  
 +
Siehe [[Linux-Tipps#Autovervollständigung_für_Rechnernamen]]
  
 
== SSH-Client für Handys ==
 
== SSH-Client für Handys ==

Aktuelle Version vom 29. Januar 2024, 09:35 Uhr

Allgemeines

SSH bietet standardmäßig einen verschlüsselten Konsolenzugang von einem entfernten Computer. Der Standardport ist 22[1].

Sicherheit

SSH bietet einen sehr sicheren Zugang zu einem Server. Allerdings muss man auch hier die Sicherheitslücken möglichst gering halten.

X-Anwendungen über SSH nutzen

  • ssh unterstützt das Laufenlassen von graphischen X-Programmen über den einfachen Befehl:
  
    ssh -X user@ip-adresse
  • Voraussetzung auf dem Computer, der die X-Befehle erzeugt, ist allerdings, dass in der Datei /etc/ssh/sshd_config folgende Zeile enthalten ist:
  
    X11Forwarding yes
    X11UseLocalhost no # This is sometimes necessary!

Nach der Änderung wird der SSH-Server (Daemon) folgendermaßen neugestartet: 

  
    /etc/init.d/sshd restart


Sollen auch X-Anwendungen auf dem Remote-Rechner als Root ausgeführt werden (und man sich aus Sicherheitsgründen nicht als root mit dem Remote-Rechner verbinden will), muss das beim Einloggen erstellte .Xauthority-File zum User root kopiert werden:[2] 

 sudo cp ~/.Xauthority ~root/
 sudo chown root ~root/.Xauthority

SSH unter Windows

SSH-Windows-Client

PuTTY

Zugriff auf SSH-(Linux)-Server (einschl. GUI)

via WinSCP

Mit WinSCP lässt sich einfach auf andere Dateien zugreifen.

via CygWin
  • CygWin installieren (inklusive openssh-Modul)
  • Los geht's:
 ssh user@ip-adresse
  • Um X-Anwendungen zu starten:
    1. zusätzlich CygWin-Modul für X installieren
    2. in der CygWin-Shell folgendes eingeben:
 
 export DISPLAY=:0.0
 X &
 ssh -X user@ip-adresse
 kde

user ist der Name des Nutzers auf dem entfernten Rechner ip-adresse die IP-Adresse des entfernten Rechners. Im Beispiel wird davon ausgegangen, dass KDE auf dem entfernten Rechner installiert ist und mit kde aufgerufen werden kann.

Den Gnome Display Manager kann man auch via SSH starten und X weiterleiten. Die Alternative ist die Benutzung von x11vnc, getunnelt mittels ssh und damit VNC statt X

SSH-Windows-Server

freeSSHd

CygWin-SSH-Server

Datei-Zugriff

Zugriff unter KDE (z.B. Konqueror) über SSH

Unter Linux kann auf die Dateien eines entfernten Rechners recht einfach zugegriffen werden: Einfach 

 fish://user@remoteIP

in die Konqueror- oder eine andere Adressleiste eingeben. user ist dabei der Login-Name auf dem entfernten Rechner.

Kopieren mit scp

Ansonsten hilft das Programm scp, das mit ssh mitgeliefert wird: 

 scp -p source.dat user@ip-adresse:destination.dat

Der Schalter -p sorgt dafür, dass insbesondere das Änderungsdatum erhalten bleibt.

SSH ohne Passwortabfrage

SSH bietet mehrere Authentifizierungsmöglichkeiten.[3] Sehr einfach zu nutzen ist - neben der Passwortabfrage - der Public-Key-Modus. Dazu muss man auf dem SSH-Client 

 ssh-keygen

ohne Parameter starten und alle Abfragen mit einem simplen Return bestätigen.


Dann kopiert man die dadurch erzeugte Datei ~/.ssh/id_rsa.pub mit dem öffentlichen Schlüssel vom Client auf den Server und nennt sie dort ~/.ssh/authorized_keys: 

 scp ~/.ssh/id_rsa.pub ssh-server.de:.ssh/authorized_keys

Falls ~/.ssh/authorized_keys auf dem Server bereits existiert, kann man den Inhalt der Datei ~/.ssh/id_rsa.pub auch anhängen; dann funktionieren die bisherigen Einwahl-Möglichkeiten weiter. Beim nächsten Einloggen vom Client auf den Server wird man nicht mehr nach dem Passwort gefragt!

Eine Kurzform für das Kopieren und Anfügen bietet folgender Befehl: 

 ssh-copy-id user@ssh-server.de

SSH ohne known hosts-Abfrage

Durch Hinzufügen der Optionen 

 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

als Parameter für SSH wird das Host-Key-Checking von SSH umgangen, Risiko: Das ermöglicht Man-in-the-Middle-Attacken.

Man kann dies für spezifische Hosts auch dauerhaft in der (notfalls anzulegenden) Datei /home/USER/.shh/config festlegen[4]: 

 Host 192.168.0.*
    StrictHostKeyChecking no
    UserKnownHostsFile=/dev/null
 Host RECHNER.fritz.box
    StrictHostKeyChecking no
    UserKnownHostsFile=/dev/null


Auch hier gilt extreme Vorsicht: Das ermöglicht Man-in-the-Middle-Attacken.

Siehe auch diese Erläuterung des Host-Key-Checkings.

SSH mit anderem Port

Wenn man auf einen SSH-Server zugreifen will, der nicht auf dem Standardport läuft, haben die verschiedenen Client-Programme unterschiedliche Arten, diesen Port zu akzeptieren:

  • mit dem Kommandozeilenparameter --port oder -p
  • in der URL SERVERNAME:PORT
  • über /etc/ssh/config oder ~/.ssh/config
 Host XY
   HostName SERVERNAME
   Port PORT

dauerhafte SSH Verbindungen

Will man ein SSH-Terminal gelegentlich wieder aufrufen, hilft dafür das Paket screen.

Dieses stellt ein virtuelles Terminal dar, das auf mehreren Clients angezeigt werden kann. Falls dabei die falsche $TERM-Variable angezeigt wird, kann man dies richtigstellen: 

 export TERM=xterm


SSH hinter Firewall

Mithilfe von SSH-reverse-Tunnels kann man eine Firewall vor dem Remote-Rechner zu Hause H überwinden. Auf diesen kann man von einem Computer im Internet I folgendermaßen zugreifen: Auf Rechner H Folgendes (z.B. als Cron-Job) ausführen (SSH-Reverse-Tunnel einrichten): 

 ssh -C -f -N -R2222:localhost:22 ip.of.I

Auf Rechner I kann man dann auf H folgendermaßen zugreifen: 

 ssh -p 2222 localhost

Dabei bitte Passwort des entfernten Rechners angeben, obwohl das des localhost angefordert wird.

Sitzt man selbst hinter einer Firewall am Rechner in der Arbeit A, hat aber einen Rechner I im Internet zur Verfügung muss man zusätzlich zum obigen Einrichten eines Reverse-Tunnels von H zu I noch einen Forward-Tunnel von A zu I einrichten.[5] Dazu gibt man auf Rechner A Folgendes ein: 

 ssh -C -f -N -L2223:localhost:2222 ip.of.I

Dann kann man von Rechner A (über I) auf H folgendermaßen zugreifen: 

 ssh -p 2223 localhost

Hinweis: Zur Fehlersuche oder um einen Systemd-Service einzurichten, kann man das "-f" in den obigen Befehlen weglassen. Es führt dazu, dass SSH nach dem Verbindungsaufbau "forkt", also im Hintergrund weiterarbeitet.

SSH über mehrere Rechner

Szenario: Man ist auf Rechner A, kann auf Rechner C aber nicht direkt von A sich einloggen, sondern nur von Rechner B, den man über Port 234.

Dann kann man auf Rechner A ausführen: 

 ssh -p 234 B

Und in der sich öffnenden SSH-Shell von Rechner B 

 ssh C

Oder - und das ist der Trick hier - man nutzt die ProxyJump-Anweisung in der .ssh/config: 

 Host C
     ProxyJump B:234

Siehe auch

Autovervollständigung in der Shell

Siehe Linux-Tipps#Autovervollständigung_für_Rechnernamen

SSH-Client für Handys


  1. ↑ http://www.pro-linux.de/berichte/ssh-absichern.html
  2. ↑ http://www.redwireservices.com/remote-x11-for-linux-unix
  3. ↑ http://www.schlittermann.de/doc/ssh
  4. ↑ Siehe http://linuxcommando.blogspot.de/2008/10/how-to-disable-ssh-host-key-checking.html
  5. ↑ Vergleiche http://openbook.galileocomputing.de/linux/linux_kap21_003.html#dodtp09514538-0f5b-4580-9745-a2c1ca551a6d
Abgerufen von „https://railpulse.de/m_codicatipps/index.php?title=Ssh&oldid=22604“