Die Secure Shell (ssh) bietet mehr als nur ein verschlüsseltes Terminal Login auf einen anderen Computer. Hier ein kurzer Überblick über die Erstellung von Schlüsseln und wie man sie einsetzt.

Vorbereitung und -bemerkung

Bemerkung: Die in diesem Dokument verwendeten Domainnamen sind auf lokale Netze angelegt und in der Form: remote.host.local

Die öffentlichen und privaten Schlüssel liegen in der Regel in einem Verzeichnis ~/.ssh, welches nur für den User selber lesbar ist. Werden die Rechte hierfür nicht richtig gesetzt, wird der ssh die Verbindung verweigern.

# mkdir .ssh; chmod 700 .ssh; cd .ssh

Schlüsselgenerierung

# ssh-keygen -t rsa -C "Example `date +%Y-%m-%d`" -f id_rsa-example
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):Enter same passphrase again:
Your identification has been saved in id_rsa-example.
Your public key has been saved in id_rsa-example.pub.
The key fingerprint is:
df:7b:ea:5c:60:65:0a:df:a0:d6:a9:ea:e2:d3:ef:72 Example 2009-12-19

Erstellen eines öffentlichen Schlüssel aus dem privaten

Falls es einmal nötig sein sollte, den öffentlichen Schlüssel neu zu erstellen. Die Option -y ist wichtig, sie fragt nach einer Bestätigung für das Passworf (passphrase):

# ssh-keygen -y -C "Ein Kommentar" -f id_rsa-example > id_rsa-example.pub

Registrieren des öffentlichen Keys

# cat id_rsa-example.pub >> authorized_keys2

Nachträgliches Verschlüsseln des privaten Schlüssels

Will man einen privaten Schlüssel vor dem Zugriff Fremder schützen, weil man ihn bspw. auf einem USB-Stick mitnehmen möchte, den man verlieren könnte, lässt sich der Schlüssel mit einem sogenannten Passhphrase schützen. Ein Passphrase ist bspw. ein Passwort:

# cp id_rsa-example id_rsa_example.crypt
# ssh-keygen -p -C "crypted key" -f id_rsa_example.crypt
Key has comment 'crypted key'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

Konfigurieren des sshd

/etc/ssh/sshd_config:

# einen beliebigen anderen Port oberhalb 1024 wählen, um Script-Kiddies fern zu halten:
Port 8745
PasswordAuthentication no
MaxStartups 3:50:10
LoginGraceTime 30
AllowUsers john mary joe*
AllowGroups sshusers
PermitRootLogin no
PermitRootLogin without-password
PermitRootLogin forced-commands-only

Weiteres Sichern des Systems

Attackierende Hosts aussperren

# yum install denyhosts

Dieses Script hilft server attacs zu behandeln. Es liest das ssh server logfile und trägt in /etc/hosts.deny diejenigen hosts ein, die durch attacken auffallen.

SSH flood protection

# iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 \
--rttl --name SSH -j LOG --log-prefix "SSH conn flooding " iptables -A INPUT -p tcp \
--dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP iptables \
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT

Scannen nach Loginversuchen

Die letzten 5 Loginversuche:

#  lastb | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

Die 5 am meisten attackierten Accounts:

# awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $1}' /var/log/secure* \
| sort | uniq -c | sort -rn | head -5

Die 5 IP-Addressen mit den meisten Login Attacken:

# awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $3}' /var/log/secure* \
| sort | uniq -c | sort -rn | head -5

Port-Forwarding, Tunneling

Mit dem Weiterleiten von Ports lässt sich SSH zum Universallogin benützen. Der Vorteil besteht darin, dass jegliche Verbindung zu einem entfernten Rechner schlüsselt stattfindet und die dort laufende Software nicht umkonfiguriert werden muss, um sicher zu sein. Port-Forwarding lässt sich am einfachsten an einem Beispiel erklären. Nehmen wir an, wir haben Webmin installiert, mit dem sich bequem via Browser ein Server verwalten lässt. Webmin selber ist von vornherein so eingestellt, dass es nur auf Anfragen aus dem eigenen Netzwerkbereich antwortet. Man könnte das ändern und auch Anfragen von aussen zulassen. Dafür müsste aber im Router ein neuer Port  geöffnet werden (Webmin: 10000) und falls NAT eingesetzt wird, auf den Server weitergereicht werden. Webmin selber benutzt SSL. Das wäre an sich sicher, doch müsste für jeden Dienst ein neuer Port geöffnet werden. Beispielsweise für den Zugriff auf den Raid-Controller, auf das Backup-System, usw. Hier kommt Port-Forwarding von ssh zum Zuge:

# ssh -L 8080:localhost:10000 userremote [dot] host [dot] local -p 8745

8080 ist der Port, auf den dann lokal zugegriffen wird.
10000 ist der Port, der durch den ssh Kanal getunnelt wird. Aller Transfer wird demgemäss verschlüsselt.
-p 8745 gibt den Port an, auf dem der sshd auf dem Rechner remote.host.local läuft.

Nun kann der lokale Webbrowser geöffnet werden und auf die Webmin-Oberfläche mit https://localhost:8080 zugegriffen werden.

Möchte man auf die Weboberfläche eines Routers mit der dort lokalen Adresse 192.168.10.1 zugreifen, dessen Interface aber nicht nach aussen öffnen, lässt sich dies auch machen:

# ssh -L 8080:192.168.10.1:10000 userremote [dot] host [dot] local -p 8745

Wiederum lässt sich nun via lokalem Browser darauf zugreifen http://localhost:8080

Es gibt viele weitere Beispiele für die sinnvolle Benützung eines SSH-Tunnels. Beispielsweise der Versand von Mails an den ungesicherten Port 25:

# ssh -L 8025:localhost:25 userremote [dot] host [dot] local -p 8745

Der (lokale) Mailclient muss nun statt auf Port 25 des remote-servers nun auf Port 8025 des eigenen Rechners gelenkt werden und verschlüsselt über den ssh-Tunnel schlussendlich auf Port 25 des entfernten Rechners geleitet.

Man kann aber auch jeden Port eines beliebigen Rechners, der vom Zielrechner erreichbar ist weiterleiten. So lässt sich durch einen sogenannten "jump server" sicher auf ein Windows via rdp zugreifen. Statt rdestop kann natürlich jedes grafische Tool wie z.B. unter Linux/Gnome den Remote Desktop Viewer als "front end" für vinagre.

# ssh -L 3389:192.168.10.10:3389 userremote [dot] host [dot] local -p 8745
# rdesktop localhost

X forward

Wählt man X forward über ssh ( -X) kann die Verbindung nicht schnell genug sein. Mit der Kompression der Übertragung lässt sich der Durchsatz steigern (-C). AES, die Grundeinstellung der Verschlüsselung, ist nicht die schnellste, Blowfish ist schneller, das ergibt:

# ssh -c blowfish-cbc -XC usernameremote [dot] host [dot] local