SSH

Wichtige Sicherheitsnachricht: Debian hatte ein ernsthaftes Problem mit SSL-Schlüsseln. Betroffen waren alle sidux live-CD-ISOs und Festplatteninstallationen von sidux Chaos, Tartaros, Gaia, Eros und Nyx.

Informationen zur Fehlerbehebung findet man online bei Debian (Englisch) und im sidux-Forum. Bitte beherzigen Sie diese Ratschläge. Dies ist eine sehr ernste Sicherheitsnachricht.

Definition von SSH aus der englischsprachigen Wikipedia (sinngemäße Übersetzung):

Im Computerwesen ist SSH bzw. "Secure Shell" ein Netzwerkprotokoll mit dazugehörigen Standards, welches die sichere Verbindung zwischen einem lokalen und einem entfernten Computer ermöglicht. Dabei wird Kryptographie mit einem öffentlichen Schlüssel (public key) angewendet, um den entfernten Computer zu authentifizieren bzw. um optional dem entfernten Computer zu gestatten, den Nutzer zu authentifizieren. SSH gewährleistet Vertraulichkeit und Integrität der zwischen den beiden Rechnern ausgetauschten Daten, indem Verschlüsselung und MACs (message authentication codes) zur Verwendung kommen. Typisches Anwendungsfeld für SSH ist die Anmeldung an einem entfernten Rechner und die Ausführung von Befehlen auf diesem, unterstützt wird aber auch das Tunneln und Weiterleiten beliebiger TCP-Ports und von X11-Verbindungen. Es können auch Dateien mit den assoziierten Protokollen SFTP oder SCP übertragen werden. In der Grundeinstellung lauscht der SSH-Server auf TCP-Port 22.

Eine deutschsprachige Erstinformation über SSH findet man auf den Seiten der deutschsprachigen Wikipedia.

Verwendung guter Sicherheitsprotokolle mit SSH

Es ist nicht sicher Root-Anmeldung via SSH zu erlauben. Es gilt, Anmeldungen als Root nicht zum Standard zu machen, denn Debian sollte sicher sein, nicht unsicher. Ebenso sollen User nicht die Möglichkeit haben, über zehn Minuten einen wortlistenbasierten Passwort Angriff (brute force attack) auf den SSH-Login durchzuführen. Deshalb ist es sinnvoll, das Zeitfenster der Anmeldung sowie die Anzahl möglicher Versuche einzuschränken.

Um SSH sicherer zu machen, verwendet man einen Texteditor, um folgende Datei zu bearbeiten:

/etc/ssh/sshd_config

Folgende Einstellungen können zur Erhöhung der Sicherheit angepasst werden:

Port <gewünschter Port>: Dieser Eintrag muss auf den Port verweisen, der auf dem Router zur Weiterleitung freigeschaltet ist. Wenn nicht bekannt ist, was gemacht werden soll, soll der Einsatz von SSH zur Remote Steuerung noch einmal überdacht werden. Debian setzt den Port 22 als Standard. Es ist jedoch ratsam, einen Port ausserhalb des Standardscanbereichs zu verwenden, deswegen verwenden wir z.B. Port 5874:

Port 5874

ListenAddress <IP des Rechners oder der Netzwerkschnittstelle>: Da der Port vom Router weitergeleitet wird, muss der Rechner eine statische IP-Adresse benutzen, sofern kein lokaler DNS-Server verwendet wird. Aber wenn etwas so Kompliziertes wie SSH unter Benutzung eines lokalen DNS-Servers aufgesetzt werden soll und diese Anweisungen benötigt werden, kann sich leicht ein gravierender Fehler einschleichen. Wir verwenden eine statische IP für das Beispiel:

ListenAddress 192.168.2.134

Protokoll 2 ist bereits Grundeinstellung bei Debian, aber man sollte sicher sein und daher nochmals überprüfen.

LoginGraceTime <Zeitrahmen des Anmeldevorgangs>: Die erlaubte Zeitspanne beträgt als Standard absurde 600 Sekunden. Da man für gewöhnlich keine zehn Minuten benötigt, um Benutzernamen und Passwort einzugeben, stellen wir eine etwas vernünftigere Zeitspanne ein:

LoginGraceTime 45

Nun hat man 45 Sekunden Zeit zum Anmelden, und Hacker haben keine zehn Minuten bei jedem Versuch, das Passwort zu knacken.

PermitRootLogin <yes>: Warum Debian hier Erlaubnis zur Anmeldung als Root erteilt, ist nicht nachvollziehbar. Wir korrigieren zu 'no':

PermitRootLogin no

StrictModes yes

MaxAuthTries <Anzahl der erlaubten Anmeldungsversuche>: Mehr als 3 oder 4 Versuche sollten nicht ermöglicht werden:

MaxAuthTries 2

Folgende Einstellungen müssen hinzugefügt werden, so sie nicht vorhanden sind:

AllowUsers: Benutzernamen, welchen der Zugriff via SSH erlaubt ist, getrennt durch Leerzeichen

AllowUsers <xxx>: Nur eingetragene Benutzer können den Zugang verwenden, und dies nur mit Benutzerrechten. Mit adduser sollte man einen User hinzufügen, der speziell zur Nutzung von SSH verwendet wird:

AllowUsers werauchimmer

PermitEmptyPasswords <xxx>: dem Benutzer soll ein schönes langes Passwort gegeben werden, das man in einer Million Jahren nicht erraten kann. Dieser Benutzer sollte der einzige mit SSH Zugriff sein. Ist er einmal angemeldet, kann er mit su Root werden:

PermitEmptyPasswords no

PasswordAuthentication <xxx>: natürlich muss hier 'yes' gesetzt werden. Es sei denn, man verwendet einen KeyLogin.

PasswordAuthentication yes [wenn man keine keys verwendet]

Schlussendlich:

/etc/init.d/ssh restart

Nun hat man eine etwas sichere SSH-Konfiguration. Nicht vollkommen sicher, nur besser, vor allem wenn man einen Benutzer hinzugefügt hat, der speziell zur Verwendung mit SSH dient.

Anmerkung: Falls ssh eine Verbindung verweigert und man eine Fehlermeldung erhält, sucht man in $HOME nach dem versteckten Verzeichnis .ssh, löscht die Datei known_hosts und versucht einen neuen Verbindungsaufbau. Dieses Problem tritt hauptsächlich auf, wenn man die IP-Adresse dynamisch zugewiesen hat (DCHP).

X-Windows Programme über SSH-verschlüsselte lokale Netzwerkverbindungen verwenden

Ein Programm läuft auf einem entfernten Computer, die graphische Benutzeroberfläche (GUI) wird auf dem lokalen PC angezeigt.

Annahmen:
* sidux
* IP des lokalen PCs: 192.168.1.10/24 (nur X11-Bildausgabe des Programms)
* IP des entfernten PCs: 192.168.1.2/24 (hier läuft das X11 Programm)

Konfiguration:

Auf dem entfernten PC wird die /etc/hosts.allow um folgende Zeile erweitert:

ssh sshd : 192.168.1.0/24 : ALLOW 
# ALLOW erlaubt allen Adressen im lokalen Netzwerk den Zugriff über den ssh-Server

In einer Konsole baut man mit diesem Befehl eine SSH-Verbindung und X-Forwarding auf:

ssh -X 192.168.1.2
(man gibt das eigene SSH-Passwort ein, wenn danach gefragt wird,
oder das Passwort zum SSH-Schlüssel, wenn der eigene öffentliche Schlüssel (Public-Key) zum
entferneten Rechner geschickt und dort zu den Schlüsseldateien des Benutzers
hinzugefügt wurde)

Aufrufen des X-Programms in der Shell, z.B. 'iceweasel':

ssh -X 192.168.1.2
[Passworteingabe - siehe oben]
iceweasel

Remote Zugriff von einem Windows-PC unter Nutzung von SSH und X-Forwarding:

* Herunterladen und Brennen der Cygwin XLiveCD
* Die CD ins Laufwerk einlegen und auf den automatischen Start (autorun) warten
* Weiter (continue) klicken, bis sich ein Shell-Fenster öffnet.
* Folgenden Befehl eingeben:

ssh -X username@xxx.xxx.xxx.xxx

Anmerkung: xxx.xxx.xxx.xxx ist die IP-Adresse des entfernten Linux-PCs oder seine URL (z.B. eines dyndns.org Accounts), und der Username ist natürlich der eines auf dem entfernten Rechner existierenden Benutzerkontos. Nach erfolgreichem Login kann man zum Beispiel 'kmail' starten und seine Mails abrufen.

Wichtig: hosts.allow muss einen Eintrag beinhalten, der auch Rechnern aus anderen Netzwerken den Zugriff erlaubt. Wenn man einen Router oder eine NAT-Firewall verwendet, muss Port 22 zum Linuxrechner weitergeleitet sein (portforwarding).

SSH mit Konqueror

Sowohl Konqueror als auch Krusader sind fähig, auf Daten eines entfernten Rechners zuzugreifen, indem sie das sftp-Protokoll benutzen, welches in ssh vorhanden ist.

So wird es gemacht:
1) Man öffnet ein neues Konqueror-Fenster
2) Die Syntax in der Adress-Leiste ist: sftp://username@ssh-server.com

Beispiel 1: ein Dialog-Fenster öffnet sich und fragt nach dem SSH-Passwort. Man gibt das Passwort ein und klickt auf OK:

sftp://sidux1@remote_hostname_or_ip

Beispiel 2: es wird nicht nach einem Passwort gefragt, man wird direkt verbunden.

sftp://username:password@remote_hostname_or_ip

Für eine LAN-Umgebung

sftp://username@10.x.x.x
oder
sftp://username@198.x.x.x
(Anmerkung: Bitte richtige IP eingeben!
Ein Dialog-Fenster fragt nach Eingabe des ssh-Passworts: dieses eingeben und auf OK klicken)

Eine SSH-Verbindung im Konqueror ist nun hergestellt. In diesem Konqueror-Fenster kann man mit den Dateien auf dem SSH-Server arbeiten, als wären es lokale Dateien.

ANMERKUNG: wenn ein anderer Port als 22 (Grundeinstellung) benutzt wird, muss dieser bei Verwendung von sftp/fish angegeben werden:

sftp://user@ip:port

'user@ip:port' - dies ist die Standardsyntax für viele Protokolle/Programme wie sftp, smb, fish.

SSHFS - auf einem entfernten Computer mounten

SSHFS ist eine einfache, schnelle und sichere Methode unter Verwendung von FUSE, um ein entferntes Dateisystem einzubinden. Auf Serverseite benötigt man ausschließlich einen laufenden ssh-daemon.

Auf Seite des Clients muss vermutlich sshfs erst installiert werden:

apt-get update && apt-get install sshfs

fuse und groups sind ab sidux eros auf der ISO und müssen nicht extra installiert werden.

Das Einbinden eines entfernten Dateisystems ist sehr einfach:

sshfs username@entfernter_hostname:verzeichnis lokaler_mountpunkt

Wobei username den Nutzernamen am entfernten Host-Rechner meint.

Wenn kein bestimmtes Verzeichnis angegeben wird, wird das Home-Verzeichnis des entfernten Nutzers eingebunden. Bitte beachten: der Doppelpunkt : ist unbedingt erforderlich, auch wenn kein Verzeichnis angegeben wird!

Nach erfolgter Einbindung verhält sich das entfernte Verzeichnis wie jedes andere lokale Dateisystem. Man kann wie auf einem lokalen Dateisystem nach Dateien suchen, diese lesen und ändern sowie Skripte ausführen.

Die Einbindung des entfernten Hosts wird mit folgendem Befehl gelöst:

fusermount -u lokaler_mountpunkt

Bei regelmäßiger Nutzung von sshfs empfiehlt sich ein Eintrag in /etc/fstab:

username@entfernter_hostname:/entferntes_verzeichnis /lokaler_mountpunkt fuse.sshfs user,allow_other,uid=1000,gid=1000,noauto 0 0

Dies ermöglicht jedem Nutzer der Gruppe fuse, das Dateisystem einzubinden bzw. zu lösen:

mount /pfad/zum/mount/punkt     # Einbindung
umount /pfad/zum/mount/punkt    # Lösen

Mit diesem Befehl prüft man, ob man Mitglied der Gruppe fuse ist:

cat /etc/group | grep fuse

Die Antwort sollte in etwa so aussehen:

fuse:x:117: <nutzername>

Falls der Nutzername (username) nicht gelistet ist, verwendet man als root den Befehl adduser:

adduser <nutzername> fuse

Zur Beachtung: Der Benutzer wird erst nach einem neuerlichen Einloggen Mitglied der Gruppe "fuse" sein.

Jetzt sollte der gewünschte Nutzername gelistet und folgender Befehl ausführbar sein:

mount lokaler_mountpunkt

und

umount lokaler_mountpunkt