Ssh: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
(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</ | + | 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 | + | 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
- PuTTY ist ein plattformübergreifender SSH-Client.
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:
- zusätzlich CygWin-Modul für X installieren
- 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
- freeSSHd ist ein Open Source SSH Server für Windows.
CygWin-SSH-Server
- CygWin-SSH-Servers unter Windows XP als Service
- Installation von eines CygWin-SSH-Servers unter Windows XP als Service
- Kurzversion dieser Anleitung
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
- ConnectBot für Android
- SSH-Client-Midlet
- ↑ http://www.pro-linux.de/berichte/ssh-absichern.html
- ↑ http://www.redwireservices.com/remote-x11-for-linux-unix
- ↑ http://www.schlittermann.de/doc/ssh
- ↑ Siehe http://linuxcommando.blogspot.de/2008/10/how-to-disable-ssh-host-key-checking.html
- ↑ Vergleiche http://openbook.galileocomputing.de/linux/linux_kap21_003.html#dodtp09514538-0f5b-4580-9745-a2c1ca551a6d