SSH (Secure Shell)

Dieses Dokument beschreibt Grundlagen und Einsatz von SSH unter UNIX, Linux und Windows.

Einführung

SSH (Secure Shell) stellt mit ssh, scp? und sftp? eine gesicherte (verschlüsselte) Kommunikation über unsichere Netze zur Verfügung, und bildet einen sicheren Ersatz für die Standard UNIX Tools telnet, ftp?, rlogin?, rcp?, rsh?, rcmd?, ... (Remote Login, Remote Kommando Ausführung bzw. Dateitransfer).

SSH sollte daher aus Sicherheitsgründen alle diese UNIX/LINUX Remote Kommandos ersetzen. Bei den meisten LINUX/UNIX Versionen ist SSH inzwischen Standard. Auf ftp/telnet-Dienste sollte daher von vornherein verzichtet werden oder über SSH getunnelt werden.

Weiterhin unterstützt SSH den Schutz von X11 Verbindungen (X Window System) und die Weiterleitung (Port-Forwarding) von beliebigen TCP-Verbindungen über einen kryptografisch gesicherten Kanal und bietet VPN-Funktionalität (VPN für Arme).

Eigenschaften:

  • Leistungsfähige Authentifizierung von Client und Server
  • Sichere Verschlüsselung der übertragenen Daten (und Anmeldung)
  • Integritätssicherung (Verifizierung) der übertragenen Daten (verhindert "Man-in-the-middle Attacken")

Kurzer Funktionsumfang:
  • Login auf Remote Host
  • Ausführung von Kommandos auf Remote Host (interaktiv / nicht-interaktiv)
  • Kopieren von Dateien zwischen Hosts
  • Port-Forwarding/Tunneling
  • Komprimierung

Besondere Eigenschaften:
  • RSA/DSA-basierte Authentifizierung (IP-, Routing-, DNS-Spoofing nicht möglich)
  • Systemweite + benutzerbezogene Konfigurationsdateien
  • Übertragung von Binärdaten (+ Komprimierung) möglich
  • Sechs Verfahren der Client-Authentifizierung gegenüber dem Server
  • Automatische und transparente Verschlüsselung der gesamten Kommunikation
  • OpenSSH: Kommt ohne patentierte Algorithmen aus (http://www.openssh.org)
  • Arbeitet gut mit anderen Tools zusammen (z.B. "rsync", "X", "cvs", "svn", "unison").
  • standard Port 22 (SSH-Port [auch jeder andere konfigurierbar]) für Kommunikation verwendet
  • Windows-Ersatz: Putty (suchen in Google nach: putty download), oder andere ssh-Client/Server Software

Übersicht Konfigurationsdateien

Es gibt zentrale (rechnerspezifische) Konfigurationsdateien im Verzeichnis /etc/ssh und benutzerspezifische im Verzeichnis ~/.ssh jedes Benutzers. Gibt es für den gleichen Zweck beide Varianten, dann überschreiben die benutzerspezifischen Einstellungen die zentralen. Existiert die benutzerspezifische Konfigurationsdatei nicht, dann gilt die zentrale vollständig.

In der Regel gibt es Schlüsselpaare pro Rechner bzw. pro Benutzer, da es 3 verschiedene Verschlüsselungsverfahren gibt (veraltet/modern, unsicher/sicher, patentbehaftet/patentfrei). Die Schlüsselpaare für den Rechner werden bei der Installation des Rechners automatisch angelegt. Die Schlüsselpaare für den Benutzer müssen manuell pro Benutzer per sshkey-gen angelegt werden. Ein zusammengehörendes Schlüsselpaar ist in 2 Dateien abgelegt:

File Beschreibung
XXX Privater Teil (bleibt auf Rechner, nur für wenige lesbar)
XXX.pub Öffentlicher Teil ("pub"=public, darf beliebig verteilt werden)


Übersicht
Lokal (Client) Remote (Server)
Kommunikation
Programme: ssh, scp, sftp ===> Dämon: sshd
<=== Firewall mit offenem SSH-Port
Konfiguration
etc/ssh/ssh_config
~/.ssh/config
etc/ssh/sshd_config
(Achtung: d! Daemon)
Server Authentifiz.
etc/ssh/ssh_known_hosts
~/.ssh/known_hosts
<=== etc/ssh/ssh_host_rsa_key (P2)
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_dsa_key (P2)
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_key (P1)
/etc/ssh/ssh_host_key.pub
Client Authentifiz.
~/.ssh/id_rsa (P2)
~/.ssh/id_rsa.pub
~/.ssh/id_dsa (P2)
~/.ssh/id_dsa.pub
~/.ssh/identity (P1)
~/.ssh/identity.pub
===> ~/.ssh/authorized_keys


ACHTUNG: Server Konfigurationsdatei sshd_config (MIT d!) und Client Konfigurationsdatei ssh_config (OHNE d!) NICHT verwechseln!


Prinzipielle Arten von Verschlüsselung

Symmetrisch: Gleicher Schlüssel zum Ver- und zum Entschlüsseln

- Schlüsselaustausch muss über geheimen Kanal erfolgen
- Schlüssel muss geheim gehalten werden
+ Schnell

Asymmetrisch: 2 verschiedene aber eindeutig zusammengehörende Schlüssel,

ein öffentlicher (public key) und ein privater (private key)
+ Schlüsselaustausch einfach (public key darf JEDER kennen!)
+ Nur privater Schlüssel muss geheim gehalten werden
- Langsam

Hybrid: Verbindung der Vorteile beider Verfahren.

Beim Verbindungsaufbau wird über eine asymmetrische Verschlüsselung ein symmetrischer "Sitzungsschlüssel" vereinbart und darüber die eigentliche Kommunikation durchgeführt (bei SSH etwa alle 60 Minuten erneuert).

SSH verwendet hybride Verschlüsselung: Das asymmetrische DSA- oder RSA-Verfahren wird zu Authentifizierung der Gegenstellen verwendet. Danach tauscht SSH einen symmetrischen Schlüssel aus, der die Sitzungsdaten verschlüsselt. Dieser Schlüssel wird in bestimmten Zeitabständen (etwa alle 60 Minuten) erneuert.

Grund für den ständigen Wechsel des Sitzungsschlüssels: Eine aufgezeichnete SSH-Sitzung könnte, wenn der zugehörige private Schlüssel später irgendwie besorgt würde, nachträglich entschlüsselt werden. Da der Sitzungsschlüssel aber nicht mehr existiert und laufend wechselt, ist eine nachträgliche Entschlüsselung der Sitzung nicht oder nur für kleine Abschnitte der Sitzung möglich ("replay"-Angriff).

SSH installieren, aktivieren und testen

Prüfen, ob SSH installiert ist

AIX 5.x + 6.x

Beschreibung folgt

SuSE 10.x + 11.x

rpm -qa | grep "ssh"

openssh-X.XXX-XX
openssh-askpass-X.XXX-XX

Auf dem eigenen Rechner muss der SSH Client ssh installiert sein, auf dem Remote Rechner muss ein SSH Server sshd laufen (lauscht standardmäßig auf Port 22). Firewalls müssen Verbindungen auf Port 22 erlauben bzw. durchlassen.

SSH-Dienst auf dem Server (SSH Server) aktivieren

Temporär:
rcsshd start

oder
/etc/init.d/sshd start

Permanent
chkconfig -a sshd

oder (on boot)
chkconfig sshd on


Überprüfen ob der SSH-Dämon sshd läuft:

rcsshd status

oder
/etc/init.d/sshd status

oder
ps -aux | grep "sshd"


Bei Änderungen an der SSH-Server-Konfigurationsdatei /etc/ssh/sshd_config muss der SSH-Server (sshd) neu gestartet und die Verbindungen neu aufgebaut werden:
rcsshd restart

oder
/etc/init.d/sshd restart


HP-UX 11.xx

Beschreibung folgt

Ubuntu 8.xx + 9.xx

Beschreibung folgt

Konfiguration

Änderungen an der SSH Client Konfigurationsdatei /etc/ssh/ssh_config bzw. ~/.ssh/config wirken sich automatisch auf danach neu hergestellte Verbindungen aus, nicht aber auf die aktuell laufenden Verbindungen.

Es gibt 2 Protokoll Versionen von SSH
Version TYP Protokoll
Version SSHv1 RSA P1
Version SSHv2 RSA und DSA P2


Sie unterscheiden sich in der Aushandlung des symmetrischen Schlüssels, (sicherheitstechnische und patentrechtliche Gründe). Version 1 sollte
aus Sicherheitsgründen nicht mehr verwendet werden!

Die wichtigsten Einstellungen von sshd_config:
Variable Wert Beschreibung
Port 22 Standard-Port (für interne Anwendung änderbar) |
Protocol 2 Probier-Reihenfolge Protokoll-Vers. (nicht 2,1!) |
ListenAddress 0.0.0.0 Standard: Auf allen NW-Karten lauschen |
ForwardX11 yes X11-Forwarding aktiv


Neben BENUTZERSPEZIFISCHEN Schlüsseln gibt es auch RECHNERSPEZIFISCHE Schlüssel. Die rechnerspezifischen Schlüssel werden meist bei der Systeminstallation erzeugt. Sämtliche Schlüssel sollten unbedingt an einer vertraulichen Stelle gesichert werden (z.B. ausgedruckt und in einem verschlossenen Umschlag hinterlegt werden), damit sie bei einem Systemfehler oder einer Neuinstallation wieder hergestellt werden können! Durch sie kann bestimmt werden, von welchen Rechnern überhaupt eine SSH-Verbindung erlaubt ist.
Type der Schlüssel Files
File Version Typ
etc/ssh/host_key_rsa 2 privater RSA2-Schlüssel
etc/ssh/host_key_rsa.pub 2 öffentlicher RSA2-Schlüssel
etc/ssh/host_key_dsa 2 privater DSA-Schlüssel
etc/ssh/host_key_dsa.pub 2 öffentlicher DSA-Schlüssel
etc/ssh/host_key 1 privater RSA1-Schlüssel
etc/ssh/host_key.pub 1 öffentlicher RSA1-Schlüssel)

Neuer ssh Server key

Einen neuen ssh Server key zu generieren ist nicht notwendig, da dieser bei der Installation generiert wird.
Wenn man Virtuelle Server dupliziert, ist dies aber manchmal dennoch notwendig.
))OpenSSH(( benötigt unterschiedliche keys für das SSH1 und SSH2 Protokoll. Diese keys werden genauso generiert wie die eigenen.

Für das SSH1 Protokoll benötigen wir den rsa1 key, der wie folgt generiert wird:
ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

Für das SSH2 Protokoll benötigen wird zwei keys, einen rsa key und einen dsa key, die wie folgt generiert werden:
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa




Testen der SSH-Verbindung

telnet localhost 22

Antwort
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1


Anmerkung:per strg+5 bzw. strk+[ auf tty unterbrechen und mit close die Verbindung beenden oder mit quit die telnet Session schließen.

Anwendungen von SSH

Anmelden per SSH

Per SSH an einem anderen Rechner anmelden (als aktueller Benutzer oder jemand anderer auf dem Remote-Rechner anmelden):

Kommmando Beschreibung
ssh 172.23.19.56 Als aktueller Benutzer
ssh -l tom 172.23.10.56 Als anderer Benutzer (-l login)
ssh tom@172.23.10.56 Als anderer Benutzer (@ = at)
ssh -p 2222 tom@172.23.10.26 Auf anderem Port (-p port)


Test des Verbindungs Aufbaus (-v=verbose, auch mehrfach -vv, -vvv, ...):
ssh -v 172.23.10.56

Meldung beim 1. Verbindungsaufbau zu Host, dass Host Schlüssel unbekannt ist:
  The authenticity of host '192.168.1.252 (192.168.1.252)' can't be established.
  RSA key fingerprint is 8a:58:19:a1:27:95:2b:e4:e2:3e:5f:41:c7:58:2a:d2.

Server-Authentifizierung

Wird die Verbindung zu diesem Host mit yes (3 Buchstaben!) akzeptiert, dann wird in der lokalen Datei "~/.ssh/known_hosts" der rechnerspezifische öffentliche Schlüssel der Gegenstelle eingetragen (mit Zuordnung zu einer IP):
File Beschreibung
etc/ssh/ssh_host_rsa_key.pub Version 2 (öffentlicher Schlüssel)
etc/ssh/ssh_host_dsa_key.pub Version 2 (öffentlicher Schlüssel)
etc/ssh/ssh_host_key.pub Version 1 (öffentlicher Schlüssel)


Das ist unsinnig für Rechner, die ständig ihre IP-Adressen ändern. In der Konfigurationsdatei /etc/ssh/ssh_config bzw. ~/.ssh/config kann daher das
Verhalten eingestellt werden (Yes oder No möglich (neben Ask)
StrictHostKeyChecking Ask


Das ist bequem aber gefährlich, da der Schlüssel kompromittiert sein könnte ("man-in-the-middle"). Daher sollte er über einen getrennten Kanal transportiert werden (z.B. USB-Stick, Diskette, CDROM). Zumindest sollte der Fingerprint (16 Byte lange Hexadezimalzahl) aus dem übertragenen Schlüssel gebildet und mit dem des Originals verglichen werden:
Kommand Beschreibung
ssh-keygen -l -l list (Standarddatei vorgeschlagen)
ssh-keygen -l -f SCHLÜSSELDATEI -l list
-f file benutze Schlüsseldatei

Wird von SSH bei der Erstellung eines neuen Schlüssels bzw. bei der ersten Verbindungsaufnahme angezeigt (z.B. am Telefon vorlesen lassen oder von der Visitenkarte ablesen).
RSA key fingerprint is 8a:58:19:a1:27:95:2b:e4:e2:3e:5f:41:c7:58:2a:d2.

Übung
  • Oben mit yes akzeptieren, in ~/.ssh/known_hosts steht anschließend IP-Adresse + Schlüssel + Info der Gegenstelle.
  • Schlüssel in known_hosts verändern (z.B. ein Zeichen übertippen) -> Anmeldung geht nicht mehr
  • Andere IP-Adresse eintragen (steht in known-hosts mit drin) -> Analog.
Es ergibt sich in beiden Fällen folgende Fehlermeldung:

@@@@@@@@@@@@@@@@@...
@ WARNING...
@@@@@@@@@@@@@@@@@...
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...

Dies ist ein häufiger Fehler, wenn man SSH einsetzt.
Lösungsmöglichkeiten
  • Eintrag aus ~/.ssh/known_hosts entfernen
  • Eintrag aus /etc/ssh/ssh_known_hosts entfernen
  • StrictHostKeyChecking auf No setzen

Kommando per SSH remote ausführen

Ein Kommando an eine SSH-Verbindung übergeben und ausführen lassen:
Kommando Beschreibung
ssh HOST CMD Kommando CMD
ssh HOST ls -l Kommando ls -l


ACHTUNG: Aufpassen bei Metazeichen (resultierenden Befehl ansehen mit echo):
Kommando Beschreibung
ssh HOST ls -l * "*" auf lokalem Serrver ausgewertet
ssh HOST ls -l \* "*" auf Remote Server ausgewertet
ssh HOST ls -l "*" "*" auf Remote Server ausgewertet
ssh HOST ls -l '*' "*" auf Remote Server ausgewertet
ssh HOST "ls -l *" "*" auf Remote Server ausgewertet
ssh HOST 'ls -l *' "*" auf Remote Server ausgewertet

Dateien per SSH zwischen Rechnern kopieren

  • ACHTUNG: ":" nicht vergessen, sonst erhält man eine lokale Kopie!
  • Standard Benutzer ist aktuell angemeldete Benutzer
  • Standard Verzeichnis ist sein Heimatverzeichnis
  • Passwort wird verlangt, wenn kein Schlüsselaustausch stattgefunden hat
  • Struktur des Filesystems auf dem anderen Rechner muss bekannt sein, damit man dort mit korrekten Pfaden zugreifen kann
  • Zugriffsrechte auf anderem Rechner müssen Zugriff gemäß Anmeldung erlauben

Kommando Beschreibung
scp FILE HOST: Remote=Ziel: Heimat Verzeichniss des aktuellen Users
scp FILE HOST:/tmp Remote=Ziel: Verz. /tmp
scp FILE USER@HOST: Remote=Ziel: Als anderer Benutzer anmelden (-l geht nicht!)
scp HOST:FILE . Remote=Quelle: "FILE" im Heimat Verzeichniss in akt. Verzeichniss
scp USER1@HOST1:FILE USER2@HOST2:FILE Zwischen zwei fremden Rechnern kopieren


Optionen von scp:
-r recursive
-p preserve access rights
-q quiet
-C Compression
-P 2020 Port (GROSS wg. -p=preserve!)
-o StrictHostKeyChecking=no Option

X Window Protokoll tunneln

X Window Protokoll durchtunneln (Variable "DISPLAY" anschließend gesetzt):

Kommando Beschreibung
ssh -X 172.23.10.56 Erlauben (-X=enable, -x=disable)
ssh -Y 172.23.10.56 Erlauben (-Y=enable)


Um X Window Anwendungen remote starten zu können, müssen verschiedene Bedingungen erfüllt sein:
  • Remote Server muss das unterstützen (Eintrag X11Forwarding in /etc/ssh/sshd_config, Standard meist no).
  • Lokaler Client muss das unterstützen (Variable DISPLAY muss gesetzt sein
    Eintrag ForwardX11 in /etc/ssh/ssh_config bzw. ~/.ssh/config, Standard meist no
    oder Schalter -X (enable) bzw. -x (disable) beim ssh-Aufruf mitgeben).
  • Evtl. xhost +HOST auf lokalem Rechner setzen (macht eigentlich xauth)

Öffentlichen Schlüssel vom fremden Rechner holen:
Kommando Beschreibung
ssh-keyscan -t rsa HOST V2: RSA-Schlüssel von HOST holen
ssh-keyscan -t dsa HOST V2: DSA-Schlüssel von HOST holen
ssh-keyscan HOST V1: RSA-Schlüssel von HOST holen



Client-Authentifizierung (ohne Passwort)

Aktueller Stand: Bei Verbindungsaufnahme wird Server authentifiziert, der Client muss zur Authentifizierung sein Passwort eingeben (wird aber bereits verschlüsselt). Es soll aber eine Anmeldung ohne Passwort mit Authentifizierung des Clients möglich sein. Dazu muss für den anzumeldenden Anwender ein Schlüssel generiert werden, dessen öffentlicher Teil auf dem Remote Server in einer Datei authorized_keys einzutragen ist.
z.B.: über SSH-Verbindung per CUT/PASTE kopieren oder per scp kopieren und mit
cat KEY &gt;&gt; ~/.ssh/autorized_keys

anhängen.

ACHTUNG: kein Anfangs/Endstück weglassen, keine Zeilenumbrüche, muss EINE Zeile sein!.

Zunächst ist zu einem Benutzer kein Verzeichnis ~/.ssh/ in seinem Heimatverzeichnis vorhanden. Dieses wird erzeugt, wenn für ihn ein Schlüsselpaar generiert wird (ohne "Passphrase" = leere Passphrase!):
Kommando Beschreibung
ssh-keygen -t rsa -b size V2: Patentiert bis Mitte 2004 (-t=type)
ssh-keygen -t dsa -b size V2
ssh-keygen -t rsa1 -b size V1


-b size minimum size ist 768 bits und der default Wert ist 2048 bits.
Derzeit kann man, ohne große Performanceeinbrüche, auch 4096 bits verwenden.

Den Fingerprint (16-stellige Hexadezimalzahl) des öffentlichen Schlüssels, kann man z.B. auf seiner Web Seite oder auf der Visitenkarte veröffentlichen. Andere können darüber manuell feststellen, ob der Verbindungspartner wirklich der richtige ist.

Der Weg, auf dem der öffentliche Schlüssel ausgetauscht wird, darf nicht manipulierbar sein (z.B. per Hand, Telefon, Diskette, USB, Maus per SSH-Verbindung, NICHT per eMail!). Eine weitere Möglichkeiten wäre der Transport des Schlüssels mittels CUTE/PASTE in einer SSH-Anmeldung
cat ~/.ssh/id_rsa.pub
ssh USER@HOST
mkdir ~/.ssh
vi ~/.ssh/authorized_keys
           ... angezeigten Schlüssel CUT/PASTE als 1 Zeile einfügen ...
   :wq

Oder mit scp:
scp ~/.ssh/id_rsa.pub USER@HOST:/tmp
  ssh USER@HOST
  mkdir ~/.ssh
  cat /tmp/id_rsa.pub &gt;&gt; ~/.ssh/authorized_keys
  exit

Oder alles auf einen Schlag:
ssh USER@HOST "mkdir ~/.ssh;
    cat &gt;&gt; ~/.ssh/authorized_keys" &lt; ~/.ssh/id_rsa.pub


Es sollte nun ein Anmeldung per ssh ohne Passworteingabe möglich sein!

Letzten Endes hat folgender Austausch von öffentlichen Schlüsseln der jeweiligen Gegenstelle "über Kreuz" stattgefunden.

Client
(local)
Austausch Server (HOST)
(remote)
ssh USER@HOST ======> sshd
~/.ssh/id_rsa (NICHT kopieren!)
~/.ssh/id_rsa.pub
(per Hand mittels ssh-keygen erzeugt)
------->
(manuell pro Benutzer)
~/.ssh/authorized_keys
(NICHT: /etc/ssh/authorized_keys!)
~/.ssh/known_hosts
oder
/etc/ssh/ssh_known_hosts
<-------
(meist automatisch bei dem 1. ssh
mittels "yes" zu bestätigen)
etc/ssh/ssh_host_rsa_key (NICHT kopieren!)
(beim Installieren erzeugt)


Nach Austausch der öffentlichen Schlüssel wird häufig in /etc/ssh/sshd_config die Authentifizierung via Passwort ausgeschalten.

Variable Beschreibung
RSAAuthentication yes Reine RSA-Authentifizierung erlaubt
PubkeyAuthentication yes Public-Key Authentifizierung erlaubt (nur P2)
PasswordAuthentication no SSH fragt selber nach dem Passwort
UsePAM no Sonst wird Passwort von PAM verlangt


Privaten Schlüssel mit Passphrase sichern

Der private Schlüssel sollte durch eine Passphrase (das ist ein längerer Text ähnlich einem Passwort) gesichert werden, mit der er zusätzlich verschlüsselt wird und nicht im Klartext auf der Platte liegt (Diebstahl oder Kompromittierung des eigenen Rechners führt dann nicht zur Kompromittierung des privaten Schlüssels). Beim Remote Login per SSH wird nach der Passphrase des Schlüssels gefragt (damit dieser entschlüsselt werden kann) und nicht mehr nach dem Password.
ssh-keygen -p

oder mit Datei ~/.ssh/id_rsa
ssh-keygen -p -f ~/.ssh/id_dsa
  Enter file in which the key is (/home/tsbirn/.ssh/id_rsa):
  Enter old passphrase: OLD_XXXXXX
  Key has comment '/home/tsbirn/.ssh/id_rsa'
  Enter new passphrase (empty for no passphrase): XXXXXXXXX
  Enter same passphrase again: XXXXXXXXX
  Your identification has been saved with the new passphrase.

Die Passphrase ist jedesmal einzugeben, wenn ein Zugriff auf den privaten Schlüssel notwendig ist (für automatischen Verbindungs-Aufbau ist das unsinnig, man kann aber auch mehr als ein Schlüsselpaar erzeugen). Alternativ kann die Passphrase über einen SSH-Agent zur Verfügung gestellt werden, sodaß sie nur 1x eingegeben werden muss, im Speicher liegt und dann bei jedem SSH-Kommando automatisch für den Zugriff verwendet wird.
Programm starten zum "halten" der Passphrase
ssh-agent

-s -s Bourne Shell Befehle erzeugen

Passphrase hinzufügen (ggfs. auch für mehrere Keys)
ssh-add [-f file]

-f file speziellen Key File ansprechen


Wichtig sind weiterhin folgenden Einstellungen in /etc/ssh/sshd_config:

Variable Beschreibung
PermitRootLogin no Direkte root SSH Anmeldung nicht möglich
PermitEmptyPasswords no Leere Passworte verboten
IgnoreRhosts yes Datei ~/.rhosts ~/.shosts nicht benutzen
IgnoreUserKnownHosts yes User spezifische Hosts ~/.ssh/known_hosts verboten


Weitere sinnvolle Einstellungen in /etc/ssh/sshd_config sind:

Variable Beschreibung
StrictModes yes Zugriffsrechte auf Benutzer-Dateien prüfen
X11Forwarding yes X11-Protokoll tunneln
X11DisplayOffset 10 X11-Display Startnummer
TCPKeepAlive yes TCP-Keepalive Meldungen schicken



Nur fixes Kommando zulassen

Als Option in Schlüssel Dateien (~/.ssh/authorized_keys) command="KMDO..." vor dem Schlüssel Typ angeben:
command="/bin/ls > /tmp/ls.txt" ssh-rsa ...
command="/usr/bin/ssh " ssh-rsa ...


Shell /bin/bash muss eingetragen sein, damit Kommando ausgeführt werden kann. Der Eintrag in authorized_keys sorgt dafür, dass keine echte Anmeldung erfolgt (sofern schlüsselbasierte Anmeldung mit diesem Schlüssel stattfindet; bei passwordbasierter Anmeldung wird kein Kommando ausgeführt). Sinn:
+ Einzelne Kommandos freischalten
+ SSH-Verbindung nach außen über Proxy Server (keine End-zu-End-Verbindung)
+ SSH-Datenfluss überwachen

Port-Forwarding (Tunneling anderer Protokolle)

Durchschleusen von anderen Protokollen durch einen SSH-Tunnel. Insbesondere Klartext Protokolle können auf diese Weise sicher übertragen werden. Auf dem Zielrechner "SERVER" muss man sich per SSH anmelden können und folgende Einstellung muss dort gelten:
AllowTcpForwarding yes

Tunnel initialisieren

Allgemein gibt es folgende Möglichkeiten des "Tunneling" gesteuert durch ein ssh Kommando:
CLIENT SERVER
1111
<====>
99


Auf lokalem Host

Tunnel vom CLIENT Port 1111 zum SERVER Port 99 aufmachen und lokal telnet session auf Port 1111 aufmachen.

Tunnel vom CLIENT (-L local) zum SERVER
ssh -L 1111:localhost:99 SERVER

Telnet Session auf CLIENT (localhost)
telnet localhost 1111

Auf Remote Host

Verbindung vom SERVER Port 23 zum CLIENT Port 1111 aufmachen :
Auf dem CLIENT Tunnel zum SERVER (-R remote) initialisieren:
ssh -R 1111:CLIENT:23 SERVER

Auf dem SERVER kann jetzt die telnet Session auf localhost Port 1111 aufgemacht werden
SERVER: telnet localhost 1111

Mehrere Tunnels

Verbindung von localhost über HOST2 (SSH-Port 4021) zu HOST3 aufbauen (2 Tunnels!) und das HTTP-Protokoll (Port 80) von HOST3 zu Port 1111 lokal tunneln:
ssh -l root -p 4021 -L 1111:localhost:3000 HOST2 \
                 "ssh -L  3000:localhost:80   HOST3 "

Ablauf:
  1. Anmelden am Rechner HOST2 auf Port 4021
  2. Tunneln auf eigenem Rechner localhost von Port 10001 auf mittleren Rechner HOST2 (-L = "localhost" = dort) zu Port 3000
  3. Tunneln auf mittlerem Rechner HOST2 von Port 3000 auf Endrechner HOST3 (-L = "localhost" = dort) zu Port 80

Beispiele von verschlüsselten Verbindungen

HTTP Protokoll

Von lokal Port 5000 auf den remote SERVER auf Port 80 tunneln. Keiner kann mitlesen, lange laufendes Kommando starten, die keine Rechenzeit verbrauchen und in den Hintergrund schieben
Nur wenn ssh ohne Password/Passphrase auf den Remote Host zugreifen kann
ssh -L 5000:localhost:80 SERVER "sleep 100000" &amp;

Mit Password/Passphrase Abfrage
ssh -L 5000:localhost:80 SERVER "sleep 100000"     
Strg-Z
bg


Im Browser den lokalen Rechner auf Port 5000 ansprechen, die HTTP-Daten werden verschlüsselt an/vom SERVER auf Port 80 übertragen:
http://localhost:5000

POP3 Protokoll

von Port 5000 lokal auf Port 110 auf remote SERVER tunneln
keiner kann mitlesen:
ssh -L 5000:localhost:110 SERVER

mails abrufen mitttels fetchmail (eine gültige .fetchmailrc muss existieren) oder mail Clients die auf localhost:5000 zugreifen

Telnet Verbindung

lokal auf Port 5000 zum Rechner SERVER Port 23 aufbauen
Vor den Tests telnet SERVER installieren und aktivieren sowie xinetd rekonfigurieren und neu starten:
Auf dem SERVER
ssh -R 5000:CLIENT:23 SERVER "sleep 100000"

Auf dem Client
telnet localhost 5000

MySQL Verbindung

Von localhost Port 3306 auf remote SERVER Port 3306 tunneln (MySQL-Server):
ssh -L 3306:localhost:3306 SERVER

Übersicht


Kommandos

file Beschreibung
ssh, slogin Verbindung zu fremdem Rechner aufnehmen (sicherer Ersatz von "telnet", "rsh", "rlogin")
scp Dateien von/zu fremden Rechner transferieren (sicherer Ersatz von "rcp")
sftp Dateien von/zu fremden Rechner transferieren (sicherer Ersatz von "ftp")
ssh-keygen Schlüsselpaar erzeugen
ssh-keyscan Öffentlichen Schlüssel von einem Rechner holen
ssh-add Privaten Schlüssel beim "ssh-agent" registrieren
ssh-agent Privaten Schlüssel verwalten (automatische Beantwortung von "challenges")


Server-Konfigurationsdateien

file Beschreibung
Config
etc/ssh/sshd_config Zentrale Server Konfiguration (es gibt keine benutzerspezifische!)
Keys
etc/ssh/ssh_host_rsa_key Server Identity (Private Key, Protocol V2 = RSA)
etc/ssh/ssh_host_rsa_key.pub Server Identity (Public Key, Protocol V2 = RSA)
etc/ssh/ssh_host_dsa_key Server Identity (Private Key, Protocol V2 = DSA)
etc/ssh/ssh_host_dsa_key.pub Server Identity (Public Key, Protocol V2 = DSA)
etc/ssh/ssh_host_key Server Identity (Private Key, Protocol V1 = RSA)
etc/ssh/ssh_host_key.pub Server Identity (Public Key, Protocol V1 = RSA)
Authentifizierung
etc/ssh/ssh_known_hosts Public Keys der bekannten Server (fest)


Client-Konfigurationsdateien

file Beschreibung
Server Config
etc/ssh/ssh_config Zentrale Client-Konfiguration
User Config
~/.ssh/config User spezifische Client-Konfiguration
User Keys
~/.ssh/id_rsa User Identity (Private Key, Protocol 2 = RSA)
~/.ssh/id_rsa.pub User Identity (Public Key, Protocol 2 = RSA)
~/.ssh/id_dsa User Identity (Private Key, Protocol 2 = DSA)
~/.ssh/id_dsa.pub User Identity (Public Key, Protocol 2 = DSA)
~/.ssh/identity User Identity (Private Key, Protocol 1 = RSA)
~/.ssh/identity.pub User Identity (Public Key, Protocol 1 = RSA)
User/Server Authentifizierung
~/.ssh/known_hosts Public Keys der bekannten Server (updatebar)
~/.ssh/authorized_keys Public Keys der bekannten Benutzer


Ubuntu / Debian Linux regenerieren der OpenSSH Host Keys

  • Löschen der alten ssh host keys
    rm /etc/ssh/ssh_host_*
  • Reconfigurieren des OpenSSH Server
    rm /etc/ssh/ssh_host_*
  • Update der ssh client(s) known_hosts files
    Auf den Client Systemen müssen die Server Einträge in den user Files ~/.ssh/known_hosts mit folgenden Befehlen gelöscht werden
    ssh-keygen -f "/home/[USER]/.ssh/known_hosts" -R [HOSTNAME]
    ssh-keygen -f "/home/[USER]/.ssh/known_hosts" -R [IP]




Das Originaldokument ist zu finden unter http://www.ccf-consulting.de/tiki-5.0/tiki-index.php?page=SSH