Verwechslungsgefahr! SSH ermöglicht wie TLS (SSL) Public-Key-Authentifizierung und somit Schlüssel und Zertifikate. Diese sind jedoch nicht die gleichen wie bei TLS.

Failed to execute the [velocity] macro. Click on this message for details. 

Im folgenden wird OpenSSH behandelt.

  1. Konfiguration
    1. Server
    2. Client
    3. Beide
  2. Login
  3. Public Key Authentication
    1. ssh-keygen
    2. Hostkeys verwenden
    3. Identitykeys verwenden
  4. agent forwarding
  5. port forwarding  
    1. local port forwarding
    2. remote port forwarding
    3. dynamic port forwarding
  6. SFTP-Server mit Chroot
  7. Quellen und Links

Konfiguration

Server

Die Konfiguration wird ausgelesen, wobei der erste Treffer entscheidend ist, von:

  • Kommandozeilenparameter
  • /etc/ssh/sshd_config

Wichtige Parameter

Syntax: Key Value

keyOptionvalueErläuterung
 AcceptEnv  Umgebungsvariablen wie z.B. LANG, als auch Wilcards * und ? Legt fest, welche von dem Umgebungsvariablen der Client mit übertragen darf (siehe SendEnv). Standard: LANG LC_*
 AddressFamily -4 -6 [any|inet|inet6] Legt die erlaubten Adresstypen fest. IPv4, IPv6 oder beide (Standard).
 AllowGroups  Liste von Gruppennamen-Pattern (nicht GID) Login wird nur Usern ermöglicht, welche einer der gelisteten Gruppen angehören. Standardmäßig Zugriff für alle Gruppen. Priorität in der Reihenfolge: DenyUsers, AllowUsers, DenyGroups, AllowGroups
 AllowTcpForwarding  [yes|no] Legt fest, ob bei einem Tunnel der Server TCP-Anfragen weiterleitet (siehe port forwarding. TCP-Forwarding auszuschalten lohnt sich erst, wenn dem User auch der Shell-Zugriff verwehrt wird, da er so sonst jederzeit seine eigenen Forwarders anlegen kann.
 AllowUsers  Liste von Username-Pattern (nicht UID) analog zu AllowGroups
 AuthorizedKeysFile relative oder absolute Pfadangabe mit Tokens %h für User-Home und %u für Username Legt die Datei innerhalb des Users Homedirectory fest, welche die public keys der Clients zur Authentifizierung dieser enthält. Standardmäßig: ~/.ssh/authorized_keys
 Banner  absolute Pfadangabe Inhalt der Datei wird dem User vor der Authentifizierung auf der Konsole ausgegeben.
 ChallengeResponseAuthentication  [yes|no] Die Möglichkeit zur challenge-response Authentifizierung sollte auf no geschalten werden.
 Compression -C [yes|no|delayed] Legt fest, ob komprimierte Datenübertragung erlaubt ist. delayed bedeutet, das dies erst nach der authentifizierung möglich ist.
 DenyGroups Liste von Gruppennamen-Pattern (nicht GID) analog zu AllowGroups
 DenyUsers  Liste von Username-Pattern (nicht UID) analog zu AllowGroups
 GatewayPorts
[yes|no|clientspecified] Legt fest, ob entfernte Rechner auf für den Client geforwardede Ports zugreifen dürfen. Die Standardoption ist no und die forwarded Ports sind an die loopback-Adresse gebunden. Bei yes wird ssh angewiesen, die vom Client initiierten remote port forwardings an die wildcard-Adresse zu binden und so allen entfernten Systemen  die Ports zugänglich zu machen. clientspecified bedeutet, der Client darf festlegen, an welche Adresse die Ports gebunden werden.
 HostbasedAuthentication  [yes|no] Legt für die SSH-Protokollversion 2 fest, ob die Datei .rhosts sowie /etc/hosts.equiv für die Authentifizierung von Usern verwendet werden dürfen. Das Standardoption ist no und sollte aus Sicherheitsgründen auch nicht geändert werden. Das Pendant für die SSH-Protokollversion 1 ist RhostsRSAAuthentication.
 HostKey -h DateipfadangabeDateipfad zu den private keys für die Authentifizierung. Für SSH-Protokoll version 2 muss der RSA und DSA-Key angegeben werden. Standard ist /etc/ssh/ssh_host_rsa_key und /etc/ssh/host_dsa_key. Es ist zudem möglich mehrere private keys anzugeben.
 ListenAddress [host|(IPv4_addr|IPv6_addr) ][:port] Gibt ein lokales Netzwerkinterface an, an dem der SSHD lauscht. Mehrere Angaben sind möglich. Wurde kein Port angegeben, so werden alle Ports der Port-Option verwendet.
 LoginGraceTime  Zeit in Sekunden Zeit ohne erfolgreichen Login, nachdem der Server die Verbindung zum User abbricht. Standard sind 120 Sekunden, 0 bedeutet keine Zeitbegrenzung.
 LogLevel  [QUIET| FATAL| ERROR| INFO| VERBOSE| DEBUG| DEBUG1| DEBUG2| DEBUG3] Setzt das Loglevel. Standard ist INFO. DEBUG ist das gleiche wie DEBUG1. Ab dem Loglevel DEBUG werden auch private Nutzerinformationen geloggt, sodass dieses Level nicht für das Produktivsystem geeignet ist.
 Match  User, Group, Host und Address + das definierende PATTERN (siehe ssh_config) Eröffnet einen Bedingungsblock. Alles Optionen vor dem ersten Bedingungsblock sind global. Treffen alle Bedingungen in der Match-Zeile zu, überschreiben alle folgenden Optionen bis zum nächsten Bedingungsblock oder zum Dateiende die globalen Optionen.
Als folgende Optionen ist jedoch nur eine Teilmenge erlaubt. Genauere informationen siehe sshd_config
 PasswordAuthentication  [yes|no] Ob die Authentifizierung per Passwort erlaubt ist. Standardmäßig ja.
 PermitEmptyPasswords  [yes|no] Falls PasswordAuthentication (s.o.) erlaubt ist, ob leere Passwörter akzeptiert für User-Accounts akzeptiert werden. Standardmäßig nein.
 PermitOpen host:port oder [IPv4_addr| IPv6_addr]:port oder anySchränkt die Ziele für Portforwarding ein. Mehrere Ziele können getrennt durch Leerzeichen angegeben werden.Standard ist any
PermitRootLogin [yes|no|without-password|forced-commands-only] Erlaubt, sich als root am System anzumelden. Sollte unbedingt auf no gestellt werden und alternativ sollte man mit su/sudo administrative Aufgaben ausführen. Das Value without-password erlaubt den Login, jedoch ohne PasswordAuthentication. forced-commands-only erlaubt den Login, jedoch nur zur Ausführung der vorbelegten Kommandos. Standard ist yes
Port -pinteger Serverport auf dem gehorcht wird. Mehrere Angaben sind möglich. Standardport ist 22. Siehe auch ListenAddress.
 PrintLastLog [yes|no]Ob Zeit und Datum des letzten interaktiven Logins nach dem Einloggen gezeigt werden soll. Standard ist yes.
 PrintMotd   Ob nach dem Login der Inhalt von /etc/motd ausgegeben werden soll. Auf manchen Systemen geschieht dies automatisch durch die shell (/etc/profile). Standard ist yes
Protocol [1|2|1,2] Protokollversion von SSH. Nach möglichkeit immer '2' wählen.
 RevokedKeys DateipfadIn dieser Liste erwähnte public keys werden bei der Publik-Key Authentifizierung abgelehnt. Ist diese Datei jedoch nicht lesbar, werden alle User per Publik-Key Authentifizierung abgelehnt.
 RhostsRSAAuthentication  [yes|no] Pendant zu HostbasedAuthentication für SSH-Protokollversion 1
 StrictModes [yes|no]SSHD überprüft vor dem Login eines Users, ob die Dateien des Users und sein Home-Directory nicht für jedermann schreibbar sind. Da dies gerade ein Anfängerfehler ist und den Server korrumpierende Dateien dadurch geändert werden können, sollte man die Standardeinstellung yes belassen.
 TCPKeepAlive [yes|no]Der Server sendet während der Verbindung zum Client diesem in regelmäßigen Abständen keep alive messages, um zu prüfen, ob die Verbindung überhaupt noch besteht. Würde dies nicht gemacht werden, und es kommt öfters vor, dass die Verbindung von einem Client zu Server abbricht, hätte man 'ghost'-User auf dem Server, die nur Ressourcen verbrauchen. So beendet sich aber der Serverprozess nach geraumer Zeit selber. Standard ist yes und sollte es auch bleiben. (Außer wenn man Verbindungsprobleme hat und hängende Serverprozesse manuell beendet.)
 UseDNS [yes|no]Gibt an, ob der Server den remote host name auf dem DNS suchen soll und die dortige IP mit der des remote hosts abgleichen soll. Standard ist yes.
UsePrivilegeSeparation [yes|no] Erzeugt nach dem Einloggen für die Kommunikation einen Kindprozess mit den Rechten des eingeloggten Users. Sollte auf yes gestellt sein.
Beispielkonfiguration

### Authentifizierungsbelange ###

ChallengeResponseAuthentication no
HostbasedAuthentication no
PermitPasswordAuthentication yes
PermitRootLogin no
PubKeyAuthentication yes

### Sicherheitseinstellungen ###

AcceptEnv
AllowGroups <groupname>
AllowUsers <username>
AllowTcpForwarding yes
GatewayPorts no
PermitEmptyPasswords no
LoginGraceTime 15
MaxAuthTries 2
Protocol 2
StrictModes yes
UseDNS yes
UsePrivilegeSeparation yes

### sonstige Einstellungen ###

AddressFamily any
Banner /etc/issue.net
Compression yes
Port <port_number>
PrintLastLog yes
PrintMotd yes
TCPKeepAlive yes

Client

Die Konfiguration wird ausgelesen, wobei der erste Treffer entscheidend ist, von:

  • Kommandozeilenparameter
  • ~/.ssh/config
  • /etc/ssh/ssh_config

Wichtige Parameter

Syntax: Key Value

keyOptionvalueErläuterung
 BatchMode [yes|no]Passwort-Abfrage wird deaktiviert. Dies ist in Skripten nützlich, wo kein Nutzer zur Passwort-Eingabe vorhanden ist. Standard ist no.
 CheckHostIP [yes|no]Gibt an, ob der Client anhand der IP des Hosts dessen public key im known_hosts-File auf Veränderung hin prüfen soll. Standard ist yes und das sollte es auch bleiben.
 Cipher -c[blowfish|3des]Auswahl zwischen dem schnelleren Blowfish-Algorithmus und dem sichereren 3des-Algorithmus. Bei privaten und sehr schnellen Netzwerken kann man Blowfish nutzen, ansonsten den Standard 3des.
 Compression -C[yes|no]Ob der Datenverkehr komprimiert werden soll oder nicht. Standard ist no.
 Host  PATTERN oder *Ähnlich der Match-Option des Servers Beginnt ab hier bis zur nächsten Host-Option oder dem Dateiende eine Sektion von Optionen, welche nur für Hosts gelten, die dem angegebenen Pattern entsprechen. Mehrere Pattern können durch Leerzeichen getrennt angegeben werden oder * um eine globale Sektion zu eröffnen.
 DynamicForward-D[bind_address:]portSSH wird zum SOCKS-Server und forwarded alle TCP-Verbindungen an den gewählten Port zum Server weiter, wo die Anfragen schließlich bearbeitet werden. Das benutzende Programm (z.B. Firefox) muss in den Proxy-Einstellungen für den SOCKS-Server eingestellt werden, damit die getunnelte Verbindung aus dem unsicheren Netzwerk heraus auch verwendet wird. Ob der geforwardede Port für außenstehende Rechner zur verfügung steht, wird entweder über GatewayPorts festgelegt, oder durch die manuelle Angabe einer bind_address vor dem Port. Standard ist die bind_address * für alle Netzinterfaces. Für eine Einschränkung auf die lokale nutzung auf dem Rechner muss man localhost verwenden.
 GatewayPorts  äquivalent zur Serveroption GatewayPorts
 GlobalKnownHostsFile DateipfadangabePfad zu den Dateien (Kommagetrennt), in der die Fingerprints global bekannter Hosts stehen. Diese werden bei erneuter Verbindung auf Veränderung hin geprüft. Standard ist /etc/ssh/ssh_known_hosts
 HashKnownHosts  [yes|no]Die Namen und Adressen im known_hosts-File werden nur als Hash-Code hinterlegt, sodass bei Verlust des Files die kontaktierten Hosts nicht ersichtlich sind. SSH arbeitet ohnehin mit den Hash-Werten. Standard ist no und kann bei manueller Pflege des Files auch so bleiben. Auf fremden Systemen sollte hier yes eingestellt werden.
 IdentitiesOnly  [yes|no]Gibt an, ob nur die private Keys, welche in der Konfiguration mittels IdentityFile festgelegt sind, genutz werden oder auch jene, die vom ssh_agent zur Verfügung gestellt werden. Standard ist no.
 IdentityFile  DateipfadangabeLegt den Dateipfad zu den private keys mit denen sich der Client identifiziert fest und ist somit das Client-Pendant zur HostKey-Option des Servers. Standard für Protokoll sind die Optionen für ~/.ssh/id_rsa und ~/.ssh/id_dsa. Die Option kann also mehrfach erwähnt werden.
 LocalForward  siehe local port forwarding
 PasswordAuthentication  [yes|no]Ob sich mit Passwort angemeldet werden soll. Standard ist yes.
 PermitLocalCommand  [yes|no]Ob die Ausführung von Kommandos auf dem lokalen Host aus der remote console heraus über die !Kommando-Escapesequenz erlaubt ist. Standard ist no
 Port IntegerDie Portnummer, auf der der SSH-Server zu erreichen ist.
 Protocol [1|2|1,2]SSH-Protokollversion, welche genutzt werden soll. Standard ist 2 und sollte es auch bleiben.
 PubkeyAuthentication [yes|no]Ob der Client sich per publik key beim Server authentifizieren soll. Standard ist yes.
 RemoteForward  siehe remote port forwarding
 SendEnv  String; mehrere Kommagetrennt oder über mehrere Keys Legt fest, welche Umgebungsvariablen vom Client zum Host mit übertragen werden. Dies muss vom Server erlaubt werden (siehe AcceptEnv). Dabei muss nur der Name der Umgebungsvariablen angegeben werden, nicht der Wert. (sollen zum Beispiel der Standardprompt und der Standardeditor mit übernommen werden: 'SendEnv PS1 EDITOR')
 StrictHostKeyChecking   [yes|no|ask] Ist diese Option auf yes gestellt, wird SSH niemals weitere Hosts zum ~/.ssh/known_hosts File hinzufügen und sich auch nur zu Hosts aus dem known_hosts File mit gleichbleibendem Fingerprint verbinden. Neue Hosts müssen manuell hinzugefügt werden. Bei ask fragt SSH bei neuen Hosts, ob diese zum known_hosts File hinzugefügt werden soll und weigert sich zu bekannten Hosts mit verändertem Fingerprint zu verbinden. Standard ist ask.
 User StringDer User, welchen man sich auf dem SSH-Server anmelden möchte. So muss man diesen nicht immer vor die Host-IP schreiben hat aber auch weniger Sicherheit, wenn auf dem Server die DenyUsers Optionen gesetzt sind.
UserKnownHostsFile  DateipfadePfad zu den Dateien (Kommagetrennt), in der die Fingerprints dem Benutzer bekannter Hosts stehen. Diese werden bei erneuter Verbindung auf Veränderung hin geprüft. Standard ist ~/.ssh/known_hosts
Beispielkonfiguration nach obiger Serverkonfiguration

### Globale Einstellungen ###
Host *

## Sicherheit ##
CheckHostIP yes
Cipher 3des
GatewayPorts no
HashKnownHosts yes
IdentitiesOnly yes
PermitLocalCommand no
StrictHostKeyChecking

## Sonstiges ##
Compression yes
Port <port_number>

Verschlüsselung

Prinzipiell unterscheidet man zwei Arten der Verschlüsselung der Nutzdaten:

  • 3des sehr sicher; benötigt viel Rechenzeit; sollte dennoch Standard sein
  • blowfish schnell; für Ausnahmen in nichtkritischen Netzen und Austausch großer Datenmengen und CPU-Limitierung

Über folgende Varianten kann man zum Beispiel zum blowfish-Algorithmus wechseln:

  • ssh -c blowfish ... für einmaligen Algorithmuswechsel
  • ssh -o Cipher=blowfish ... gleiches als Optionsparameter
  • Option Cipher blowfish in einer der Konfigurationsdateien für permamente Algorithmusauswahl

Beide

Komprimierung

Hierbei lässt sich der Traffic auf etwa 50% der Netz-Pakete einsparen. Über Tunneling lässt sich zudem so jede P2P-Verbindung beschleunigen - auch ohne Verschlüsselung.

  • ssh -C
  • ssh -o Compression=yes
  • Option Compression yes in einer der Konfigurationsdateien, auf jeden Fall aber auf dem Server

Die Option muss auf dem Server erlaubt sein (siehe Compression), wenn man vor hat, Komprimierung zu benutzen.

Login

Je nach Einsatz von Parametern und Syntax gibt es unterschiedliche Varianten zur Anmeldung. Der Hostname ist obligatorisch, der Username kann wie folgt angegeben werden:

  • ssh -l <username> <hostname> (über den Parameter -l)
  • ssh <username>@<hostname> (die einfache und gebräuchliche Syntax)
  • ssh -o User=<username> <hostname> (über den Optionsparameter -o)
  • ssh <hostname> und der Option User <hostname> in der config-Datei

Public Key Authentication

Die PublicKey-Authentifizierung basiert auf asymmetrischer Verschlüsselung, wobei ein Rechner für sich einen privaten und einen öffentlichen Schlüssel erstellt. Dieses Schlüsselpaar gehört zusammen, denn mit dem 'public key' können Informationen verschlüsselt und nur mit dem 'private key' wieder entschlüsselt werden (deswegen auch asymmetrisch). Der zu authentifizierende Rechner gibt nun nach außen seinen public key preis. Ist er also in der Lage mit diesem verschlüsselte Nachrichten zu entschlüsseln, hat er damit seine Identität bewiesen.

ssh-keygen

Schlüsselpaar (Private Key und Public Key) mit ssh-keygen erstellen.

Hostkeys verwenden

Szenario: der Client authentifiziert den Server, zu dem er sich verbindet, anhand dessen (vorher auf dem Client abgespeichertem) Public Key.

Client: Angabe des Public Keys der vertrauten Server auf dem Client unter:

  • Konfigurationsdatei: GlobalKnownHostsFile
  • Konfigurationsdatei: UserKnownHostsFile
    Standardpfade sind:
  • ~/.ssh/known_hosts - Userdatei bekannter Hosts
  • /etc/ssh/ssh_known_hosts - Globale Datei bekannter Hosts
Nicht die known_hosts-Datei überschreiben, sonder um den Inhalt des Public Keys zeilenweise erweitern.

Server: die auf dem Client benötigten Hostkeys befinden sich auf dem Server an folgenden Stellen

  • die Option -h host_key_file
  • Konfigurationsdatei: HostKey
    Standardpfade sind:
  • (/etc/ssh/ssh_host_key für SSH-Protokollversion 1)
  • /etc/ssh/ssh_host_rsa_key für RSA und SSH-Protokollversion 2
  • /etc/ssh/ssh_host_dsa_key für DSA und SSH-Protokollversion 2

Identitykeys verwenden

Szenario: Alternativ zum Passwort authentifiziert der Server den Client anhand dessen hinterlegtem Public Key.

Client: die auf dem Server zu hinterlegenden Identitäten (Public Keys) befinden sich auf dem Client an folgenden Stellen

  • Pfadangabe über die Option -i
  • Konfigurationsdatei: IdentityFile
    Standardpfade sind:
  • (~/.ssh/identity für SSH-Protokollversion 1)
  • ~/.ssh/id_rsa für RSA und SSH-Protokollversion 2
  • ~/.ssh/id_dsa für DSA und SSH-Protokollversion 2

Server: Angabe der zugangsberechtigten Identitäten der Clients unter:

  • Konfigurationsdatei: AuthorizedKeysFile
    Standardpfade sind:
  • ~/.ssh/authorized_keys - für den jeweiligen Nutzer der Secure Shell auf dem Server
Nicht die authorized_keys-Datei überschreiben, sonder um den Inhalt des Public Keys zeilenweise erweitern.

Vom Client aus können Public Keys auch mit folgendem Befehl per ssh installiert werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub <ssh_user>@<server>

Aufbau (public key)

Der public key (z.B. ~/ssh/id_rsa.pub)

  1. key-Typ (ssh-rsa|ssh-dsa)
  2. ein Leerzeichen
  3. Modulus (der Informationsträger, eine lange Folge von Zeichen)
  4. optional ein von einem Leerzeichen eingeleuteter Kommentar

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxtWFO8XbyT6+IlBAWYyOb/VWraJ7iymKVsb0TNmieBSzF6fgustkT0nX3udbSqTqiECwXFKqeyl27bkd+rEcFba+s+wgv9MKRaiV0kOFVQrAvwrKnS1QI6YZWZIhSP7KS5QE0HRra+gy/47vGwHUn0RxksGOQ6YsKP5lNN8H3E= user@host

Beide besitzen zudem einen Fingerprint, welcher gerne als Kurzform zur Bezeichnung der Schlüssel angegeben wird als auch ihre Zusammenhänigkeit darstellt, da dieser für public key und private key gleich ist. Den Fingerprint kann man sich mit ssh-keygen ausgeben lassen:

$ ssh-keygen -l -f .ssh/id_rsa
1024 5a:b6:c4:50:ce:ec:18:78:e9:b2:e7:5b:04:c2:e4:c7 .ssh/id_rsa.pub

agent forwarding

Erlaubt das Hopping per SSH über mehrere Hosts, wobei bei jedem Hop die Keys zur Authentifizierung vom ersten Rechner aus verwendet werden. Eine Beispielkonfiguration für ~/.ssh/config:

Host bastion
  Hostname bastion.myserver.net
  User frankfrei
  IdentityFile ~/.ssh/id_rsa
  ForwardAgent yes

Host mywebserver
  Hostname www.myserver.net
  User wwwadmin
  IdentityFile ~/.ssh/mywebserver.pem
  ProxyCommand ssh bastion -W %h:%p
  • Angenommen nur über den Bastion-Server kann auf den Webserver zugegriffen werden.
  • Der SSH-Agent, welcher sich um die Authentifizierung kümmert, wird auf den bastion geforwarded.
  • Bei einer Verbindung zu mywebserver wird durch den ProxyCommand automatisch ein Tunnel über den bastion aufgebaut.
  • Durch den geforwardeden SSH-Agent kann sich an mywebserver auch mit dem lokalen mywebserver.pem-Key authentifiziert werden.

port forwarding  

Mittels Portforwarding kann man Dienstanfragen, wie zum Beispiel das Aufrufen einer Website, über einen SSH-Tunnel an einen entfernten Server verlagern. So werden zum Beispiel eventuelle Firewall-Beschränkungen aufgehoben, sofern man den SSH-Tunnel an sich aufbauen kann. Im folgenden wird ein Überblick über die verschiedenen Portforwarding-Varianten gegeben.

Möchte man nach Aufbau des SSH-Tunnels und Einrichtung des Portforwardings auf der aktuellen Konsole weiterarbeiten, muss man ssh zusätzlich die Optionen -f -N vorangestellt werden.
  • -f befördert den SSH-Tunnel nach der Passworteingabe in den Hintergrund
  • -N besagt dass nach Verbindungsaufbau keine Kommandos ausgeführt werden sollen/müssen

So würde ein Befehl zum Portforwarding zum Beispiel wie ssh -fNL 4321:www.google.de:80 maxmuster@myserver.de aussehen.

local port forwarding

Anstatt sich direkt mit einem Server im Internet zu verbinden, schaltet man einen Tunnel zwischen SSH-Client und SSH-Server davor und greift über den 'Eingang' des Tunnels, also über Adresse und Port des Clients, auf den Webserver zu. Diese Brücke schlägt man im einfachsten Fall mit dem Befehl

$ ssh -L 4321:www.google.de:80 <username>@<ssh_hostname>

  • -L forwarded den Port 4321 des Clients über den SSH-Tunnel, also über den SSH-Server, zu dem übergebenen Host (www.google.de) und Port (80)

Anstatt http://www.google.de nun direkt auzurufen, kann man die Website nun über http://localhost:4321 aufrufen und arbeitet dabei über Port 22 (SSH) anstatt über Port 80 (TCP). Denn technisch gesehen wird ein Socket vom Betriebssystem angefordert, der auf dem gewünschten lokalen Port (4321) lauscht. Eingehende Anfragen werden dann über den SSH-Tunnel (Port 22) an den SSH-Server weitergeleitet, der die Anfrage dann an den gewünschten Host (www.google.de) forwarded. Man spricht hier insgesamt von einem Tunnel von localhost:4321 auf www.google.de:80. Für das Öffnen eines Ports <1024 benötigt man root-Rechte.

 Damit der SSH-Server seinen Dienst nicht verweigert, muss die Option AllowTcpForwarding auf yes gestellt sein.

Nun möchte man aber unter Umständen auch außerhalb des Clients auf dessen Port 4321 zugreifen, um dessen Port zu nutzen. Derzeit kann man den Port nämlich nur über localhost bzw. 127.0.0.1 erreichen. Dazu erlaubt mit der zusätzlichen Option -g auch entfernten Rechnern über des Clients offene Netzinterfaces auf dessen forwarded Port zuzugreifen. Mit dem Kommando

$ ssh -g -L 4321:www.google.de:80 <username>@<ssh_hostname>

sowie der Client-IP 192.168.0.5 im lokalen Netzwerk bzw. dessen Netzwerkname mars, ist http://www.google.de innerhalb des LANs auch über http://192.168.0.5:4321 beziehungsweise http://mars:4321 erreichbar. SSH versucht den lokalen Port dabei über alle Interfaces des Clients zu forwarden. Ist jedoch eines dieser Interfaces nicht verfügbar, informiert SSH auf der Konsole mit bind: Address already in use, was jedoch zumeist nicht weiter schlimm ist, da die loopback-Adresse sowie die IPv4-Adressen der angeschlossenen Netzwerkkarten meistens nicht davon betroffen sind.

Möchte man jedoch die bind address genau festlegen, gibt man diese mit Doppelpunkt getrennt vor dem lokalen Port an:

$ ssh -L <bind_address>:4321:www.google.de:80 <username>@<ssh_hostname>

Hierbei wird die Option -g unbrauchbar, da man nun selber die bind adress festlegt. Ist diese localhost, so ist der Port für entfernte Rechner auch nicht sichtbar. Im Falle der Netzwerkadresse des Clients jedoch schon. Zudem kann man auch hier die Wildcard * eintragen, wobei der Port dann wieder für alle Interfaces verfügbar ist.

remote port forwarding

Den umgedrehten Weg des local port forwarding geht remote port forwarding. Diesmal lauscht der Server, über einen Tunnel verbunden mit dem Client, auf Anfragen an einem seiner Ports und leitet diese weiter an den Client. Dieser wiederum forwarded die Anfrage an den gewünschten Zielhost/-Port. So ist es möglich, bei der Fernarbeit auf dem remote host trotzdem auf Resourcen des Clients zugreifen zu können, die so aus dem lokalen Netzwerk heraus nicht sichtbar sind. Trotzdem wird der Tunnel vom Client aus eingerichtet:

$ ssh -R 4321:www.google.de:80 <username>@<ssh_hostname>

Der Unterschied ist äußerst geringfügig und besteht im wesentlichen aus der Option -R anstatt -L. Zudem ist der Port 4321 der Port auf dem Server auf dem gehorcht wird. Auch hier bedarf es root-Rechten, möchte man einen Port < 1024 öffnen. Um den root-Zugriff per ssh zu umgehen, legt man den Tunnel auf einen port >=1024 und leitet den kleineren Port per xinetd, netcat oder Firewall auf diesen um.

Das Pendant zur Option -g um den Listener-Port des Clients über ein offenes Netzinterface auch entfernten Rechnern zur Verfügung zu stellen ist auf dem Server die Option GatewayPorts yes. Ist diese Option jedoch auf clientspecified gestellt, darf der Client wieder per bind address das Interface (oder per Wildcard * alle Interfaces) für den Port festlegen:

$ ssh -R <bind_address>4321:www.google.de:80 <username>@<ssh_hostname>

dynamic port forwarding

Nun wünscht man sich vielleicht auf dem Client mehr als nur die Dienste eines Servers zu forwarden und will alle Anfragen in das Netz forwarden. Hierbei kann man einen einen forward-Tunnel zum entfernten Server zu dem lokalen SOCKS-Protokoll aufbauen. Soll dann eine Anwendung alle Anfragen an den Server forwarden, muss sie dazu nur den im tunnel eingestellten lokalen SOCKS-Port nutzen. Zunächst erst einmal der Aufbau des forwarding-Tunnels zwischen lokalem SOCKS-Port und dem SSH-Server

$ ssh -D 4321 <username>@<ssh_hostname>

Wir sehen, dass zur Verbindungsherstellung nur noch ein Port angegeben werden muss. Alle anderen Adressangaben sind frei - also dynamisch. Möchten wir nun clientseitig das Forwarding nutzen, müssen wir das jeweilige Programm auf den SOCKS-Proxy einstellen oder falls das Programm diese Einstellung nicht bietet, mit einem Client-Tool Anfragen der Software abfangen und an den SOCKS-Proxy umleiten. Erstere Variante erlaubt uns zum Beispiel Firefox. Hier können wir in den erweiterten Einstellungen die Internetverbindung selber festlegen.

Firefox-SOCKS-Setting

Als zweite Variante bietet sich ein Tool an, welches die Verbindungen eines Programmes Abfängt und zum Proxy umleitet. Zu erwähnen wäre für Windows das einfache aber funktionale Tool SocksCap. Hierin erstellen wir einfach eine Verknüpfung zur ausführbaren Datei der Software samt angabe des Arbeitsverzeichnisses (diese Angaben findet man zumeist bequem in der Startmenüverknüpfung) und startet die Software anschließend immer aus dem SocksCap-Tool heraus, wenn man den Proxy-Tunnel wünscht.

SocksCap-Settings

SFTP-Server mit Chroot

  • der Open-SSH-Server erlaubt automatisch Zugriff per ssh://<user>@<server-ip>:<port>
  • möchte man jemandem eingeschränkten SSH-Zugriff geben, so sieht der Benutzer zunächst jedoch alle Pfade, für welche er Leserechte hat
  • im folgenden soll der Zugriff auf das Home-Verzeichnis beschränkt werden, in welchem der Website-Ordner von Apache gemountet ist
  • zunächst wird OpenSSH entsprechend konfiguriert:

/etc/ssh/sshd_config

#Subsystem      sftp    /usr/lib64/misc/sftp-server
Subsystem       sftp    internal-sftp

Match Group sftponly
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
        X11Forwarding no
        AllowTcpForwarding no 
  • anschließend wird die in der Konfiguration erwähnte Gruppe erstellt, optional der Benutzer erstellt und der Gruppe hinzugefügt
groupadd sftponly
adduser ftpuser
usermod -aG sftponly ftpuser 
  • mit der chroot-Einschränkung soll der Nutzer nicht in sein Home-Verzeichnis schreiben dürfen
  • daher werden die Rechte entsprechend eingeschränkt und der Arbeitsordner /var/www von Apache in das Home-Verzeichnis gemountet
chown root:sftponly /home/ftpuser
chmod 750 /home/ftpuser
chown -R ftpuser:ftpuser /var/www
mkdir /home/ftpuser/www
mount --bind /var/www/ /home/ftpuser/www/
  • soll der Mount auch nach einem Neustart vorhanden sein, muss folgender Eintrag in der /etc/fstab getätigt werden
/var/www /home/ftpuser/www auto bind 0 0

Quellen und Links

Erstellt von thomass am 2014/07/31 12:53
    
Copyright 2004-2018 XWiki
7.4.5