Linux User Group Xanten

SSH (SecureShell) findet sich wohl auf jedem linuxartigen System wieder. Und das nicht ohne Grund, nicht nur das SSH die sicherere Alternative zum voellig veralteten Telnet ist, SSH ist auch ein echtes Multitalent was Remotezugriffe angeht.

SSH beim X-Forwarden

SSH ist zum Beispiel beim X-Forwarden sehr hilfreich, denn SSH setzt automatisch die Umgebungsvariablen.
[sshd_config]

X11Forwarding yes

Moechte man sich auf dem Laptop (PC2) den Browser vom Desktop-Rechner (PC1) "ausleihen", loggt man sich von PC2 auf PC1 mit

ssh -X rechner

ein. In die frisch aufgepoppte Shell tippt man mozilla oder sonst was ein.

SSH eine Spur sicherer machen

Nur SSH2 zulassen

SSH laesst standardmaessig SSH1 und SSH2 als Authentisierungsprotokoll zu, wobei SSH2 mehr Auswahl an Authentifizierungsmoeglichkeiten/Verschluesselungsverfahren bietet, also [sshd_config]

Protocol 2

Kein Root-Zulassen

In der Regel ist es besser dem User root den direkten Zugang zu verweigern, denn erfolgreiche Attacken a la BrutalForce auf den root-Account treiben dem Admin wohl mehr Hitze auf die Stirn als wenn es "nur" ein (L)user-Account betrifft.

PermitRootLogin no

Kein normaler User/Passwort-Zugang

Das "normale" bzw. meist verwendete Authen am Remote-Rechner ist die Username/Passwort-Methode. Passwoerter sind, wie man es aus eigener Erfahrung weiss, meistens recht "schwach". Guckt man sich Passwortlisten an findet man sehr oft den Namen der Frau/Freundin/Geliebten oder den Namen des Lieblingsvereins, also ein (sehr) anfaelliges Verfahren.

PasswordAuthentication no

Ein schoeneres Verfahren ist das Public-Key-Verfahren. Der Client erzeugt einen xbliebig langen DSA-Schluessel

ssh-keygen -b 2048 -t dsa

im $HOME/.ssh Ordner werden 2 Schluessel abgelegt id_dsa und id_dsa.pub. Der Publickey (id_dsa.pub) muss auf dem Server in der $HOME/.ssh/authorized_keys Datei hinterlegt werden. Ist der Key auf dem Server hinterlegt, wird ab diesem Zeitpunkt der User ueber den Key authentifiziert.

Zusammenfassung
Auf dem Client sind diese Schritte zu tun:

# Schluessel bauen
ssh-keygen -b 2048 -t dsa
# Schluessel uebertragen
cat .ssh/id_dsa.pub | ssh USER@REMOTERECHNER "umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys"

Tipp: Beim Uebertragen der Schluessel sollte PasswordAuthentication noch auf "yes" stehen.

Bei diesem Verfahren faellt das nervige Username/Passwort-Eintippen flach (wenn man die Passphrase weglaesst).

Firewall mit SSH tunneln

Problem: Der Rechner (PC2) auf den man sich ssh'en moechte, steht hinter einer Firewall bzw. einem Router und kein Forwarding von Port 22 auf diesen Rechner weit und breit zu sehen ..

Folgendes ist zu tun um einen einfachen Tunnel zu schaffen:
PC2:

ssh -N -R 1234:localhost:22 USERNAME@RECHNER_IM_INTERNET

Damit oeffnet sich auf dem RECHNER_IM_INTERNET der Port 1234 und leitet die Anfragen durch den aufgespannten Tunnel an PC2:22 weiter.

Moechte man sich jetzt auf PC2 verbinden gibt man

ssh RECHNER_IM_INTERNET -p 1234

ein und es poppt ein Anmeldedialog auf.

Problem: Der Mailtransport erfolgt ueber das Klartextprotokoll SMPT bzw. POP3; Inhalt und Passworter koennen leicht mitgelesen werden.

Hat man einen haeuslichen Mailserver und moechte von Unterwegs Mail verschicken oder abrufen kann man mit SSH einen sicheren Tunnel bauen ohne dass die Welt die Mail mitliesst.
Von Unterwegs

ssh USERNAME@MAILSERVER -q -L 2025:MAILSERVER:25 2010:MAILSERVER:110

Man stellt sein Mailproggi auf Server: localhost mit SMPT statt "25" auf "2025" und POP3 statt "110" auf "2010"

Viel Erfolg!

Tipps und Anregungen an Marc Giavarra