SSH (SecureShell) ist inzwischen sehr verbreitet. Es hat bzw. sollte Telnet überall ersetzt haben. SSH nutz eine Verschlüsselung um zwischen zwei Rechnern Daten auszutauschen. SSH kann aber noch vieles mehr. Z.B. kannst du mit scp einfach, schnell und sicher Dateien von einem Rechner auf einen anderen Kopieren.
scp dateien user@rechner:/pfad
Du kannst aber auch X-Weiterleitungen sehr einfach realisieren. Hierzu musst du einfach in deine
sshd_config folgende Option auf
yes setzten.
X11Forwarding yes
Mal angenommen du besitzt ein altes (SEHR) altes Notebook. Dieses Notebook hat gerade noch genug Leistung zum Hochfahren und starten des X-Servers. Dieses Notebook könntest du jetzt als eine Art X-Terminal benutzen. D.h.: du tipperst ein:
ssh -X rechner
in deine X-Konsole und meldest dich nun mit deinen Usernamen an einem Zweitrechner in deinem Netzwerk an, welcher etwas mehr Leistung hat und auch gleich noch die Programme installiert sind, mit denen du jetzt gerne auf dem Notebook arbeiten willst. Du tipperst nach der Anmeldung also
ooffice oder was du halt gerade brauchst ein. Darauf bekommst du dann nur die GUI auf dein Notebook. Die gesamte Datenverarbeitung und Rechenleistung für das genutzte Programm kommt nun vom anderen Rechner.
Bist du mal über eine sehr schwache Leitung an dein System angeschlossen kann dir die Option
-C sehr helfen. Diese sorgt dafür das der gesamte Datenstrom komprimiert wird. So ist die zu übertragende Datenmenge kleiner und alles sollte flotter gehen.
ssh -C rechner
Wie sicher ist dieses SSH denn nun?
Man kann sagen, recht sicher. Es gibt natürlich keine absolute Sicherheit und es hängt auch immer ein großer Teil vom User und der Konfiguration ab.
Du solltes also einige Punkte in der Konfiguration seines SSH-Servers ändern. Diese liegt fast immer unter:
/etc/ssh/ und schimpft sich
sshd_config!
– Nur SSH2
Das SSH1 Protokoll gilt als unsicher. Programme wie z.b.:
ettercap sind in der Lage hier Kennwörter und Usernamen herauszulesen. Zu dem bietet SSH2 eine ganze Stange mehr an Möglichkeiten. Daher sollte nur das Protocol 2 genutzt werden.
Protocol 2
– Root-Login is nicht
Der User Root braucht keinen direkten Login. Wer wirklich von extern auf seinem Rechner administrieren will der kann als User auch
su oder
sudo benutzen. Da SSH2 wohl kaum zu entschlüsseln ist, wird ein Angreifer es meist mit
Brute Force versuchen. Er braucht zu dem Kennwort welches er damit bekommen möchte erst mal einen Usernamen. Da er Root haben will und dieser wohl auch
immer auf einer Linux-Kiste zu finden ist, wird er es auch auf diesen Account probieren. Verbieten wir jetzt aber den Login für den User Root kann der Angreifer es sehr lange Probieren.
PermitRootLogin no
– Kein User/Passwort verfahren
Die Geschichte mit dem
Brute Force hatten wir ja jetzt. Was aber wenn der Angreifer einen Usernamen von unserem System kennt. Dann ist es erstmal nur noch eine Frage der Zeit. Tja und da die meisten User keine „guten“ Passwörter haben….. Viel besser ist es wenn der User ein Zertifikat hat, mit welchem er sich anmelden darf. Weiter unten zeige ich wie es gemacht wird. Hier aber erstmal das User/Passwort verfahren verbieten!
PasswordAuthentication no
Das Public-Key-Verfahren (jetzt kommt die Beschreibung) ist da viel besser. Zuerst bauen wir einen schön langen Schlüssel auf dem Client:
ssh-keygen -b 4068 -t dsa
Nun tauchen im Homeverzeichniss des Users, mit dem wir den Schlüssel erstellt haben, unter:
~/.ssh/ zwei Dateien auf:
id_dsa und
id_dsa.pub. Den Publickey
id_dsa.pub packen wir nun auf den Server. Direkt in die Datei
authorized_keys (vielleicht müssen wir diese noch mit der Hilfe von
touch anlegen). Die Datei sollte im Homeverzeichniss des zu autorisierenden Users im Ordner
.ssh angelegt werden. Haben wir das alles so eingetragen brauchen wir kein Kennwort mehr.
Wie wäre es mit einem Tunnel durch die Firewall?
OK… klingt ja ganz nett. Aber warum sollte ich einen Tunnel in meine Firewall machen?
Das kann ich dir erklären. Stell dir mal vor du sitzt mit deinem Notebook in einem Netzwerk wo du dir nicht sicher bist das keiner deine Verbindungen abhört oder gar die Verbindungen über bestimmte Ports blockiert sind. Du willst nun aber eine E-Mail schreiben! Oder bestimmte Ports sonst wie durch diese oder eine andere Firewall verschlüsselt tunneln.
Um einen einfachen Tunnel zu basteln musst du jetzt nur noch folgendes machen:
Computer2:
ssh -N -R 5555:localhost:22 user@erreichbarer_rechner
Jetzt passiert etwas feines 🙂 Denn nun geht am „erreichbarer_rechner“ der Port 5555 auf und der beamt dann alles durch den Tunnel an Computer2 an den Port 22 weiter.
Du kannst nun also sitzen wo du willst. Sobald du versuchst dich auf Port 5555 mit dem Computer „erreichbarer_rechner“ zu verbinden, wird deine Anmeldeanfrage direkt an Computer2 weitergeleitet. So bekommst du also sofort das Login von Computer 2.
ssh erreichbarer_rechner -p 5555
Geil, was?
Siehe auch: SSH-Server mit MFA absichern
Fragen? Einfach melden.
Beim Booten zeigen beide Monitore schon mal das gleiche an. Zumindest bis der X-Server gestartet wird. Bei mir werkelt der X.org.
Ist dieser gestartet wird der zweite Monitor abgeschaltet und alles läuft weiter wie gehabt. 🙁
Also schnell STRG + ALT + F1 gedrückt als root angemeldet und direkt mit dem vi in die xorg.conf….
Hier habe ich nun folgendes eingetragen:
]
[Mobile: +49 0177 5995900
