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"

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


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:

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)


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).

Ü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:

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 >> ~/.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 >> ~/.ssh/authorized_keys
  exit

Oder alles auf einen Schlag:

ssh USER@HOST "mkdir ~/.ssh;
    cat >> ~/.ssh/authorized_keys" < ~/.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:


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:

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" &

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]

Links

• http://www.openssh.com
• http://www.openbsd.org
• ftp://ftp.de.openbsd.org/pub/unix/OpenBSD/OpenSSH/portable
• ftp://ftp.freesoftware.com/pub/infozip/zlib
• http://www.openssl.org
• http://www.ssh.fi
• http://www.chiark.greenend.org.uk/~sgtatham/putty Putty (Windows SSH-Client)

---