OpenSSH

#OpenSSH #Man-in-the-Middle #Hash #Integrität #telnet #ftp

Table of Contents

Grundlagen

OpenSSH basiert auf dem letzten freien Free SSH 1.2.12 Release von Tatu Ylönen. implementiert aber die Kryptobibliotheken des OpenSSL Projektes. Es ist eine Entwicklung des OpenBSD Teams und unter der BSD Lizenz erhältlich. SSH ist ein Standard der die IP Kommunikation über einen verschlüsselten Tunnel leitet und somit Sniffing und Connection Hijacking verhindert, sowie DNS Spoofing verhindern kann, da sich die Partner (meist per Schlüssel) authentifizieren müssen.

OpenSSH beherrscht die in diversen IETF festgeschriebenen Protokolle 1 und 2 sowie kommt mit einem Server (sshd) dem Client ssh und dem SecureFTP Subsystem im Daemon und dem entsprechende sftp Client.

Da OpenSSH wie OpenBSD ausserhalb der USA in Kanada, Holland und Deutschland gehostet ist, unterliegt es nicht dem Zugriff der US Export- und Schnüffelbestimmungen. OpenSSH ist eigentlich für OpenBSD gedacht, allerdings wurde es inzwischen schon auf zahlreiche Unices portiert und als Package aufbereitet (diese sind an dem p in der Versionsnummer zu erkennen) Es werden in der 1. Version die Cipher 3DES und Blowfish und in der 2. Protokollversion die Cipher 3des-cbc, blowfish-cbc, cast128-cbc, arcfour, aes128-cbc, aes192-cbc, aes256-cbc, rijndael128-cbc, rijndael192-cbc, rijndael256-cbc, rijndael-cbc@lysator.liu.se unterstützt.

Ebenso erlaubt OpennSSH das bequeme forwarden von X Programmen und die Kompression der übertragenen Daten. Die Authentifizierung der Hosts erfolgt erfolgt (idealerweise) mittels der Schlüssel, welche jedes SSH erzeugt. Es gibt wie bei jedem asymmetrischen Chiffreverfahren einen öffentlichen und einen privaten Schlüssel, die öffentlichen Schlüssel werden untereinander ausgetauscht und mit dem Geheimen zusammen zur Verschlüsselung benutzt. Verwendet werden RSA1 Schlüssel für Protokoll 1 und RSA/DSA Schlüssel für Protokoll 2. Beim erstmaligen Login zeigt SSH den Key-Fingerprint an und fragt ob er gültig ist. Der Fingerprint ist eine mathematische Prüfsumme über dem Schlüssel und beweist ähnlich einer Signatur das dieser Schlüssel auch der ist, der er, vorgibt zu sein. Es wird somit quasi unmöglich einen falschen Server per manipuliertem DNS vorzutäuschen (spoofen), da es bisher unmöglich ist einen Schlüssel mit bestimmtem Fingerprint zu erzeugen (kompromittierung des Servers und übernahme der Schlüssel seien außer Acht gelassen.)

Ein Beispiel-Login mit Fingerprint:

bash-2.05$ ssh USER@server.de
The authenticity of host 'server.de (123.245.1.32)' can't be established.
DSA key fingerprint is d5:02:31:d4:d6:79:d6:61:b6:57:71:6e:97:5d:2d:a8.
Are you sure you want to continue connecting (yes/no)?

Wird dies bestätigt, wird der öffentliche Schlüssel des Server in der Datei ~/.ssh/known_hosts gecached. Sollten sich änderungen ergeben, warnt SSH aufdringlich beim Login und man sollte sich den neuen Fingerprint vom Admin des Servers, z.B. per Telefon, verifizieren lassen. Das Format des Caches des 2er Protokoll sieht folgendermaßen aus:

DNS-Name, IP-Adresse ssh-rsa Schlüssel-Kauderwelsch

Grundprinzip

OpenSSH läuft auf dem gewünschten Server als Daemon und erzeugt beim ersten Start (oder per Befehl) mehrere Schlüssel. SSH verschlüsselt asymmetrisch, d.h. es werden wie z.B. bei GPG ein öffentlicher und ein privater Schlüssel erzeugt. Der Server nimmt standardmäßig auf Port 22 Verbindungen des Clients entgegen. Der Client sendet beim ersten Kontakt seinen öffentlichen Schlüssel und der Server beantwortet diese Anfrage bereits verschlüsselt. Nun folgt entweder eine Passwortabfrage oder die Authentifizierung erfolgte bereits per Schlüssel. Standarmäßig startet OpenSSH nun auf dem Server eine Login-Shell, dies ist aber nicht zwingend nötig. Man kann mittels OpenSSH auch verschlüsselte Tunnel über einen SSH-Server bauen. Als Beispiel soll hier mein Uni-Newsserver dienen, welcher nur IP-Adressen aus dem internen Uni-Netz zulässt. Als Zugang stehen den Studenten und Mitarbeitern mehrere Rechner mit SSH zur Verfügung (hier z. B. connect6.urz.uni-magdeburg.de). Dieser Connect-Rechner wird nun als Tunnel zum Newsserver benutzt.

Dies geschieht per Port-Weiterleitung mit dem Befehl:

# ssh -2 -C -c rijndael256-cbc 	BENUTZER@connect6.urz.uni-magdeburg.de -L 50000:news.cs.uni-magdeburg.de:119

Im einzelnen bedeutet dies: Protokoll 2, Komprimierung, Rijndael-256cbc als Kryptoalgorithmus danach Benutzer@Server und zuletzt soll der entfernte Port 119 des Newsserver auf den eigenen Port 50000 gemappt werden.

Nun kann man einen Newsreader an den eigenen Localhost:50000 binden und dieser wird dann von OpenSSH verschlüsselt auf den Uni-Newsserver getunnelt. Dies funktioniert z. B. auch um von außen auf den Mailserver im Firmennetzwerk zuzugreifen oder verschlüsselt ein X Login (natürlich per KDM mit 1600x1200@24bpp Hintergrund-Bitmap ;-) zu erhalten.

Ebenso gefährlich wie ein telnet oder rlogin ist das "gute" alte FTP. Hier gehen wieder Login und Passwort im Klartext über den äther. Dies muß nicht sein, den OpenSSH bietet sowohl einen verschlüsselten SecureFTP Dameon als auch den passenden sftp Client. Der Server ist sehr einfach aus der sshd.conf zu starten. Der Client funktioniert wie "normales" FTP mit sftp User@Server

Es existieren auch diverse freie SSH-Clients, wie z.B. PuTTy für Win32.

Die Installation:

Für die meisten Systeme kommt OpenSSH schon als Package oder Port, so das z.B. ein cd /usr/pkgsrc/security/openssh/ && make fetch-list | sh && make && make install ausreichen sollte, um es zu installieren (oder per rpm -i Openssh***.rpm) Wesentlich wichtiger als die relativ einfache Installation ist die Konfiguration. Es gibt zwei Möglichkeiten den OpenSSH Daemon zu starten, einmal per Systemstart via /etc/rc.conf oder per (x)inetd. Da der Start per inetd bei jedem mal neue Schlüssel generiert ist dies nicht zu empfehlen, kann aber bspw. als Fallbacklösung implementiert werden um z.B. bei einem (sehr seltenen) Absturz des sshd eine Möglichkeit des Einloggens zu haben (er muß dann allerdings an einen anderen Port gebunden werden)

Konfigurationshinweise:

Aus Sicherheitsgründen sollte nur noch die Protokollversion 2 eingesetzt werden. Die Version 1 ist aufgrund der Verwendung vom relativ schwachen CRC-32 (Cyclic Redundancy Check mit 32 Bit) anfällig für einen Man in the Middle Angriff in dem gefälschte Pakete in die Verbindung eingespooft werden können. Ein Patch der dies erkennen soll SSH CRC32 attack detection) enthält einen Buffer Overflow der Angriffstufe root-exploitable. Es ist eine bekannte Tatsache das viele Angreifer nur einen großangelegten Scan nach bekannten exploited Diensten fahren und wahllos diese Rechner attackieren. Version 2 verwendete einen Keyed Hashing for Message Authentication Algorithmus (siehe RFC 2104) Es ist generell sehr wichtig bei solchen Diensten bekannte Exploit/Security Listen zu lesen und unverzüglich die angebotenen Patches/Updates zu installieren. Bewiesen hat dies der erst kürzlich gefundene "Off-by-One Error" der eingeloggten User einen root-exploit ermöglicht und alle OpenSSH Versionen bis 3.0.2 befallen hat. <a href="http://www.openssh.org/de/security.html">OpenSSH Security Advisories</a> Soll der sshd erst getestet werden, ist es vielleicht von Vorteil die Optionen per Kommandozeile zu übergeben. Es ist ohne weiteres möglich eine funktionierenden sshd zu verwenden und den experimentellen an einen anderen Port zu binden und auszutesten, bis er funktioniert. Eine weitere Sicherheitsverbesserung ist der Verzicht auf das Login per Passwort und der Einsatz von Schlüssel-basierten Logins. Dazu muß PubKeyAuthentication angestellt werden. Der sshd verfügt dann über die öffentlichen Schlüssel der Benutzer und Authentifiziert diese beim Login mittels ihrer Privaten. Somit sind die Schwächen eines Passworts ausgemerzt, allerdings sollten die Schlüssel auf dem Host entsprechend geschützt werden, z. B. in einem verschlüsseltem Dateisystem wie CFS.

Konfiguration des Servers

In /etc/sshd.conf bzw, teilweise mittels Parameterübergabe:

  • AFSTokenPassing

    • Default: Yes, gibt an ob eine AFS Token zum Server geforwardet werden soll

  • AllowGroups

    • Gruppen die sich einloggen dürfen. Wenn aktiviert, dürfen sich auch nur diese Gruppen einloggen Joker wie ? und * sind erlaubt, GID sind nicht gestattet.

  • AllowTcpForwarding

    • Erlaubt TCP-Forwarding

  • AllowUsers

    • Erlaube folgende Benutzernamen, Joker sind gestattet, wenn aktiviert, können sich andere Benutzer nicht einloggen. AuthorizedKeysFile spezifiziert die Datei, die den öffentlich Schlüssel eines Benutzers enthält. Standardeinstellung ist .ssh/authorized_keys. Joker der folgenden Form sind erlaubt

      %% = %
      %h = Home-Verzeichnis
      %u = Username
  • Banner

    • Banner gibt den Text in der angegebenen Datei vor dem Login wider. Kann teilweise Notwendig sein um z. B. juristische Warnungen auszugeben Nur in Protokoll 2, Standardmäßig abgeschaltet

  • ChallengeResponseAuthentication

    • erlaubt challenge response Authentifizierung, Standard ist ja Alle Authentifizierungen aus login.conf(5) werden unterstützt

  • Ciphers

    • Spezifiziert die Cipher (Kryptoalgorithmen) für Protokoll 2 Standard ist: ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc''

  • ClientAliveInterval

    • Zeitintervall während dem keine Daten übertragen werden. Der Daemon überprüft dann ob der Client noch Lebt. 0 bedeutet keine überprüfung, nur in Protokoll 2

  • ClientAliveCountMax

    • Anzahl der überprüfungen des Client (siehe ClientAliveInterval) bevor der Client gekappt und die Session beendet wird. Die ClientAlive Meldungen werden im verschlüsselten SSH Kanal übertragen und sind somit im Gegensatz zu KeepAlive nicht spoofable. Standard ist 3 Beispiel: ClientAliveInterval auf 15 und ClientAliveCountMax 3 bedeutet ein Ende der Session nach 45 Sekunden Idle-Time

  • DenyGroups

    • Verbiete Gruppen, Joker erlaubt, GID nicht erlaubt, Standard ist "keine"

  • DenyUsers

    • Verbiete Benutzer, Joker erlaubt, GID nicht erlaubt, Standard ist "keine" Die Form User@Host ist erlaubt und verbietet nur diesen User an jenem Host

  • PubkeyAuthentication

    • Spezifiziert ob Public Key Authentifizierung erlaubt ist, Standard ist ja, nur Protokoll 2

  • GatewayPorts

    • Spezifiziert ob entfernte Hosts sich an geforwardete Ports des Client binden dürfen

  • HostKey Parameter: -h

    • Gibt die Datei an die die privaten Server-Schlüssel enthalten. Standard ist /etc/ssh_host_key) sshd verweigert Datein die Group/World Zugriffe erlauben. Mehrere Dateien sind möglich.

  • IgnoreRhosts

    • .rhosts und .shosts Dateine solen ignoriert werden, /etc/hosts.equiv und /etc/shosts.equiv werden trotzdem ausgewertet, Standard ist ja

  • IgnoreUserKnownHosts

    • Spezifiziert ob sshd $HOME/.ssh/known_hosts des Benutzers während der RhostsRSAAuthentication beachten soll. Standard ist Nein.

  • KeepAlive

    • Gibt an ob KeepAlive Meldungen gesendet werden sollen. Dies ermöglicht die überprüfung der Verbindung und und tötet die Session wenn die Verbindung abbricht und verhindert somit Geisterprozesse Standard ist ja, zum abschalten müssen Client und Server auf nein stehen.

  • KerberosAuthentication

    • Spezifiziert ob Kerberos-Authentifizierung erlaubt ist. Standard ist ja, der Server benötigt eine Kerberos Servtab welche die Authentifizierung der KDC Identität erlaubt. Die Identifizierung erfolgt mittels Kerberos Ticket oder Passwort.

  • KerberosOrLocalPasswd

    • Standard ist ja, ermöglicht die Authentifizierung des Benutzers durch z.B. /etc/passwd wenn die Kerberosauthentifizierung fehlschlägt.

  • KerberosTgtPassing

    • Gibt an ob ein Kerberos TGT an den Server geforwardet werden soll. Standard ist nein, es funktioniert nur wenn die Kerberos KDC ein AFS kaserver ist.

  • KerberosTicketCleanup

    • Gibt an ob das User Ticket beim Logout vernichtet werden soll. Standard ist ja.

  • KeyRegenerationInterval Parameter -k

    • Zeit in Sekunden, nach der der private Server Schlüssel regeneriert wird. Standard ist 3600 Dies soll verhindern das aufgezeichnete Sessions mit einem gestohlenen Serverkey entschlüsselt werden können. Der Schlüssel wird nicht gespeichert.

  • ListenAddress

    • Definiert die Adresse an die sich der sshd binden soll. Standardmäßig bindet sich der sshd an alle Interfaces. Mehrere Angaben sind möglich.

  • LoginGraceTime, Parameter: -g

    • Der Server beendet ein Login wenn innerhalb dieser Zeit keine Authentifizierung stattgefunden hat. Standard sind 600 Sekunden, 0 bedeutet keine Begrenzung.

  • LogLevel

    • Verbosemodus ("Auskunftsfreudigkeit") dess sshd wenn mitgeloggt wird. Optionen: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. Standard ist INFO. DEBUG verletzt die Privatsphäre der User und ist nicht empfohlen.

  • MACs

    • Gibt die MACs (Message Authentication Code) Algorithmen an. Dies wird in Protokoll 2 benutzt um die Integrität der übertragung zu schützen. Mehrere Algorithmen können per Komma-getrennter Liste angegeben werden. Standard ist: ``hmac-sha1,hmac-md5,hmac-ripemd160, hmac-ripemd160@openssh.com, hmac-sha1-96,hmac-md5-96''

  • MaxStartups

    • Gibt die maximale Anzahl von konkurrierenden und unauthentifizierten Verbindungen zum sshd an. Zusätzliche Verbindungen werden gedropped. Standard ist 10

  • PasswordAuthentication

    • Gibt an ob die Authentifizierung via Passwort erlaubt ist. Standard ist ja, Gilt für beide Protokolle.

  • PermitEmptyPasswords

    • Erlaubt leere Passwörter. Standard ist nein.

  • PermitRootLogin

    • Gibt an ob sich root per ssh einloggen kann. Standard ist ja, Mögliche Argumente sind: yes - login erlaubt without-password - Password Authentifizierung abgeschaltet für root. forced-commands-only - root Login mit Public Key Authentifizieruung ist erlaubt. aber nur wenn der Command Modus übergeben wurde (nützlich um z.B. remote-Backups zu erlauben)

  • PidFile

    • Gibt die Datei an, die die Prozess ID (pid) des sshd enthält. Standard ist /var/run/sshd.pid

  • Port Parameter: -p

    • Gibt den Port an, an den sich der sshd binden soll. Standard ist 22, mehrere Ports können übergeben werden.

  • PrintMotd

    • Gibt an ob sshd beim Login /etc/motd ausgeben soll. Wird auf manchen System bereits von der Shell übernommen Standard ist ja.

  • Protocol

    • Gibt die Protokollversionen an, Standard ist 1, 1,2 erlaubt 1 und 2

  • PubKeyAthentication

    • Erlaubt das Login per Schlüssel. RandomSeed Veraltet, Zufallsgeneratoren benutzen andere Techniken.

  • ReverseMappingCheck

    • sshd überprüft ob der Clienthostname auf die übertragene IP passt. Standard ist nein.

  • RhostsAuthentication

    • Erlaubt rhosts-Authentifizierung mittels .rhosts oder /etc/hosts.equiv Standard ist nein.

  • RhostsRSAAuthentication

    • Erlaubt rhosts-Authentifizierung mittels .rhosts oder /etc/hosts.equiv und RSA Host-Authentifizierung Standard ist nein.

  • RSAAuthentication

    • Gibt an das reine RSA Authentifizierung erlaubt ist. Standard ist ja, betrifft nur Protokoll 1.

  • ServerKeyBits

    • Gibt die Größe der Serverschlüssels in Bit an. Minimum ist 512, Standard ist 768

  • StrictModes

    • Gibt an ob sshd Owner und Modes der Dateien checken soll. Anfänger lassen ihre Dateien manchmal World-writable, Standard ist ja.

  • Subsystem

    • Speizifiziert ein externes Subsystem (z.B. Secure FTP). Optionen sind ein Subsystem Name und der Befehl der bei einem Request ausgeführt werden soll. Beispiel sftp: Subsystem sftp /usr/libexec/sftp-server

  • SyslogFacility

    • übergibt den facility code an sylogd, Optionen sind DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 Standard ist AUTH.

  • UseLogin

    • Login(1) soll für interaktive Logins benutzt werden. Login wird nicht für remote Befehle verwendet. Standard ist Nein

  • X11DisplayOffset

    • Spezifiziert die erste Displaynummer für X11 forwarding, um Probleme mit echten X11 Servern zu vermeiden. Standard ist 10.

  • X11Forwarding

    • Gibt an ob X11 Forwarding erlaubt werden soll. Standard ist nein. Das Verbieten erhöht die Sicherheit nicht da die User eigene Forwarder installieren können.

  • XAuthLocation

    • Gibt den Ort des xauth(1) Programm. Standard ist /usr/X11R6/bin/xauth.

Konfiguration des Client

Der OpenSSH-client (ssh) bezieht seine Konfigurationsdaten in folgender Reihenfolge:

  1. Kommandozeile

  2. $HOME/.ssh/config

  3. /etc/ssh.conf

  4. Parameter

    • Host

      • Begrenzt bis zu nächsten "Host" die Regeln auf den übergebenen Host. Jokerzeichen * und ? sind erlaubt

    • AFSTokenPassing

      • siehe sshd

    • BatchMode

      • Wenn auf ja gesetzt, wird kein Passwort hinterfragt. Nützlich in Shellscripts vor allem in Verbindung mit schlüsselbasierter Authentifikation.

    • CheckHostIP

      • Wenn aktiviert wird ssh zusätzlich die IP Adresse mit der in known_hosts vergleichen. Dies ermöglicht es gespoofte Verbindungen anhand des Keyfingerprints zu erkennen.

    • Cipher

      • Zu verwendender Verschlüsselungsalgorithmus in Protokoll 1

    • Ciphers

      • Zu verwendender Verschlüsselungsalgorithmus in Protokoll 1

    • Compression

      • Spezifiert ob Kompression eingeschaltet werden soll.

    • CompressionLevel

      • Komprimierungsrate falls Komprimierung eingeschaltet ist. Rate geht von 1 (wenig&schnell bis 9 hoch&langsam)

    • ConnectionAttempts

      • Anzahl der Verbindungsversuche (1 pro Sekunde) bevor auf RSH zurückgeschaltet oder abgebrochen wird. NBützlich vao allen in Scripts.

    • PubkeyAuthentication

      • Gibta an ob die Authentifizierung per Schlüssel erfolgen soll, betrifft nur Protokoll 2.

    • EscapeChar

      • Definiert den Escapecharacter. (Standard: `~'), möglichst ein Character. Anpassungen können teilweise für binary-Daten notwendig sein.

    • FallBackToRsh

      • Spezifiziert ob auf RSH (unverschlüsselt!) zurückgegangen werden soll falls die ssh Verbindung nicht zustande kommt.

    • ForwardAgent

      • Spezifiziert ob die Verbindung zum Authentication Agent zur entfernten Maschine forwarded werden soll.

    • ForwardX11

      • Spezifiziert ob X11 Verbindungen automatisch über die sichere Verbindung getunnelt werden sollen.

    • GatewayPorts

      • Spezifiziert ob sich entfernte Maschinen an lokal geforwardete Ports hängen dürfen.

    • GlobalKnownHostsFile

      • Definiert eine andere Datei statt /etc/ssh_known_hosts.

    • HostKeyAlias

      • Definiert ein Alias das anstelle des echten in known_hosts verwendet wird. Nützlich für das tunneling oder wenn mehrere Server auf einem Host laufen.

    • HostName

      • Definiert einen Hostnamen zum Log in z. B. als Spitznamen oder Abkürzung.

    • IdentityFile

      • Definiert die Datei von der die RSA Identität des Benutzer ausgelesen wird, Standard ist $HOME/.ssh/identity. Zusätzlich können Identitäten des Authentication Agents angegeben werden."~" kann benutzt werden, ebenso können mehrere Dateien angegeben werden, die der Reihe nach durchsucht werden.

    • KeepAlive

      • Gibt an ob KeepAlive Meldungen gesendet werden sollen. Dies ermöglicht die überprüfung der Verbindung und und tötet die Session wenn die Verbindung abbricht und verhindert somit Geisterprozesse. Standard ist ja, zum abschalten müssen Client und Server auf nein stehen. Nützlich vor allem in Scripts.

    • KerberosAuthentication

      • Spezifiziert ob Kerberos-Authentifizierung erlaubt ist. Standard ist ja, der Server benötigt eine Kerberos Servtab welche die Authentifizierung der KDC Identität erlaubt. Die Identifizierung erfolgt mittels Kerberos Ticket oder Passwort.

    • KerberosTgtPassing

      • Gibt an ob ein Kerberos TGT an den Server geforwardet werden soll. Standard ist nein, es funktioniert nur wenn die Kerberos KDC ein AFS-Kaserver ist.

    • LocalForward

      • Definiert einen TCP/IP Port der von der lokalen zur entfernten Maschine geforwardet wird. Mehrere Ports können geforwardet werden, Format ist: lokalerPort:entfernteMaschine:entfernterPort , nur root kann privilegierte Ports forwarden.

    • LogLevel

      • Verbosemodus ("Auskunftsfreudigkeit") dss sshd wenn mitgeloggt wird.Optionen: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. Standard ist INFO. DEBUG verletzt die Privatsphäre der User und ist nicht empfohlen.

    • MACs

      • Gibt die MACs (Message Authentication Code) Algorithmen an. Dies wird in Protokoll 2 benutzt um die Integrität der übertragung zu schützen. Mehrere Algorithmen können per Komma-getrennter Liste angegeben werden. Standard ist: ``hmac-sha1,hmac-md5,hmac-ripemd160, hmac-ripemd160@openssh.com, hmac-sha1-96,hmac-md5-96''

    • NumberOfPasswordPrompts

      • Anzahl der Passwortabfragen vor Abbruch. Standard ist 3.

    • PasswordAuthentication

      • Spezifiziert ob Password-Authentifikation erlaubt ist. Betrifft Protokoll 1 & 2

    • Port

      • Gibt den Port an, an den sich der sshd binden soll. Standard ist 22, mehrere Ports können übergeben werden.

    • Protocol

      • Gibt die Protokollversionen an, Standard ist 1. 1,2 erlaubt 1 und 2

    • ProxyCommand

      • Definiert einen Befehl der benutzt wird um zum Server zu verbinden. Die gesamte Zeile wird als Befehl an /bin/sh übergeben. %h und %p werden als entfernter Host und Port interpretiert. CheckHostIP ist nicht verfügbar wenn mit ProxyCommand gearbeitet wird.

    • RemoteForward

      • Forwarded einen TCP/IP Port der entfernten Maschine über den verschlüsselten Kanal zum angegeben Host:Port der lokalen Maschine, mehrere Ports können angegeben werden, Format ist entfernterPort:Host:lokalerPort

    • RhostsAuthentication

      • Gibt an ob rhosts basierte Authentifikation benutzt werden soll. Betrifft nur den Client, wenn der Server kein rhost zuläßt wird dies nicht benutzt.

    • RhostsRSAAuthentication

      • Gibt an ob RSA-rhosts basierte Authentifikation benutzt werden soll. Betrifft nur den Client, wenn der Server kein rhost zuläßt wird dies nicht benutzt.

    • RSAAuthentication

      • Gibt an ob RSA authentication benutzt werden soll. Wird nur benutzt wen der Identityfile dazu existiert und betrifft nur Protokoll 1.

    • ChallengeResponseAuthentication

      • Gibt an ob Response Authentication benutzt werden soll. Zur Zeit gibt es nur Unterstützung für skey(1) Authentifizerung

    • StrictHostKeyChecking

      • Wenn aktiviert, fügt ssh keine bekannten Schlüssel zu $HOME/.ssh/known_hosts und $HOME/.ssh/known_hosts2 und verweigert die Verbindung zu Hosts deren Schlüssel geändert wurden. Wenn auf "ask" gesetzt muß der Benutzer neue Schlüssel bestätigen, bevor sie hinzugefügt werden.

    • UsePrivilegedPort

      • Gibt an ob ein privilegierter Port für ausgehende Verbindungen genutzt werden soll. Wenn deaktiviert können einige ältere Server mit RhostsAuthentication und RhostsRSAAuthentication nicht mehr kontaktiert werden.

    • User

      • Definiert den Benutzernamen als den man sich einloggen will. Sehr nützlich wenn man mehrere Maschinen mit verschiedenen Logins hat.

    • UserKnownHostsFile

      • Definiert die Datei die anstelle von $HOME/.ssh/known_hosts verwendet wird

    • UseRsh

      • Gibt an das für diesen Host rsh/rlogin verwendet werden soll.

    • XAuthLocation

      • Definiert den Ort des xauth(1) Programms. Standard ist/usr/X11R6/bin/xauth.

Umgebungsvariablen

  • DISPLAY

    • Diese Variable gibt (X11-üblich) den X11 Server in "host:n" an.

  • HOME

    • Pfad zum Home-Verzeichnis des Users.

  • LOGNAME

    • Synonym für USER; aus Kompatibilitätgründen verwendet.

  • MAIL

    • Pfad zur Mailbox.

  • PATH Der Standardpfad, gesetzt wenn SSH kompiliert wird

  • SSH_AUTH_SOCK

    • Definiert den Pfad eines Unix-Domain Socket der genutzt wird um mit dem Agent zu kommunizieren.

  • SSH_CLIENT

    • Definiert den Client der Verbindung. Die Variable hat folgende Form: Client IP, Client Port, Server Port

  • SSH_ORIGINAL_COMMAND

    • Diese Variable enthält die originale Kommandozeile wenn ein übergebener Befehl ausgeführt wird.

  • SSH_TTY

    • Der Pfad zum TTY welches mit der aktuellen Shell (oder Befehl) assoziert ist. Wenn die Sitzung kein TTY hat ist die Variable nicht gesetzt.

  • TZ

    • Timezone-Variable, wird gesetzt wenn der Daemon gestartet wird und an eröffnete Verbindungen weitergereicht.

  • USER

    • Loginname des User. Zusätzlich liest ssh $HOME/.ssh/environment, und übergibt angebenene Zeile im Format "VARNAME=value" als Variablen.

Verwendete Dateien des ssh-Client

  • $HOME/.ssh/known_hosts

    • Zeichnet die Host Schlüssel für alle Maschinen auf, in die sich der User einloggt und die nicht /etc/ssh_known_hosts stehen.

  • $HOME/.ssh/identity, $HOME/.ssh/id_dsa

    • Beinhaltet die RSA und DSA Identitäten des Users. Enthält sensible Daten und sollte r-------- gesetzt sein. (chmod 400) Andernfalls wird er von ssh ignoriert. Beim generieren kann eine Passphrase übergeben werden die den Schlüssel per 3DES schützt.

  • $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub

    • Enthält den öffentlichen Schlüssel zur Authentifizierung in lesbarer Form. Der Inhalt sollte auf allen Servern die per RSA erreicht werden sollen in $HOME/.ssh/authorized_keys eingefügt werden. Für DSA analog in $HOME/.ssh/authorized_keys2, Diese Dateien enthalten keine sensiblen Daten.

  • $HOME/.ssh/config

    • Konfugrationsdatei für den Benutzer.

  • $HOME/.ssh/authorized_keys

    • RSA Schlüssel die dieser Benutzer für Logins verwenden kann.

  • /etc/ssh_known_hosts

    • Systemweite Liste der bekannten Hostschlüssel fürProtokoll 1

  • /etc/ssh_known_hosts2

    • Systemweite Liste der bekannten Hostschlüssel fürProtokoll 2.

  • /etc/ssh.conf

    • Systemweite Konfiguration für nicht gesetzte Werte oder (nicht vorhandene) Konfigurationen der Benutzer.

  • $HOME/.rhosts

    • Wird in der .rhosts Authentifikation benutzt und enthält die Host/Benutzer Paare die sich einloggen dürfen.

  • $HOME/.shosts

    • hat die selbe Bedeutung wie .rhosts. Wird benötigt um .rhost Authentifikation mit ssh durchzuführen, ohne rlogin oder rsh einsetzbar zu halten.

  • /etc/hosts.equiv

    • Genutzt zur .rhosts Authentifikation, enthält die kanonischen Hostnamen welche sich automatisch einloggen dürfen.

  • /etc/shosts.equiv

    • Äquivalent zu hosts.equiv, wieder mit der Möglichkeit kein rlogin oder rsh einsetzbar halten zu müssen.

  • /etc/sshrc

    • Befehle in dieser Datei werden ausgeführt wenn sich ein User einloggt, bevor die Shell (oder ein übergebener Befehl) ausgeführt werden.

  • $HOME/.ssh/rc

    • Befehle in dieser Datei werden ausgeführt wenn sich dieser User einloggt, bevor die Shell (oder ein übergebener Befehl) ausgeführt werden.

  • $HOME/.ssh/environment

    • Zusätzliche Environmentvariablen können hierübergeben werden.

Login via public-key

SSH ermöglicht es ebenfalls die Loginauthentifikation via Schlüssel vornehmen zu lassen, dabei muss ein Passwort nicht zwingend vergeben werden, so das hiermit automatisierte Logins vorgenommen werden können. Konfiguration:

Auf dem Client einen Schlüssel erstellen:

stefan@AragornOfArathorn {22} ssh-keygen -b 2048 -t rsa

Dieser wird in der Regel nach ~/.ssh/ gespeichert, wobei id_rsa der geheime und id_rsa.pub der öffentliche 2048-bittige RSA-Schlüssel für SSH-Protokoll 2 ist.

Anschließend muss id_rsa.pub auf den Server übertragen werden, am besten via sftp oder scp:

stefan@AragornOfArathorn {23} scp .ssh/id_rsa.pub stefan@192.168.2.1:/home/stefan/.ssh

und an ~/.ssh/authorized_keys anhängen:

stefan@RumilOfLorien {2} cat id_rsa.pub &gt;&gt; authorized_keys && chmod 600 authorized_keys

Der sshd weigert sich eine Schlüsseldatei zu lesen, die bei Anderen als dem Eigentümer lesbar ist, daher werden die Zugriffsrechte auf 600 gesetzt.

Es ist jetzt möglich, sich bequem per ssh einzuloggen oder z. B. scp ohne Interaktion aufzurufen.