SSH: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
K (synt)
K (anti-redlink)
(12 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Artikelstil}}{{Veraltet}}
{{righttoc}}
{{righttoc}}


Zeile 15: Zeile 16:
OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen.
OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen.


== OpenSSH installieren ==
{{installation|repo=core|paket=openssh}}
OpenSSH kann aus dem ''core''-Repositorium einfach per Pacman installiert werden:
pacman -S openssh


== SSH konfigurieren ==
Nach der Installation stehen einige Programme zur Verfügung:


===Client===
* {{ic|ssh}} Ein Programm, mit dem man verschlüsselt auf die Shell entfernter Rechner zugreifen kann, aber auch Verbindungen tunneln kann.
* {{ic|scp}} Ein Programm, um verschlüsselt Dateien zu übertragen. Es funktioniert ähnlich wie {{ic|cp}} kann jedoch auf Dateien entfernter Rechner zugreifen.
* {{ic|ssh-keygen}} Mit diesem Programm kann man Schlüssel erstellen, welche die Passwort Authentifizierung auf entfernten Rechnern ersetzen können.
* {{ic|ssh-copy-id}} Mit diesem Programm können die erstellten Schlüssel für die Authentifizierung einfach und sicher ausgetauscht werden.
* {{ic|sshd}} Ein Daemon, der verwendet werden kann, um den Computer als entfernten Computer verwenden zu können.


Die SSH-Client-Konfigurationsdatei wird unter <code>/etc/ssh/ssh_config</code> automatisch angelegt.
== Verwendung ==


===Client ssh===


Hier eine Beispielkonfiguration:
Die SSH-Client-Konfigurationsdatei wird unter {{ic|/etc/ssh/ssh_config}} automatisch angelegt.
Die Standardkonfiguration ist für viele Fälle absolut ausreichend. Um die Sicherheit ein wenig zu erhöhen,
kann die '''ProtocolVersion''' auf 2 beschränkt werden. Die Standardeinstellung 2,1 besagt, dass zuerst eine Verbindung
über Version 2 versucht werden soll. Version 1 öffnet einem aktiven Angreifer einige Sicherheitsrelevanten Möglichkeiten wie MITM oder
Datainsertion [https://www.centos.org/docs/4/html/rhel-rg-en-4/s1-ssh-version.html [1]][http://cs.ucsb.edu/~koc/ns/projects/02Reports/YW.pdf [2]].


#      $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $
Mit {{ic|$ ssh [-p port] [user@]host}} wird eine sichere Verbindung zum Server '''host''' aufgebaut. Die Angabe von Port und User sind dabei optional. Wird der User weggelassen, so nimmt '''ssh''' den aktuellen Benutzernamen für den Verbindungsaufbau.
# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
Host *
#  ForwardAgent no
#  ForwardX11 no
#  RhostsRSAAuthentication no
#  RSAAuthentication yes
#  PasswordAuthentication yes
#  HostbasedAuthentication no
#  GSSAPIAuthentication no
#  GSSAPIDelegateCredentials no
#  BatchMode no
#  CheckHostIP yes
#  AddressFamily any
#  ConnectTimeout 0
#  StrictHostKeyChecking ask
#  IdentityFile ~/.ssh/identity
#  IdentityFile ~/.ssh/id_rsa
#  IdentityFile ~/.ssh/id_dsa
Port 22
#  Protocol 2,1
#  Cipher 3des
#  Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#  MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#  EscapeChar ~
#  Tunnel no
#  TunnelDevice any:any
#  PermitLocalCommand no
#  VisualHostKey no
HashKnownHosts yes
StrictHostKeyChecking ask
 
Es wird empfohlen, die Protokollzeile so zu ändern:
 
Protocol 2
 
Dies bedeutet, dass nur Protokoll 2 benutzt wird, da Protokoll 1 als unsicher gilt.


Beispiele
* {{ic|# ssh root@archlinux.com}} Baut eine root Verbindung zum Server archlinux.com auf.
* {{ic|# ssh -p 2222 max@192.168.0.2}} Baut eine Verbindung zum Computer 192.168.0.2 auf Port 2222 auf und versucht sich dort mit dem Benutzernamen max einzuloggen.
* {{ic|# ssh ::1}} Baut eine Verbindung zu localhost über IPv6 auf.


===Daemon===
===Daemon sshd.service===


Die Konfigurationsdatei des SSH-Daemons wird unter <code>/etc/ssh/</code> automatisch angelegt.
Die Konfigurationsdatei des Daemons {{ic|/etc/ssh/sshd_config}} sollte vor dem Start entsprechend angepasst werden:


Hier eine Beispielkonfiguration:
* {{ic|AllowUsers user1 user2}} schränkt den Zugriff auf die Benutzer user1 und user2 ein.  
 
* {{ic|AllowGroups sshusers}} schränkt den Zugriff auf Benutzer der Gruppe sshusers ein.
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $
* {{ic|Protocol 2}} beschränkt den Server lediglich auf die Verwendung von Protocol Version 2.
* {{ic|LoginGraceTime 120}} bedeutet, dass man nach 120 inaktiven Sekunden automatisch getrennt wird.
# This is the sshd server system-wide configuration file. See
* {{ic|PermitRootLogin no}} verbietet einen direkten Login des Benutzers root. Aufrufe per {{ic|sudo}} bleiben davon unberührt.
# sshd_config(5) for more information.
* {{ic|PasswordAuthentication no}} Kann benutzt werden, wenn man anstatt Passwörtern nur noch Schlüssel für die Authentifizierung ermöglichen will.
* {{ic|ChallengeResponseAuthentication no}} ChallengeResponseAuthentication kann sicher implementiert sein. Ist jedoch das Backend falsch konfiguriert, wird hier ebenfalls nur nach dem Passwort gefragt. Es bietet sich daher an, sofern man sich mit [[PAM]] aber nur eine Authentifizierung über Schlüssel zulassen möchte zu deaktivieren.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
* {{ic|ListenAddress ::}} Um auch IPv6 Verbindungen zuzulassen.
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Protocol 2,1
ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh''host''key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh''host''rsa_key
#HostKey /etc/ssh/ssh''host''dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes ~QuietMode and ~FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
   
   
# Set this to 'yes' to enable PAM authentication, account processing,
In der Datei {{ic|/etc/issue}} kann eine Nachricht hinterlassen werden, die bei jedem Login über ssh angezeigt wird.
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ~ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, ~PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem      sftp    /usr/lib/ssh/sftp-server


Um den Zugriff nur für bestimmte Nutzer zu erlauben, füge folgende Zeile hinzu:
Der Daemon welcher die Verbindung zu dem Computer zulässt sollte nur gestartet werden, wenn man auf den Computer entfernt zugreifen möchte.  
 
Der Name des Services ist {{ic|sshd.service}} und kann wie üblich über {{ic|# systemctl}} konfiguriert werden.
AllowUsers    user1 user2
  # systemctl enable sshd.service
 
# systemctl {start|stop|restart} sshd.service
Evtl. möchtest Du auch einige Zeilen ändern, so dass sie wie folgt aussehen:
 
<pre>
 
Protocol 2
 
.
 
.
 
.
 
LoginGraceTime 120
 
.
 
.
 
.
 
PermitRootLogin no # (put yes here if you want root login)
 
</pre>
 
Außerdem kann man die BANNER-Option einkommentieren und die Datei <code>/etc/issue</code> für eine nette Willkommensbotschaft bearbeiten.
 
Wahrscheinlich will man den Standard-Port von 22 auf irgendeinen höheren Port ändern (siehe dazu: [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).
 
Obwohl der Port, auf welchen SSH lauscht, von einem Port-Scanner wie ''nmap'' gefunden werden kann, wird die Änderung des Ports die Anzahl der automatischen Loginversuche merklich eindämmen.
 
Das Ausschalten von passwortbasierten Logins erhöht ebenfalls die Sicherheit, da jeder Nutzer, der sich auf dem Server anmelden will, einen SSH-Key erstellen muss (siehe dazu [[:en:SSH_Keys|Using SSH Keys]] {{sprache|en}}).
 
Dazu ist in der Datei <code>/etc/ssh/sshd_config</code> einzutragen:
 
PasswordAuthentication no
  ChallengeResponseAuthentication no
 
===Erlaube Fremdzugriffe===
 
Man muss diese Datei anpassen, um per SSH auf den Server zugreifen zu können, da diese in der Standardeinstellung leer ist. Um andere Benutzer per SSH auf den Server zugreifen zu lassen musst Du die Datei <code>/etc/hosts.allow</code> anpassen und folgendes hinzufügen:
 
<pre>
 
# let everyone connect to you
 
sshd: ALL
 
 
 
# OR you can restrict it to a certain ip
 
sshd: 192.168.0.1
 
 
 
# OR restrict for an IP range
 
sshd: 10.0.0.0/255.255.255.0
 
 
 
# OR restrict for an IP match
 
sshd: 192.168.1.
 
</pre>
 
Nun sollte man die Datei <code>/etc/hosts.deny</code> ansehen und sicherstellen, dass sie wie folgt aussieht:


ALL: ALL: DENY


Das war es. Du solltest nun einen funktionierenden SSH-Clienten und -Daemon haben.
=== Schlüsselgenerierung ssh-keygen und ssh-id-copy ===


Um die neue Konfiguration zu benutzen, starte den Daemon (als root) neu:
#ssh-keygen -t rsa


# systemctl restart sshd.service
Erzeugt einen privaten und einen öffentlichen Schlüssel. Normal werden diese in {{ic|/home/user/.ssh/id_rsa}} und {{ic|/home/user/.ssh/id_rsa.pub}} abgelegt. Der private Schlüssel {{ic|id_rsa}} sollte niemals in fremde Hände geraten, da er für die Authentifizierung auf allen konfigurierten Systemen ermöglicht! Der öffentliche Schlüssel kann auf einen SSH-Server mit folgendem Befehl installiert werden um sich anschließend ohne Passwort einzuloggen:
 
 
== Kontrolle des SSH Daemon ==
 
Automatischer Start beim booten:
 
# systemctl enable sshd.service
 
Um den Daemon zu starten/stoppen/neu starten, benutze man folgendes:
 
# systemctl {start|stop|restart} sshd.service


==Mit dem Server verbinden==
# ssh-copy-id -i /home/user/.ssh/id_rsa.pub user@host


Um sich mit einem Server zu verbinden, führe man folgendes aus:
Weitere Infos findet man in dem Artikel [[SSH-Authentifizierung mit Schlüsselpaaren]].


$ ssh -p port user@server-address


= Tips und Tricks =
=== Dateiübertragung scp ===


== Verschlüsselter Socks-Tunnel ==
Der Befehl {{ic|scp}} funktioniert im wesentlichen genau wie {{ic|cp}} jedoch können Ziel und Quelldateien auf verschiedenen über SSH zugänglichen Computern liegen. Am besten versteht man {{ic|scp}} an einigen Beispielen:


Dies ist sehr nützlich für Laptop Benutzer, die zu unterschiedlichen, unsicheren Funknetzwerken verbunden werden. Das einzige, was man dafür braucht, ist ein laufender SSH-Server mit einem sicheren Anschluss, wie dein Home-PC oder dein Arbeitsplatzrechner. Es ist nützlich, einen dynamischen DNS Service wie [http://www.dyndns.org/ DynDNS] zu benutzen, um flexibel eine IP-Adresse zugewiesen zu bekommen.
* {{ic|scp mypicture.png max@mustermannserver.net:/home/max/mypicture.png}} Überträgt die Datei mypicture.png auf den mustermannserver in /home/max/. Dabei wird der Benutzer max zur Authentifizierung am Zielserver verwendet.
* {{ic|scp max@mustermannserver.net:/home/max/mypicture.png ./mypicture.png}} Kopiert die Datei vom mustermannserver zum lokalen Computer
* {{ic|scp root@server1:/etc/fstab root@server2:/etc/fstab}} überträgt die fstab Datei von Server1 nach Server2.


Natürlich können auch ganze Verzeichnisse kopiert werden oder rekursive Befehle genutzt werden. Dabei geht man exakt so vor wie bei cp.


=== Schritt 1: Starte die Verbindung ===
= Tipps und Tricks =


Nur ein einziges Programm ist im Terminal auszuführen, um die Verbindung zu starten:
== Verschlüsselter Socks4 Proxy ==


$ ssh -ND localhost:4711 user@host
Ein Rechner, auf dem ein SSH-Daemon läuft zu dem man einen Zugang hat, kann verschlüsselt als Proxy verwendet werden. Das bedeutet man kann alle Verbindungen verschlüsselt über diesen Computer weiterleiten. Dies kann für mehrere Szenarien verwendet werden:
* Gateway Zugang zu einem Firmennetz
* Sicherer Internetzugang in einem unverschlüsselten oder unsicheren WLAN
* Anonymisierung im Internet
* Sichere Verbindung zweier entfernter Firmenstandorte


Dabei ist '''user''' der Benutzername auf dem SSH-Server, der als '''host''' läuft. SSH wird dich nach einem Passwort fragen und dich dann verbinden. Das '''N'''-Flag schaltet die interaktive Eingabeaufforderung ab und das '''D'''-Flag stellt den lokalen Port ein, auf den gelauscht werden soll. Die Angabe von localhost: bewirkt, dass nur vom eigenen Computer aus auf den Tunnel zugegriffen werden kann. Die Port-Nummer kann beliebig gewählt werden.
{{achtung|Die Verbindung wird nicht bis zum Zielrechner verschlüsselt, sondern nur bis zum SSH Server!}}


Ein Weg, dies zu vereinfachen, ist, einen Alias wie den folgenden in die ~/.bashrc (oder je nach der eingesetzten Shell) hinzuzufügen:


  alias sshtunnel="ssh -ND localhost:4711 -v user@host"
  $ ssh -ND localhost:8080 user@host


Es ist praktisch, das '''v'''-Flag (für verbose - gesprächig) hinzuzufügen, da man dank diesem in dem SSH-Output ablesen kann, ob man verbunden ist. Nun muss man nur noch das '''sshtunnel'''-Kommando ausführen :)
Dieser Befehl öffnet auf dem Lokalen Computer den Port 8080 als Socks4 Proxyverbindungen. Dazu wird der Computer '''host''' als Proxy verwendet.
Die Einschränkung '''localhost''' besagt dabei, dass nur der lokale Computer eine Verbindung zum Port 8080 aufbauen darf. Man kann hier auch einen IP Bereich angeben und so anderen Computern im lokalen Netzwerk ermöglichen den Tunnel zu benutzen. Die Verbindung wird für '''user''' authentifiziert und danach der lokale Proxyport freigegeben. Die Wahl des Ports 8080 kann beliebig erfolgen. Alle Programme die den Tunnel nutzen sollen, müssen auf diesen Port konfiguriert werden. Der Parameter N besagt lediglich, dass keine Eingabeaufforderung aktiv werden soll und D ist für das öffnen des Ports verantwortlich.


=== Schritt 2: Konfiguriere deinen Browser (oder andere Programme) ===
Um den Aufwand zu reduzieren kann man einen alias in ~/.bashrc hinzuzufügen:


Der vorherige Schritt ist vollkommen nutzlos, wenn du deinen Web Browser (oder andere Programme) nicht so konfigurierst, dass sie den neuen Socks-Tunnel benutzen.
alias sshtunnel="ssh -ND localhost:8080 -v user@host"


* Für Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':
Das '''v'''-Flag (für verbose - gesprächig) wird hinzugefügt, damit man an den Ausgaben erkennen kann ob die Verbindung aufgebaut wurde.
: Markiere die ''"Manual proxy configuration"'' Option und schreibe "localhost" in das ''"SOCKS host"'' Textfeld. Dann gib deine Port-Nummer im nächsten Feld an.
: Stelle sicher, dass du SOCKS4 als das zu benutzende Protokoll angibst, da diese Einstellungen nicht für SOCKS5 funktionieren.


Viel Spaß mit deinem sicheren Tunnel!
{{achtung|Nur Programme bei denen ein Socks4 Proxy auf localhost:8080 konfiguriert wurde benutzen diesen verschlüsselten Tunnel. Alle anderen Programme schicken ihre Pakete nach wie vor direkt auf den Weg!}}


== X11 weiterreichen ==
== X11 weiterreichen ==


Um grafische Programme durch eine SSH-Verbindung zu benutzen, musst du das Weiterreichen von X11 aktivieren. Dafür müssen die Konfigurationsdateien auf dem Server und Client (in diesem Fall ist der "Client" dein Desktop PC (oder Laptop) auf dem der X11-Server läuft und du wirst Grafische Programme auf dem "Server" laufen lassen).
Um grafische Programme durch eine SSH-Verbindung zu benutzen, muss man das Weiterreichen von X11 aktivieren. Damit können Programme entfernt ausgeführt jedoch die graphische Oberfläche lokal angezeigt werden. Man installiert dazu das Paket {{ic|xorg-xauth}} auf dem Server und ändert folgende Einstellungen
 
Installiere xorg-xauth auf dem Server:
 
# pacman -S xorg-xauth
 


* Aktiviere die '''AllowTcpForwarding''' Option in der '''sshd_config''' auf deinem '''Server'''.
* Aktiviere die '''AllowTcpForwarding''' Option in der '''sshd_config''' auf deinem '''Server'''.
Zeile 338: Zeile 121:
* Aktiviere die '''ForwardX11''' Option in der '''ssh_config''' auf deinem '''Client'''.
* Aktiviere die '''ForwardX11''' Option in der '''ssh_config''' auf deinem '''Client'''.


Um X weiter zu reichen, logge dich auf deinem Server per SSH ein:
Um die Verbindung zum X11 aufzubauen fügt man X oder Y (für sicheres Verbinden) beim Verbindungsaufbau hinzu:


  # ssh -X -p port user@server-address
  # ssh -X[Y] -p port user@host


Wenn du bei dem Versuch, grafische Programme zu starten, Fehlermeldungen erhältst, versuche stattdessen ''sicheres Weiterreichen'':
Startet man nun ein grafisches Programm wie {{ic|xclock}} in der Eingabeaufforderung so wird die Anwendung auf '''host''' gestartet, die GUI erscheint jedoch lokal.


# ssh -Y -p port user@server-address
== Port Weiterleitung mit SSH ==


Nun kannst du jedes grafische Programm auf deinem Server starten und die Informationen werden zu deinem Client weitergeleitet:
SSH erlaubt es auch einzelne Ports verschlüsselt zu verknüpfen. Dazu können alle Verbindungen auf einem Quellport zu einem Zielport über einen konkreten Rechner weitergeleitet werden.


  # xclock
  ssh -g -L 120:ZIEL:80 user@host


== Port Forwarding mit SSH ==
Dieser Befehl öffnet einen lokalen Port (120) und leitet alle Verbindungen auf diesem Port über '''host''' zum Port 80 auf '''Ziel''' weiter.


Falls es einmal zu dem Fall kommen sollte, dass man vom Zielserver aus auf einen anderen zugreifen möchte, dies aber von seinem lokalen Rechner aus durchführen will, kann man bestimmte Ports durch die SSH-Verbindun hindurch leiten. Als Anwendungsbereich könnte das Szenario vorkommen, dass ein bestimmter Rechner B auf mehrere Zielsysteme (Rechner C) Zugriff hat, Rechner C jedoch von unserem Rechner (Rechner A) nicht verfügbar ist. Daher wollen wir unsere Anfragen vom Rechner A über den Rechner B an Rechner C weiter leiten. Für Rechner C sieht es dann so aus, als würde lediglich Rechner B auf ihn zugreifen.
ssh -g -L8080:192.168.0.23:80 user@sshgateway.firma.net


Rechner A --> ssh-Verbindung --> Rechner B --> Port Weiterleitung --> Rechner C
* 192.168.23 ist dabei z.B. ein Webserver der auf Port 80 im lokalen Netzwerk von firma.net hört.
* Öffnet man nun http://localhost:8080, so werden die Daten an den sshgateway.firma.net weitergeleitet, welche die Zustellung an 192.168.23 übernimmt.


=== einfache Port Weiterleitung ===
{{achtung|Falsch konfigurierte SSH-Gateways können ganze Firmennetze kompromittieren!}}


Das ganze führt man wie folgt durch. Auf Rechner B muss zunächst das Portforwarding aktiviert sein. In der sshd_conf nimmt man also auf Rechner B folgende Einstellungen vor:
Man kann den Parameter -L mehrmals verwenden:
ssh -g -L8080:192.168.0.23:80 -L8081:192.168.0.24:80 user@sshgateway.firma.net


#AllowTcpForwarding No
Nutzen man statt dem Schalter "-L" den Schalter "-R", so wird aus der Lokalen Weiterleitung eine Remote Weiterleitung. Man kann damit dem Zielrechner die Verwendung eines lokalen Services ermöglichen.


Dieser Wert sollte auskommentiert werden. Nun kann man auf dem Rechner A folgendes eingeben:
== Ein entferntes Filesystem mit SSHFS mounten ==


ssh -g -L PORT_Rechner_A:IP_Rechner_C:PORT_Rechner_C Benutzername@IP_Rechner_B
Zuerst muss SSHFS installiert und das [[fuse]] Modul geladen werden. Wie man das fuse Modul automatisch lädt kann dem Artikel [[Kernel Module]] entnommen werden.
ssh -g -L 80:192.168.10.10:80 root@192.168.10.1


Falls dieser Aufruf dazu diente, auf den Webserver des Rechners C (IP: 192.168.10.10) zuzugreifen, kann nun anschliessend kann auf Rechner A im Webbrowser folgendes eingegeben werden:
# pacman -S sshfs
# modprobe fuse


localhost:80


Die Ausgaben des lokalen Ports 80 werden (bei geöffneter SSH Verbindung) nun durch den Rechner B (192.168.10.1) auf den Port 80 des Rechners C (192.168.10.10) weiter geleitet. Für Rechner C (dem Webserver) sieht dies nun so aus, als würde Rechner B auf ihn zugreifen. Das ganze funktioniert jedoch nur so lange, wie die SSH Sitzung zu Rechner B aufgebaut bleibt.
Um nun einen entfernten Ordner zu mounten, erstellt man einen Ordner und verlinkt diesen über '''sshfs''':
als Hinweis sei noch gegeben, dass der Quell-Port auf Rechner A nicht dem Zielport auf Rechner C entsprechen muss. Falls der Webserver des Rechners C nicht auf dem Standard Port 80 läuft, sondern ggf. auf Port 8080, so kann auch folgendes durchgeführt werden:
# mkdir ~/remote_folder
# sshfs USER@remote_server:/path/to/folder ~/remote_folder


ssh -g -L 80:192.168.10.10:8080 root@192.168.10.1
Das Kommando oben wird den Ordner '''/tmp''' auf dem Server in den Ordner '''~/remote_folder''' auf deinem lokalen Computer einhängen. Schreibvorgänge in diesem Ordner werden per SFTP ausgeführt. Mit {{ic|#fusermount -u ~/remote_folder}} kann das entfernte Verzeichnis wieder ausgehängt werden.


Der Aufruf im Webbrowser des Rechners A bleibt in diesem Falle auf Port 80, wird jedoch auf Port 8080 auf den Zielrechner weiter geleitet.
Möchte man einen Eintrag in die [[fstab]] machen um das Verzeichnis automatisch beim Systemstart einzuhängen, fügt man folgende Zeile in {{ic|/etc/fstab}} ein:
sshfs USER@remote_server:/path/to/source /path/to/target fuse    defaults,auto,allow_other    0 0


=== Port-Weiterleitung mehrerer Ports gleichzeitig ===
Dabei gibt {{ic|/path/to/source}} das Verzeichnis auf dem Server und {{ic|/path/to/target}} das lokale Verzeichnis an. Man sollte den Eintrag in die ''fstab'' mit dem Befehl {{ic|# mount --all}} testen, da eine fehlerhafte '''fstab''' zu Problemen beim Systemstart führen kann!


Falls der Dienst, welchen man auf Rechner C nutzen möchte nicht nur einen Port benötigt (Beispielsweise Windows Freigaben), so benötigt man mehrere Ports. Im Beispiel der Windows Freigaben werden die Ports 137, 138 und 139 benötigt. Dies könnte man entweder durch drei gleichzeitige SSH Sitzungen auf den Mittelrechner (Rechner B) erreichen:
== Geschwindigkeitsoptimierungen ==


ssh -g -L 137:192.168.10.10:137 root@192.168.10.1
Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind ''Arcfour'' und ''Blowfish-CBC'' die besten Alternativen. Um sie zu benutzen, führt man SSH mit dem '''c'''-Flag aus:
ssh -g -L 138:192.168.10.10:138 root@192.168.10.1
ssh -g -L 139:192.168.10.10:139 root@192.168.10.1
 
oder aber, wir nutzen in einer SSH Sitzung gleich mehrere Port-Weiterleitungen gleichzeitig:
 
ssh -g -L 137:192.168.10.10:137 -L 138:192.168.10.10:138 -L 139:192.168.10.10:139 root@192.168.10.1
 
Falls wir also anschliessend auf die Freigaben von Rechner A zugreifen, indem wir "localhost\Freigabe" benutzen, bekommen wir als Ergebnis die Windows Freigaben des Rechners C.
 
=== Lokale Weiterleitung vs. Remote Weiterleitung ===
 
Der Schalter "-L" besagt, dass hier eine Lokale Weiterleitung genutzt wird. Dies ist eine Art Richtungsangabe für die Portweiterleitung. Anfragen auf unseren angegebenen Lokalen Port werden also an den "Server" des Rechners C weiter geleitet. Falls die Konstellation jedoch anders herum ist, und der Webserver auf dem Rechner A laufen sollte, kann in diesem Falle Rechner C nicht auf unseren zugreifen. Die Art "Lokale Weiterleitung" besagt also, dass Rechner A als Client tätig ist, und Rechner C als Server. Nutzen wir jedoch statt dem Schalter "-L" den Schalter "-R", so wird aus der Lokalen Weiterleitung eine "Remote Weiterleitung". Zwar ist es unserem Rechner A nicht möglich, auf Dienste des Rechners C zuzugreifen, wir räumen jedoch in diesem Fall Rechner C die Möglichkeit ein, auf unseren Port zuzugreifen.
 
== Befehle remote ausführen ==
 
Per SSH ist es auch möglich, lediglich kurz eine SSH Verbindung zu öffnen, auf der Gegenseite einen Befehl auszuführen und anschliessend sofort die SSH Verbindung zu beenden. Dies geht etwa folgendermaßen:
 
ssh root@192.168.10.1 "ls -lah"
 
Dies würde lediglich eine SSH Verbindung zum Rechner 192.168.10.1 öffnen, dort kurz den Befehl "ls -lah" ausführen, die Ausgabe lokal auf der Konsole ausgeben und anschliessend die SSH Verbindung wieder schliessen. Dies kann unter Umständen sehr nützlich sein, um Skripte im größeren Umfang zu schreiben. Eine weitere Einsatzmöglichkeit zeigt sich durch die Verwerndung von Pipes:
 
dd if=/root/Archiv.tar.gz | ssh root@192.168.10.10 "dd of=/root/Archiv.tar.gz"
 
In diesem Fall würde auf dem lokalen Rechner die Datei /root/Archiv.tar.gz per dd in die Standard-Ausgabe geleitet werden, per Pipe in die Standard-Eingabe des folgenden Befehls, welcher diesen durch die SSH Sitzung an dort gestarteten Befehl weiter leitet. So wäre auch ein Kopieren einer Datei durch eine SSH Sitzung möglich. Auch das kopieren kompletter Partitionen wird hierbei interessant, allerdings sollte vorher entweder mit gzip gearbeitet werden, da sonst sehr viel Traffic aufkommt und dies mitunter sehr lange dauern kann:
 
# unkomprimiert:
dd if=/dev/sda2 | ssh root@192.168.10.1 "dd of=/dev/sda2"
# komprimiert:
dd if=/dev/sda2 | gzip | root@192.168.10.1 "gunzip | dd of=/dev/sda2"
 
== Speed up SSH ==
 
Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind ''Arcfour'' und ''Blowfish-CBC'' die besten Alternativen. Um sie zu benutzen, führe SSH mit dem '''c'''-Flag aus:


  # ssh -c arcfour,blowfish-cbc user@server-address
  # ssh -c arcfour,blowfish-cbc user@server-address


Um sie immer zu benutzen, füge diese Zeile unter dem Punkt "Host" in deiner '''/etc/ssh/ssh_config''' ein:
Um sie immer zu benutzen, fügt man diese Zeile unter dem Punkt "Host" in der '''/etc/ssh/ssh_config''' ein:


  Ciphers arcfour,blowfish-cbc
  Ciphers arcfour,blowfish-cbc
Zeile 435: Zeile 189:
  alias ssh='ssh -C4c arcfour,blowfish-cbc'
  alias ssh='ssh -C4c arcfour,blowfish-cbc'


Letztendlich kannst du alle Verbindungen zu dem selben Host nur eine einzige Verbindung benutzen lassen, was dir einen wahren Geschwindigkeit-Boost geben sollte. Füge dafür folgende Zeilen unter dem Punkt "Host" in deiner '''/etc/ssh/ssh_config''' ein:
Man kann alle Verbindungen zu dem selben Host nur eine einzige Verbindung laufen lassen, was einen wahren Geschwindigkeitszuwachs geben sollte. Dafür fügt man folgende Zeilen in die Konfigurationsdatei '''/etc/ssh/ssh_config''' ein:


  ControlMaster auto
  ControlMaster auto
  ControlPath ~/.ssh/socket-%r@%h:%p
  ControlPath ~/.ssh/socket-%r@%h:%p




=== Trouble Shooting ===
= Problemlösungen =


Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist:
Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist:
Zeile 457: Zeile 210:




Wenn dieser Fehler auftaucht, solltest du ''localhost'' zu deiner '''/etc/hosts''' hinzufügen.
Wenn dieser Fehler auftaucht, solltest man ''localhost'' zu '''/etc/hosts''' hinzufügen.
 
== Ein entferntes Filesystem mit SSHFS mounten ==
 
Zuerst muss SSHFS installiert werden:
 
# pacman -S sshfs
 
Nun muss das Fuse-Modul geladen werden:
 
# modprobe fuse
 
Modul automatisch beim Systemstart laden: [[Kernel Module]].
 
 
Mounte den entfernten Ordner mit SSHFS:
 
# mkdir ~/remote_folder
# sshfs USER@remote_server:/tmp ~/remote_folder
 
Das Kommando oben wird den Ordner '''/tmp''' auf dem Server in den Ordner '''~/remote_folder''' auf deinem lokalen Computer einhängen. Schreibvorgänge in diesem Ordner werden per SFTP ausgeführt.
 
 
Wenn du mit der Arbeit auf dem Server fertig bist, kannst du den Ordner mit folgendem Befehl wieder aushängen:
 
# fusermount -u ~/remote_folder
 
Wenn du häufiger an diesem Ordner arbeitest, kannst du ihn mithilfe der '''/etc/fstab''' automatisch beim Systemstart oder manuell (z.B. per ''# mount -a'') einhängen. So könnte solch ein Eintrag aussehen:
 
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse    defaults,auto,allow_other    0 0


== Autologout verhindern ==
== Autologout verhindern ==


Deine SSH-Session wird nach einiger Zeit beendet, wenn du zu lange inaktiv warst. Um dies zu verhindern, muss folgendes in die '''~/.ssh/config''' oder in die '''/etc/ssh/ssh_config''' geschrieben werden:
Deine SSH-Session wird nach einiger Zeit beendet, wenn man lange inaktiv war. Um dies zu verhindern, muss folgendes in die '''~/.ssh/config''' oder in die '''/etc/ssh/ssh_config''' geschrieben werden:


  ServerAliveInterval 120
  ServerAliveInterval 120
Zeile 531: Zeile 254:
Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config Documentation] auf der offiziellen Homepage.
Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config Documentation] auf der offiziellen Homepage.


= Siehe auch =


*[[SSH-Authentifizierung mit Schlüsselpaaren]]


= Weblinks =
= Weblinks =
* [http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]
* [http://webssh.cz.cc Using your browser as SSH client]


* [http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]
* [http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]


* [http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch09_02.htm O'Reilly SSH, the secure Shell: the definitive guide, Chapter 9.2 Port Forwarding]
* [http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch09_02.htm O'Reilly SSH, the secure Shell: the definitive guide, Chapter 9.2 Port Forwarding]
 
[[Kategorie:Artikelstil]]
[[Kategorie:Sicherheit]]
[[Kategorie:Sicherheit]]
[[Kategorie:Netzwerk]]
[[Kategorie:Netzwerk]]
[[Kategorie:Server]]
[[Kategorie:Server]]
[[en:Secure Shell]]
[[en:Secure Shell]]

Version vom 10. Januar 2021, 18:28 Uhr

Dieser Artikel oder Artikelabschnitt bedarf einer stilistischen Überarbeitung laut Empfehlungen in Artikelstil.


Dieser Artikel wurde als veraltet markiert, und sollte kontrolliert, und gegebenfalls korrigiert bzw. aktualisiert werden.


Secure Shell oder SSH ist ein Netzwerkprotokoll, welches den sicheren Datenaustausch zwischen zwei Computern über ein Netzwerk gestattet. SSH bietet dank Verschlüsselung Diskretion und Integrität der versendeten Daten. Als Verschlüsselungsverfahren wird ein asymmetrisches Kryptosystem (Verschlüsselung durch Public- und Private-Keys) eingesetzt, um den zugreifenden Computer und - falls benötigt - auch den zugreifenden Benutzer zu verifizieren.

SSH wird normalerweise benutzt, um sich in einem entfernten System einzuloggen und Kommandos auszuführen. Zusätzlich werden Tunneling, das Transmission Control Protocol (TCP) und X11 Verbindungen unterstützt. Datentransfer kann durch die Protokolle SFTP und SCP erreicht werden.

Standardmäßig lauscht der SSH-Server auf den Standard-TCP-Port 22. Ein SSH-Client-Programm wird normalerweise zur Herstellung einer Verbindung zu einem sshd (Secure Shell Daemon) benutzt. Beide Programme sind für die meisten modernen Betriebssysteme vorhanden. U.a. für Mac OS X, GNU/Linux, Solaris und OpenVMS. Proprietäre, freie und Open Source Versionen in unterschiedlicher Komplexität und Vollständigkeit existieren.

(Quelle: Secure Shell])

OpenSSH

OpenSSH (OpenBSD Secure Shell) ist eine Sammlung von Programmen, die eine verschlüsselte Verbindung über ein Computernetzwerk mit dem SSH-Protokoll erlauben. Sie wurde als eine Open-Source-Alternative zu der proprietären Secure Shell Software Suite des Unternehmens SSH Communications Security erstellt. OpenSSH wird als Teil des OpenBSD Projektes entwickelt und von Theo de Raadt geleitet.

OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen.

Installation

Das Programm ist als openssh in core verfügbar, und kann von dort mittels Pacman installiert werden.

pacman -S openssh

Nach der Installation stehen einige Programme zur Verfügung:

  • ssh Ein Programm, mit dem man verschlüsselt auf die Shell entfernter Rechner zugreifen kann, aber auch Verbindungen tunneln kann.
  • scp Ein Programm, um verschlüsselt Dateien zu übertragen. Es funktioniert ähnlich wie cp kann jedoch auf Dateien entfernter Rechner zugreifen.
  • ssh-keygen Mit diesem Programm kann man Schlüssel erstellen, welche die Passwort Authentifizierung auf entfernten Rechnern ersetzen können.
  • ssh-copy-id Mit diesem Programm können die erstellten Schlüssel für die Authentifizierung einfach und sicher ausgetauscht werden.
  • sshd Ein Daemon, der verwendet werden kann, um den Computer als entfernten Computer verwenden zu können.

Verwendung

Client ssh

Die SSH-Client-Konfigurationsdatei wird unter /etc/ssh/ssh_config automatisch angelegt. Die Standardkonfiguration ist für viele Fälle absolut ausreichend. Um die Sicherheit ein wenig zu erhöhen, kann die ProtocolVersion auf 2 beschränkt werden. Die Standardeinstellung 2,1 besagt, dass zuerst eine Verbindung über Version 2 versucht werden soll. Version 1 öffnet einem aktiven Angreifer einige Sicherheitsrelevanten Möglichkeiten wie MITM oder Datainsertion [1][2].

Mit $ ssh [-p port] [user@]host wird eine sichere Verbindung zum Server host aufgebaut. Die Angabe von Port und User sind dabei optional. Wird der User weggelassen, so nimmt ssh den aktuellen Benutzernamen für den Verbindungsaufbau.

Beispiele

  • # ssh root@archlinux.com Baut eine root Verbindung zum Server archlinux.com auf.
  • # ssh -p 2222 max@192.168.0.2 Baut eine Verbindung zum Computer 192.168.0.2 auf Port 2222 auf und versucht sich dort mit dem Benutzernamen max einzuloggen.
  • # ssh ::1 Baut eine Verbindung zu localhost über IPv6 auf.

Daemon sshd.service

Die Konfigurationsdatei des Daemons /etc/ssh/sshd_config sollte vor dem Start entsprechend angepasst werden:

  • AllowUsers user1 user2 schränkt den Zugriff auf die Benutzer user1 und user2 ein.
  • AllowGroups sshusers schränkt den Zugriff auf Benutzer der Gruppe sshusers ein.
  • Protocol 2 beschränkt den Server lediglich auf die Verwendung von Protocol Version 2.
  • LoginGraceTime 120 bedeutet, dass man nach 120 inaktiven Sekunden automatisch getrennt wird.
  • PermitRootLogin no verbietet einen direkten Login des Benutzers root. Aufrufe per sudo bleiben davon unberührt.
  • PasswordAuthentication no Kann benutzt werden, wenn man anstatt Passwörtern nur noch Schlüssel für die Authentifizierung ermöglichen will.
  • ChallengeResponseAuthentication no ChallengeResponseAuthentication kann sicher implementiert sein. Ist jedoch das Backend falsch konfiguriert, wird hier ebenfalls nur nach dem Passwort gefragt. Es bietet sich daher an, sofern man sich mit PAM aber nur eine Authentifizierung über Schlüssel zulassen möchte zu deaktivieren.
  • ListenAddress :: Um auch IPv6 Verbindungen zuzulassen.

In der Datei /etc/issue kann eine Nachricht hinterlassen werden, die bei jedem Login über ssh angezeigt wird.

Der Daemon welcher die Verbindung zu dem Computer zulässt sollte nur gestartet werden, wenn man auf den Computer entfernt zugreifen möchte. Der Name des Services ist sshd.service und kann wie üblich über # systemctl konfiguriert werden.

# systemctl enable sshd.service
# systemctl {start|stop|restart} sshd.service


Schlüsselgenerierung ssh-keygen und ssh-id-copy

#ssh-keygen -t rsa

Erzeugt einen privaten und einen öffentlichen Schlüssel. Normal werden diese in /home/user/.ssh/id_rsa und /home/user/.ssh/id_rsa.pub abgelegt. Der private Schlüssel id_rsa sollte niemals in fremde Hände geraten, da er für die Authentifizierung auf allen konfigurierten Systemen ermöglicht! Der öffentliche Schlüssel kann auf einen SSH-Server mit folgendem Befehl installiert werden um sich anschließend ohne Passwort einzuloggen:

# ssh-copy-id -i /home/user/.ssh/id_rsa.pub user@host

Weitere Infos findet man in dem Artikel SSH-Authentifizierung mit Schlüsselpaaren.


Dateiübertragung scp

Der Befehl scp funktioniert im wesentlichen genau wie cp jedoch können Ziel und Quelldateien auf verschiedenen über SSH zugänglichen Computern liegen. Am besten versteht man scp an einigen Beispielen:

  • scp mypicture.png max@mustermannserver.net:/home/max/mypicture.png Überträgt die Datei mypicture.png auf den mustermannserver in /home/max/. Dabei wird der Benutzer max zur Authentifizierung am Zielserver verwendet.
  • scp max@mustermannserver.net:/home/max/mypicture.png ./mypicture.png Kopiert die Datei vom mustermannserver zum lokalen Computer
  • scp root@server1:/etc/fstab root@server2:/etc/fstab überträgt die fstab Datei von Server1 nach Server2.

Natürlich können auch ganze Verzeichnisse kopiert werden oder rekursive Befehle genutzt werden. Dabei geht man exakt so vor wie bei cp.

Tipps und Tricks

Verschlüsselter Socks4 Proxy

Ein Rechner, auf dem ein SSH-Daemon läuft zu dem man einen Zugang hat, kann verschlüsselt als Proxy verwendet werden. Das bedeutet man kann alle Verbindungen verschlüsselt über diesen Computer weiterleiten. Dies kann für mehrere Szenarien verwendet werden:

  • Gateway Zugang zu einem Firmennetz
  • Sicherer Internetzugang in einem unverschlüsselten oder unsicheren WLAN
  • Anonymisierung im Internet
  • Sichere Verbindung zweier entfernter Firmenstandorte

Achtung: Die Verbindung wird nicht bis zum Zielrechner verschlüsselt, sondern nur bis zum SSH Server!


$ ssh -ND localhost:8080 user@host

Dieser Befehl öffnet auf dem Lokalen Computer den Port 8080 als Socks4 Proxyverbindungen. Dazu wird der Computer host als Proxy verwendet. Die Einschränkung localhost besagt dabei, dass nur der lokale Computer eine Verbindung zum Port 8080 aufbauen darf. Man kann hier auch einen IP Bereich angeben und so anderen Computern im lokalen Netzwerk ermöglichen den Tunnel zu benutzen. Die Verbindung wird für user authentifiziert und danach der lokale Proxyport freigegeben. Die Wahl des Ports 8080 kann beliebig erfolgen. Alle Programme die den Tunnel nutzen sollen, müssen auf diesen Port konfiguriert werden. Der Parameter N besagt lediglich, dass keine Eingabeaufforderung aktiv werden soll und D ist für das öffnen des Ports verantwortlich.

Um den Aufwand zu reduzieren kann man einen alias in ~/.bashrc hinzuzufügen:

alias sshtunnel="ssh -ND localhost:8080 -v user@host"

Das v-Flag (für verbose - gesprächig) wird hinzugefügt, damit man an den Ausgaben erkennen kann ob die Verbindung aufgebaut wurde.

Achtung: Nur Programme bei denen ein Socks4 Proxy auf localhost:8080 konfiguriert wurde benutzen diesen verschlüsselten Tunnel. Alle anderen Programme schicken ihre Pakete nach wie vor direkt auf den Weg!


X11 weiterreichen

Um grafische Programme durch eine SSH-Verbindung zu benutzen, muss man das Weiterreichen von X11 aktivieren. Damit können Programme entfernt ausgeführt jedoch die graphische Oberfläche lokal angezeigt werden. Man installiert dazu das Paket xorg-xauth auf dem Server und ändert folgende Einstellungen

  • Aktiviere die AllowTcpForwarding Option in der sshd_config auf deinem Server.
  • Aktiviere die X11Forwarding Option in der sshd_config auf deinem Server.
  • Ändere die X11DisplayOffset Option in der sshd_config auf deinem Server auf 10.
  • Aktiviere die X11UseLocalhost Option in der sshd_config auf deinem Server.
  • Aktiviere die ForwardX11 Option in der ssh_config auf deinem Client.

Um die Verbindung zum X11 aufzubauen fügt man X oder Y (für sicheres Verbinden) beim Verbindungsaufbau hinzu:

# ssh -X[Y] -p port user@host

Startet man nun ein grafisches Programm wie xclock in der Eingabeaufforderung so wird die Anwendung auf host gestartet, die GUI erscheint jedoch lokal.

Port Weiterleitung mit SSH

SSH erlaubt es auch einzelne Ports verschlüsselt zu verknüpfen. Dazu können alle Verbindungen auf einem Quellport zu einem Zielport über einen konkreten Rechner weitergeleitet werden.

ssh -g -L 120:ZIEL:80 user@host

Dieser Befehl öffnet einen lokalen Port (120) und leitet alle Verbindungen auf diesem Port über host zum Port 80 auf Ziel weiter.

ssh -g -L8080:192.168.0.23:80 user@sshgateway.firma.net
  • 192.168.23 ist dabei z.B. ein Webserver der auf Port 80 im lokalen Netzwerk von firma.net hört.
  • Öffnet man nun http://localhost:8080, so werden die Daten an den sshgateway.firma.net weitergeleitet, welche die Zustellung an 192.168.23 übernimmt.

Achtung: Falsch konfigurierte SSH-Gateways können ganze Firmennetze kompromittieren!


Man kann den Parameter -L mehrmals verwenden:

ssh -g -L8080:192.168.0.23:80 -L8081:192.168.0.24:80 user@sshgateway.firma.net

Nutzen man statt dem Schalter "-L" den Schalter "-R", so wird aus der Lokalen Weiterleitung eine Remote Weiterleitung. Man kann damit dem Zielrechner die Verwendung eines lokalen Services ermöglichen.

Ein entferntes Filesystem mit SSHFS mounten

Zuerst muss SSHFS installiert und das fuse Modul geladen werden. Wie man das fuse Modul automatisch lädt kann dem Artikel Kernel Module entnommen werden.

# pacman -S sshfs
# modprobe fuse


Um nun einen entfernten Ordner zu mounten, erstellt man einen Ordner und verlinkt diesen über sshfs:

  1. mkdir ~/remote_folder
  2. sshfs USER@remote_server:/path/to/folder ~/remote_folder

Das Kommando oben wird den Ordner /tmp auf dem Server in den Ordner ~/remote_folder auf deinem lokalen Computer einhängen. Schreibvorgänge in diesem Ordner werden per SFTP ausgeführt. Mit #fusermount -u ~/remote_folder kann das entfernte Verzeichnis wieder ausgehängt werden.

Möchte man einen Eintrag in die fstab machen um das Verzeichnis automatisch beim Systemstart einzuhängen, fügt man folgende Zeile in /etc/fstab ein:

sshfs USER@remote_server:/path/to/source /path/to/target fuse    defaults,auto,allow_other    0 0

Dabei gibt /path/to/source das Verzeichnis auf dem Server und /path/to/target das lokale Verzeichnis an. Man sollte den Eintrag in die fstab mit dem Befehl # mount --all testen, da eine fehlerhafte fstab zu Problemen beim Systemstart führen kann!

Geschwindigkeitsoptimierungen

Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind Arcfour und Blowfish-CBC die besten Alternativen. Um sie zu benutzen, führt man SSH mit dem c-Flag aus:

# ssh -c arcfour,blowfish-cbc user@server-address

Um sie immer zu benutzen, fügt man diese Zeile unter dem Punkt "Host" in der /etc/ssh/ssh_config ein:

Ciphers arcfour,blowfish-cbc

Eine andere Option, die die Geschwindigkeit verbessern kann, ist das Einschalten der Kompression mit dem C-Flag. Eine dauerhafte Lösung ist es, folgende Zeile unter dem Punkt "Host" in deiner /etc/ssh/ssh_config hinzuzufügen:

Compression yes

Die Login-Zeit kann reduziert werden, wenn das 4-Flag benutzt wird. Dieses schaltet IPv6 aus. Die dauerhafte Lösung in diesem Fall ist es, folgende Zeile unter dem Punkt "Host" in deiner /etc/ssh/ssh_config hinzuzufügen:

AddressFamily inet

Ein anderer Weg um diese Änderungen dauerhaft zu machen ist, einen Alias in der ~/.bashrc (oder dem Gegenstück von anderen Shells) zu erstellen:

alias ssh='ssh -C4c arcfour,blowfish-cbc'

Man kann alle Verbindungen zu dem selben Host nur eine einzige Verbindung laufen lassen, was einen wahren Geschwindigkeitszuwachs geben sollte. Dafür fügt man folgende Zeilen in die Konfigurationsdatei /etc/ssh/ssh_config ein:

ControlMaster auto
ControlPath ~/.ssh/socket-%r@%h:%p


Problemlösungen

Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist:

ssh -X user@server-address

server$ echo $DISPLAY

localhost:10.0

server$ telnet localhost 6010

localhost/6010: lookup failure: Temporary failure in name resolution   


Wenn dieser Fehler auftaucht, solltest man localhost zu /etc/hosts hinzufügen.

Autologout verhindern

Deine SSH-Session wird nach einiger Zeit beendet, wenn man lange inaktiv war. Um dies zu verhindern, muss folgendes in die ~/.ssh/config oder in die /etc/ssh/ssh_config geschrieben werden:

ServerAliveInterval 120

Dies sendet alle 120 Sekunden ein "keep alive"-Signal zu dem Server.

Natürlich kannst du auch eingehende Verbindungen lebendig halten. Füge dafür folgendes deiner /etc/ssh/sshd_config auf dem Server hinzu:

ClientAliveInterval 120

Sichere Verbindungsdaten in der .ssh/config

Wann immer du dich zu einem Server verbinden willst, musst du zumindest dessen Adresse und deinen Benutzernamen angeben. Um dir diese Tipparbeit für regelmäßige Verbindungen zu ersparen, kannst du deine ~/.ssh/config benutzen:

Host myserver

   HostName 123.123.123.123

   Port 12345

   User bob

   # IdentityFile ~/.ssh/privater_key   #### Falls ein privater Schlüssel vorhanden ist, kann er hier angegeben werden

Host other_server

   HostName test.something.org

   User alice

   CheckHostIP no         ### Dies verhindert die Kontrolle der IP des Hosts mit der IP, die in ~/.ssh/known_hosts eingetragen wurde. Hilfreich bei Hosts hinter dynamischen IPs

   Cipher blowfish

Nun musst du nur den Namen des Servers eingeben, um dich mit ihm zu verbinden:

$ ssh myserver

Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die ssh_config Documentation auf der offiziellen Homepage.


Weblinks