SSH ist wahrscheinlich mein liebstes Stück Software. Es ist frei, gibt mir Freiheit, es ist einfach zu benutzen und ist trotzdem sehr mächtig. Mit SSH kann man Kommunikation verschlüsseln. Das klappt auf eine sehr universelle Weise für fast jedes Problem. In diesem kleinen Howto zeige ich 6 nützliche Dinge die man – ohne zu großen Stress – mit SSH tun kann. SSH ist mehr als „nur“ eine sichere Remote-Shell!
Ding #1 – Eine sichere Remote-Shell
Das ist das Offensichtlichste was man mit SSH tun kann und die meisten Linuxuser haben es wohl schon einmal gemacht: Eine sichere Verbindung mit einem anderen Rechner herstellen und diesen darüber administrieren.
Das geht sehr einfach:
ssh user@box_B
Das verbindet Dich zu BOX B als „user“. Danach kann man als „user“ auf BOX B arbeiten.
Manchmal benötigt man gar keine interaktive Sitzung zu einem entfernten Rechner, sondern möchte lediglich ein einzelnes Kommando ausführen.
ssh user@box_B command
Hier wird man zu Box B als „user“ verbunden, das Kommando „command“ wird ausgeführt, das Ergebnis landet auf der lokalen Standardausgabe und die Verbindung wird beendet.
Ding #2 – Dateien zwischen Rechnern sicher kopieren
Cool, wir können eine entfernte Maschine mit SSH administrieren, aber man kann mit SSH auch Dateien von einer Maschine zu einer anderen kopieren. Es funktioniert im Grunde so wie das „cp“ Kommando, es heisst aber „scp“ – Secure Copy.
scp /home/me/a_file.txt user@box_B:/home/me/
Das kopiert die lokale Datei „/home/me/a_file.txt“ auf Box A nach „/home/me/a_file.txt“ auf Box B.
Es funktioniert auch andersherum:
scp user@box_B:/home/me/b_file.txt /home/me
Das würde die Datei „/home/me/b_file.txt“ von Box B ins Home-Verzeichnis auf Box A kopieren.
Weil „scp“ so ähnlich funktioniert wie „cp“ sind auch Wildcards erlaubt:
scp /var/log/* user@box_B:/home/me/logsbackup
Das kopiert alle Logfiles von Box A nach „/home/me/logsbackup“ auf Box B.
Ding #3 – Ein Verzeichnis auf einem entfernten Rechner ins lokale Dateisystem mounten
Manchmal reicht es nicht einfach nur einige Dateien von einem Rechner auf einen anderen zu kopieren. Ein entferntes Verzeichnis ins lokale Dateisystem zu mounten ist super nützlich, wenn man mit lokalen Programmen Remote-Files bearbeiten will. Ein gutes Beispiel dafür wäre zum Beispiel die Arbeit an einer Webseite auf einem entfernten Server. Man kann einfach das Web-Verzeichnis des entfernten Servers ins lokale Dateisystem mounten und danach die Dateien mit all den coolen lokal installierten HTML-Editoren und Grafikprogrammen öffnen und speichern. Ganz so als wären die Dateien auf der loaklen Platte. Hierfür benötigt man „sshfs“. Das FUSE-Filesystem ist in vielen Distributionen nicht standardmässig installiert aber meistens in den Repositories enthalten. Unter Debian und Ubuntu kann man es so installieren:
apt-get install sshfs
Nach der Installation kann man beginnen es zu benutzen
mkdir /mnt/b_data sshfs user@box_B:/b_data /mnt/b_data
Das mountet das Verzeichnis „/b_data“ auf Box B nach „/mnt/b_data“ im lokalen Dateisystem. Nun kann man mit lokalen Programm die Remote-Dateien bearbeiten. Wenn man fertig ist, kann man den mount wieder entfernen:
fusermount -u /mnt/b_data
Falls der unmount fehlschlägt sollte man überprüfen, ob noch Dateien vom Remoterechner geöffnet sind oder ob man sich noch mit der Shell oder einem Dateimanager im gemounteten Verzeichnis befindet.
Ding #4 – Unzensiert und anonym von „kritischen Orten“ aus im Web surfen
Firmenrichtlinien, faschistische Regierungen, Internet-Cafes und andere unfreundliche Regelungen, Institutionen und Orte können einen sicheren und privaten Zugriff aufs Web ziemlich schwierig gestalten. Firewalls und Proxys könnten interessante Webseiten blocken, loggen wo man herumsurft, Man-In-The-Middle-Attacken ausführen oder einfach nur ein mulmiges Gefühl generieren. SSH ist die Lösung für alle diese Probleme. Es bietet die Möglichkeit als Web-Proxy (SOCKS) zu arbeiten. Man verbindet sich einfach per SSH zur guten vertrauenswürdigen BOX B und surft durch diese Verbindung.
(Lokaler Browser <-> Lokaler SSH Proxy <-> SSH <-> Box B <-> Webseite)
Dann kann niemand mehr im unfreundlichen lokalen LAN blockieren, zensieren oder schnüffeln.
Klingt gut? Es ist sogar sehr einfach einzurichten und zu benutzen! SSH bietet die „-D“ Option um einen SOCKS-Proxy auf der lokalen Maschine einzurichten:
ssh -D 1234 user@box_B
Nun hat man einen SOCKS-Proxy der auf localhost Port 1234 lauscht. Nun muss man nur noch seinem Browser so konfigurieren, dass er für Internetverbindungen diesen Proxy benutzt. Man kann überprüfen ob alles funktioniert hat, wenn man im Browser eine Webseite aufruft, die die IP-Adresse ausgibt, die für die Verbindung genutzt wurde. http://www.whatismyip.com würde funktionieren, aber es gibt auch 1000de andere Seiten. Wenn dort die IP von Box B erscheint, ist alles in Butter. Ein portalbler Browser auf einem USB-Stick wie zum Beispiel Portable Firefox würde die Sache noch angenehmer machen.
Ding #5 – Den Traffic von lokalen Programmen verschlüsseln und tunneln oder auf Dienste in LANs zugreifen, die normalerweise nicht übers Internet erreichbar sind.
OK, wir haben sicher Maschinen administriert, Dateien sicher von Maschine zu Maschine kopiert und haben sogar in China unzensiert im Web gesurft. Aber SSH kann mehr! Man kann damit den Datenaustausch aller lokalen Programme die TCP benutzen durch einen Tunnel zu einem vertrauenswürdigen Rechner schicken. Wie schon mit dem SOCKS-Proxy kann man Daten-Verkehr zunächst durch diesen Tunnel schicken, zum Beispiel den vom lokalen E-Mail Client, damit er nicht durchs lokale LAN fliessen muss. Wir möchten unsere E-Mail in einer „kritischen“ Umgebung abrufen. Skript Kiddies, blöde Admins und Terror-China-Hacker könnten die Mail mitlesen oder sogar das E-Mail-Passwort mitsniffen. SSH hilft. Die Syntax für Tunnel mit SSH ist etwas krampfig und zunächst ein ziemlicher Brain-Twister aber eigentlich ziemlich logisch und mit ein bisschen Übung nicht schwierig:
ssh -L local_port:target_host:target_port user@box_B
zum Beispiel:
ssh -L 10000:pop3.mailprovider.com:110 user@box_B
Was ist hier geschehen? SSH wurde angewiesen einen Tunnnel mit einem lokalen (-L) Endpunkt auf Port 10000 anzulegen. Alles was in diesen lokalen Endpunkt an Daten hineingeworfen wird, fliesst zunächst verschlüsselt zu Box B und danach zu „pop3.mailprovider.com“ auf port 110 (Port 110 ist POP3). Die Daten fliessen also vom lokalen E-Mail Client verschlüsselt zu Box B und von dort aus an den E-Mail-Provider. Der E-mail Account im lokalen Client benötigt somit also für den POP-Server folgende Einstellungen: Server: localhost / Port: 10000. Aber es muss nicht unbedingt E-Mail sein. Jede Applikation, die das TCP-Protokoll benutzt kann so getunnelt werden. Zum Beispiel IRC, FTP, HTTP, IMAP, etc.
Falls sich der Server auf den zugegriffen werden soll nicht irgendwo im Internet sondern auf Box B selbst befindet, kann der Zielrechner natürlich auch BOX B sein:
ssh -L 10000:127.0.0.1:110 user@box_B
Ziel in diesem Beispiel ist „127.0.0.1“, weil es das Ziel aus der Sicht von Box B ist. Denn „127.0.0.1“ gesehen von Box B ist Box B selbst.
Tunneln kann nützlich sein um Internetdienste abzusichern, aber auch um auf Dienste in BOX B’s privatem Netzwerk zuzugreifen. Falls man einen von außen zugänglichen SSH-Account in einem LAN besitzt, kann man so auf alle TCP-Dienste in diesm LAN zugreifen, ganz so als sei man ein „echter“ Client in diesem LAN.
Angenommen BOX B steht in einem Intrantet, das einen interessanten Webserver beherbergt, der aber nicht aus dem Ineternet zugänglich ist. Dieser Server läuft im LAN auf Kiste 192.168.0.77. Mit SSH tunnelt man nun einfach einen lokalen Port auf Port 80 des Webservers im LAN:
ssh -L 10000:192.168.0.77:80 user@box_B
Wenn man nun „http://127.0.0.1:10000“ im lokalen Webbrowser aufruft landet man auf der Homepage des Webservers im entfernten Intranet.
Ding #6 – Ein Tunnel – andersherum
Wenn #5 klar ist, sollten umgekehrte Tunnel kein Problem mehr sein. Hier wird ein entfernter Endpunkt für den Tunnel erstellt. Alles was dort hineinfliesst wird verschlüsselt weitergeleitet an BOX A (den lokale Rechner) und danach an den Zielrechner weitergeleitet.
ssh -R remote_port:target_host:target_port user@box_B
zum Beispiel:
ssh -R 10000:pop3.mailprovider.com:110 user@box_B
Im E-Mail-Client würde man als POP-Server „Box B“ und Port „10000“ eintragen.
BOX B tunnelt dann den Traffic zunächst sicher auf BOX A um. Box A leitet danach weiter an „pop3.mailprovider.com“ port „110“
Nützliche Kommandozeilenoptionen für SSH
-c „Compress“
Die „-c“ Option komprimiert die übertragenen Daten mit gzip bevor sie durchs Inetrnet fliessen. Das erhöht die Geschwindigkeit beim Übertragen von unkomprimierten Daten (so wie reinem Text) stark. Sie ist nützlich beim Übertragen
langer Textdateien oder beim Websurfen wenn man SSH als Proxy nutzt.
ssh -c -D 1234 user@box_B
-g „Grant Access“
Die „-g“ option eraubt anderen Rechnern als localhost auf die lokal angelegten Tunnelendpunkte zuzugreifen. So können also zum Beispiel auch andere Rechner im LAN die lokal angelegten Tunnel nutzen.
ssh -L -g 10000:127.0.0.1:110 user@box_B
-p „Port“
Die „-p“ Option benötigt man, wenn der entfernte SSH-Server nicht auf dem Standardport 22 lauscht.
ssh -p 22000 user@box_b
-v „Verbose“
Mit dieser Option kann man sehr viele technische Verbindungsinformationen sehen, falls man tiefer in SSH eintauchen möchte.
Mehr Lesestoff:
Ich habe versucht diesen Artikel so einfach wie möglich zu schreiben, da er mir selbst in erster Linie als Referenz dienen soll. Es gibt aber noch sehr viel mehr was man mit SSH tun kann:
Hallo,
danke für deinen Beitrag. Das ist eine sehr gute Hilfe.
Beste Grüße
Michael
Sehr geiler Artikel! Danke für die Arbeit die du dir da gemacht hast! :)
Was ich noch als Vorschlag einbringen möchte:
Wie greife ich auf die in Punkt #4 bis #6 geöffneten Tunnels mit PuTTY zu. Zumindest Punkt 5 lässt sich in PuTTY mit ein paar Mausklicks mehr vor dem Verbinden mit dem entfernten SSH-Server easy einrichten.
Hallo Daniel,
Tolle Zusammenfassung, hat mir gut weitergeholfen und mich über den Tellerrand hinausblicken lassen!
Danke dafür.
Gruß Meho
Hi,
erstmal Danke für das gut zusammengefasste Tutorial.
Falles jemand das gleiche Problem hat antworte ich mal auf die alte Anfrage von Bernd:
Ohne lokalen Zugriff auf die Maschine oder das root Passwort ist es ohne hacks, die Bugs nutzen, nicht möglich. Das ist auch gut so. Bei lokalem Zugriff und der Möglichkeit zu booten einfach im Grub e (für edit) drücken. Dann am Ende der Kernel Zeile „init=/bin/bash“ anhängen und schon kann man das root passwort in /etc/shadow zurücksetzen.
Dafür muss man natürlich das root filesytem vorher rw remounten.
Hallo Daniel,
nachdem ich stundenlang in linux-Foren gesucht und nix gefunden habe, wende ich mich an dich. Ich habe meine root-Rechte verloren: In der Konsole erscheint die Meldung: bernd is not in the sudoers file. This incident will be reported.
bernd@bernd-desktop:~$
der Befehl groups gibt folgendes Ergebnis: bernd vboxusers, der Befehl id: id
uid=1000(bernd) gid=1000(bernd) Gruppen=123(vboxusers),1000(bernd)
Es sieht so aus, als ob ich nicht mehr Mitglied der admin-Gruppe bin. Wie komme ich da wieder hin?
Für ne kurze Antwort bin ich Dir, Euch sehr dankbar.
Gruß
Bernd