{"id":533,"date":"2010-04-29T18:12:48","date_gmt":"2010-04-29T16:12:48","guid":{"rendered":"http:\/\/www.daniel-ritter.de\/blog\/?p=533"},"modified":"2024-05-12T15:24:17","modified_gmt":"2024-05-12T13:24:17","slug":"6-nutzliche-dinge-die-man-mit-ssh-tun-kann","status":"publish","type":"post","link":"https:\/\/www.daniel-ritter.de\/blog\/6-nutzliche-dinge-die-man-mit-ssh-tun-kann\/","title":{"rendered":"6 n\u00fctzliche Dinge, die man mit SSH tun kann"},"content":{"rendered":"

SSH ist wahrscheinlich mein liebstes St\u00fcck Software. Es ist frei, gibt mir Freiheit, es ist einfach zu benutzen und ist trotzdem sehr m\u00e4chtig. Mit SSH kann man Kommunikation verschl\u00fcsseln. Das klappt auf eine sehr universelle Weise f\u00fcr fast jedes Problem. In diesem kleinen Howto zeige ich 6 n\u00fctzliche Dinge die man – ohne zu gro\u00dfen Stress – mit SSH tun kann. SSH ist mehr als „nur“ eine sichere Remote-Shell!<\/p>\n

Ding #1 – Eine sichere Remote-Shell<\/strong><\/p>\n

\"ssh_console1\"<\/p>\n

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\u00fcber administrieren.<\/p>\n

Das geht sehr einfach:<\/p>\n

ssh user@box_B<\/pre>\n
Das verbindet Dich zu BOX B als „user“. Danach kann man als „user“ auf BOX B arbeiten.<\/span><\/p>\n
Manchmal ben\u00f6tigt man gar keine interaktive Sitzung zu einem entfernten Rechner, sondern m\u00f6chte lediglich ein einzelnes Kommando ausf\u00fchren.<\/p>\n
ssh user@box_B command<\/pre>\n
Hier wird man zu Box B als „user“ verbunden, das Kommando „command“ wird ausgef\u00fchrt, das Ergebnis landet auf der lokalen Standardausgabe und die Verbindung wird beendet.<\/span><\/p>\n
Ding #2 – Dateien zwischen Rechnern sicher kopieren<\/strong><\/p>\n
\"ssh_copy\"<\/p>\n
Cool, wir k\u00f6nnen 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.<\/p>\n
scp \/home\/me\/a_file.txt user@box_B:\/home\/me\/<\/pre>\n
Das kopiert die lokale Datei „\/home\/me\/a_file.txt“ auf Box A nach „\/home\/me\/a_file.txt“ auf Box B.<\/span><\/p>\n
Es funktioniert auch andersherum:<\/p>\n
scp user@box_B:\/home\/me\/b_file.txt \/home\/me<\/pre>\n
Das w\u00fcrde die Datei „\/home\/me\/b_file.txt“ von Box B ins Home-Verzeichnis auf Box A kopieren.<\/p>\n
Weil „scp“ so \u00e4hnlich funktioniert wie „cp“ sind auch Wildcards erlaubt:<\/p>\n
scp \/var\/log\/* user@box_B:\/home\/me\/logsbackup<\/pre>\n
Das kopiert alle Logfiles von Box A nach „\/home\/me\/logsbackup“ auf Box B.<\/span><\/p>\n
Ding #3 – Ein Verzeichnis auf einem entfernten Rechner ins lokale Dateisystem mounten<\/strong><\/p>\n
\"ssh_mount\"<\/p>\n
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\u00fctzlich, wenn man mit lokalen Programmen Remote-Files bearbeiten will. Ein gutes Beispiel daf\u00fcr w\u00e4re 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 \u00f6ffnen und speichern. Ganz so als w\u00e4ren die Dateien auf der loaklen Platte. Hierf\u00fcr ben\u00f6tigt man „sshfs“. Das FUSE-Filesystem ist in vielen Distributionen nicht standardm\u00e4ssig installiert aber meistens in den Repositories enthalten. Unter Debian und Ubuntu kann man es so installieren:<\/p>\n
apt-get install sshfs<\/pre>\n
Nach der Installation kann man beginnen es zu benutzen<\/span><\/p>\n
mkdir \/mnt\/b_data\r\nsshfs user@box_B:\/b_data \/mnt\/b_data<\/pre>\n
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:<\/span><\/p>\n
fusermount -u \/mnt\/b_data<\/pre>\n
Falls der unmount fehlschl\u00e4gt sollte man \u00fcberpr\u00fcfen, ob noch Dateien vom Remoterechner ge\u00f6ffnet sind oder ob man sich noch mit der Shell oder einem Dateimanager im gemounteten Verzeichnis befindet.<\/span><\/p>\n
Ding #4 – Unzensiert und anonym von „kritischen Orten“ aus im Web surfen<\/strong><\/p>\n
\"ssh_proxy\"<\/p>\n
Firmenrichtlinien, faschistische Regierungen, Internet-Cafes und andere unfreundliche Regelungen, Institutionen und Orte k\u00f6nnen einen sicheren und privaten Zugriff aufs Web ziemlich schwierig gestalten. Firewalls und Proxys k\u00f6nnten interessante Webseiten blocken, loggen wo man herumsurft, Man-In-The-Middle-Attacken ausf\u00fchren oder einfach nur ein mulmiges Gef\u00fchl generieren. SSH ist die L\u00f6sung f\u00fcr alle diese Probleme. Es bietet die M\u00f6glichkeit als Web-Proxy (SOCKS) zu arbeiten. Man verbindet sich einfach per SSH zur guten vertrauensw\u00fcrdigen BOX B und surft durch diese Verbindung.<\/p>\n
(Lokaler Browser <-> Lokaler SSH Proxy <-> SSH <-> Box B <-> Webseite)<\/p>\n
Dann kann niemand mehr im unfreundlichen lokalen LAN blockieren, zensieren oder schn\u00fcffeln.
\nKlingt gut? Es ist sogar sehr einfach einzurichten und zu benutzen! SSH bietet die „-D“ Option um einen SOCKS-Proxy auf der lokalen Maschine einzurichten:<\/p>\n
ssh -D 1234 user@box_B<\/pre>\n
Nun hat man einen SOCKS-Proxy der auf localhost Port 1234 lauscht. Nun muss man nur noch seinem Browser so konfigurieren, dass er f\u00fcr Internetverbindungen diesen Proxy benutzt. Man kann \u00fcberpr\u00fcfen ob alles funktioniert hat, wenn man im Browser eine Webseite aufruft, die die IP-Adresse ausgibt, die f\u00fcr die Verbindung genutzt wurde. http:\/\/www.whatismyip.com<\/a> w\u00fcrde 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<\/a> w\u00fcrde die Sache noch angenehmer machen.<\/p>\n
Ding #5 – Den Traffic von lokalen Programmen verschl\u00fcsseln und tunneln oder auf Dienste in LANs zugreifen, die normalerweise nicht \u00fcbers Internet erreichbar sind.
\n<\/strong><\/p>\n
\"ssh_tunnel_l\"<\/p>\n
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\u00fcrdigen Rechner schicken. Wie schon mit dem SOCKS-Proxy kann man Daten-Verkehr zun\u00e4chst durch diesen Tunnel schicken, zum Beispiel den vom lokalen E-Mail Client, damit er nicht durchs lokale LAN fliessen muss. Wir m\u00f6chten unsere E-Mail in einer „kritischen“ Umgebung abrufen. Skript Kiddies, bl\u00f6de Admins und Terror-China-Hacker k\u00f6nnten die Mail mitlesen oder sogar das E-Mail-Passwort mitsniffen. SSH hilft. Die Syntax f\u00fcr Tunnel mit SSH ist etwas krampfig und zun\u00e4chst ein ziemlicher Brain-Twister aber eigentlich ziemlich logisch und mit ein bisschen \u00dcbung nicht schwierig:<\/p>\n
ssh -L local_port:target_host:target_port user@box_B<\/pre>\n
zum Beispiel:<\/span><\/p>\n
ssh -L 10000:pop3.mailprovider.com:110 user@box_B<\/pre>\n
Was ist hier geschehen? SSH wurde angewiesen einen Tunnnel mit einem lokalen (-L)<\/b> Endpunkt auf Port 10000 anzulegen. Alles was in diesen lokalen Endpunkt an Daten hineingeworfen wird, fliesst zun\u00e4chst verschl\u00fcsselt 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\u00fcsselt zu Box B und von dort aus an den E-Mail-Provider. Der E-mail Account im lokalen Client ben\u00f6tigt somit also f\u00fcr 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.<\/p>\n
Falls sich der Server auf den zugegriffen werden soll nicht irgendwo im Internet sondern auf Box B selbst befindet, kann der Zielrechner nat\u00fcrlich auch BOX B sein:<\/p>\n
ssh -L 10000:127.0.0.1:110 user@box_B<\/pre>\n
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.<\/span><\/p>\n
Tunneln kann n\u00fctzlich sein um Internetdienste abzusichern, aber auch um auf Dienste in BOX B’s privatem Netzwerk zuzugreifen. Falls man einen von au\u00dfen zug\u00e4nglichen 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.<\/p>\n
Angenommen BOX B steht in einem Intrantet, das einen interessanten Webserver beherbergt, der aber nicht aus dem Ineternet zug\u00e4nglich ist. Dieser Server l\u00e4uft im LAN auf Kiste 192.168.0.77. Mit SSH tunnelt man nun einfach einen lokalen Port auf Port 80 des Webservers im LAN:<\/p>\n
ssh -L 10000:192.168.0.77:80 user@box_B<\/pre>\n
Wenn man nun „http:\/\/127.0.0.1:10000“ im lokalen Webbrowser aufruft landet man auf der Homepage des Webservers im entfernten Intranet.<\/p>\n
Ding #6 – Ein Tunnel – andersherum<\/strong><\/p>\n
\"ssh_tunnel_r_good\"<\/p>\n
Wenn #5 klar ist, sollten umgekehrte Tunnel kein Problem mehr sein. Hier wird ein entfernter<\/b> Endpunkt f\u00fcr den Tunnel erstellt. Alles was dort hineinfliesst wird verschl\u00fcsselt weitergeleitet an BOX A (den lokale Rechner) und danach an den Zielrechner weitergeleitet.<\/p>\n
ssh -R remote_port:target_host:target_port user@box_B<\/pre>\n
zum Beispiel:<\/span><\/p>\n
ssh -R 10000:pop3.mailprovider.com:110 user@box_B<\/pre>\n
Im E-Mail-Client w\u00fcrde man als POP-Server „Box B“ und Port „10000“ eintragen.
\nBOX B tunnelt dann den Traffic zun\u00e4chst sicher auf BOX A um. Box A leitet danach weiter an „pop3.mailprovider.com“ port „110“<\/p>\n
N\u00fctzliche Kommandozeilenoptionen f\u00fcr SSH<\/strong><\/p>\n
-c „Compress“<\/p>\n
Die „-c“ Option komprimiert die \u00fcbertragenen Daten mit gzip bevor sie durchs Inetrnet fliessen. Das erh\u00f6ht die Geschwindigkeit beim \u00dcbertragen von unkomprimierten Daten (so wie reinem Text) stark. Sie ist n\u00fctzlich beim \u00dcbertragen
\nlanger Textdateien oder beim Websurfen wenn man SSH als Proxy nutzt.<\/p>\n
ssh -c -D 1234 user@box_B<\/pre>\n
-g „Grant Access“<\/p>\n
Die „-g“ option eraubt anderen Rechnern als localhost auf die lokal angelegten Tunnelendpunkte zuzugreifen. So k\u00f6nnen also zum Beispiel auch andere Rechner im LAN die lokal angelegten Tunnel nutzen.<\/p>\n
ssh -L -g 10000:127.0.0.1:110 user@box_B<\/pre>\n
-p „Port“<\/p>\n
Die „-p“ Option ben\u00f6tigt man, wenn der entfernte SSH-Server nicht auf dem Standardport 22 lauscht.<\/p>\n
ssh -p 22000 user@box_b<\/pre>\n
-v „Verbose“<\/p>\n
Mit dieser Option kann man sehr viele technische Verbindungsinformationen sehen, falls man tiefer in SSH eintauchen m\u00f6chte.<\/p>\n
Mehr Lesestoff:<\/strong><\/p>\n
Ich habe versucht diesen Artikel so einfach wie m\u00f6glich 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:<\/p>\n
The SSH man page<\/a><\/p>\n
The SSH RFC<\/a><\/p>\n
Wikipedia on SSH<\/a><\/p>\n
SSH – The Definitive Guide by O’Reilly<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
SSH ist wahrscheinlich mein liebstes St\u00fcck Software. Es ist frei, gibt mir Freiheit, es ist einfach zu benutzen und ist trotzdem sehr m\u00e4chtig. Mit SSH kann man Kommunikation verschl\u00fcsseln. Das klappt auf eine sehr universelle Weise f\u00fcr fast jedes Problem. In diesem kleinen Howto zeige ich 6 n\u00fctzliche Dinge die man – ohne zu gro\u00dfen […]<\/p>\n","protected":false},"author":1,"featured_media":1901,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[36],"tags":[98,57,29,31,99],"class_list":["post-533","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ubuntu","tag-proxy","tag-spickzettel","tag-ssh","tag-tunnel","tag-verschlusseldung"],"_links":{"self":[{"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/posts\/533","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/comments?post=533"}],"version-history":[{"count":9,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/posts\/533\/revisions"}],"predecessor-version":[{"id":1902,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/posts\/533\/revisions\/1902"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/media\/1901"}],"wp:attachment":[{"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/media?parent=533"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/categories?post=533"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.daniel-ritter.de\/blog\/wp-json\/wp\/v2\/tags?post=533"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}