Johannes Franken Vortrag für die DaLUG am 22. November Johannes Franken OpenSSH 1 of 25

Transkript

1 Johannes Franken Vortrag für die DaLUG am 22. November 2002 Johannes Franken OpenSSH 1 of 25

2 Aktuellere Versionen dieses Dokuments gibt es möglicherweise hier: Inhalt A. Grundlagen 1. Bezugsquellen Alternativen ssh-protokolle 4. Konfiguration a. Client-Konfiguration b. Server-Konfiguration 5. Login Sessions a. Escape-Kommandos b. Interaktive Programme automatisch starten 6. Verschlüsselung 7. Komprimierung 8. Public key authentication a. ssh-keygen b. known_hosts ssh-keyscan B. c. d. authorized_keys i. ssh-copy-id e. Login ohne Passwortabfrage i. Leere Passphrase ii. ssh-agent, ssh-add SSH-Tunnels 1. X11 Forwarding 2. Pipes a. imap rsync b. c. scp, sftp d. uucp e. cvs 3. Local port forwarding 4. Remote port forwarding 5. Tunnels ineinander stecken 6. ppp over ssh C. Firewalls durchbohren 1. Motivation 2. Offene Ports nutzen 3. Vorhandene Proxyserver nutzen a. ssh over http i. httptunnel b. ssh over https i. ssh-https-tunnel ii. transconnect iii. proxytunnel 4. Empfehlungen Johannes Franken OpenSSH 2 of 25

3 Grundlagen Bezugsquellen OpenSSH ist eine Implementation der ssh-protokoll-suite. Der Quellcode ist offen und wird ständig weiterentwickelt vom OpenSSH-Projekt-Team, siehe OpenSSH ist für sämtliche Betriebssysteme compiliert worden und im Lieferumfang der meisten Linux-Distributionen enthalten. Ein exzellenter Windows-Port unter Verwendung von CygWin32 ist erhältlich auf Alternativen Putty ist eine weitere, freie ssh-implementation, welche im Gegensatz zu OpenSSH eine grafische Benutzeroberfläche bietet. Eine Windows-Version ist auf verfügbar, und es gibt bereits die ersten Linux-Ports. Dann gibt es noch einige kommerzielle SSH-Varianten, z.b. auf und Johannes Franken OpenSSH 3 of 25

4 ssh-protokolle Beim Einsatz von OpenSSH wird meist ein ssh-client (/usr/bin/ssh) einen ssh-server (/usr/sbin/sshd) ansprechen, der auf einem anderen Rechner laeuft und auf Port 22 lauscht. Im Laufe der Kommunikation kommen die verschiedensten Protokolle zum Einsatz. $ echo SSH-1.99-jfranken nc -w 1 gate 22 SSH-1.99-OpenSSH_3.4p1Debian1:3.4p1-1\n[...] diffie-hellman-group-exchange-sha1,diffie-hell man-group1-sha1\0\0\0017ssh-rsa,ssh-dss\0\0\0faes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se\0\0\0faes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator. liu.se\0\0\0uhmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@opens sh.com,hmac-sha1-96,hmac-md5-96\0\0\0uhmac-md5,hmac-sha1,hmac-ripem d160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96\0\0\0\tnone,zlib\0\0\0\tnone,zlib\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 Die Liste zeigt die in der ssh-protokollversion 2 enthaltenen Algorithmen. Eine Untermenge war bereits in der ssh-protokollversion 1 enthalten, die heute aus Sicherheitsgründen nicht mehr verwendet werden sollte. OpenSSH 3 spricht wahlweise die Protokollversionen 1 oder 2. Details zu den einzelnen Algorithmen gibt es hier: draft-galb-secsh-gssapi-00.txt draft-galb-secsh-publickey-channel-00.txt draft-ietf-secsh-architecture-06.txt draft-ietf-secsh-auth-kbdinteract-01.txt draft-ietf-secsh-connect-08.txt draft-ietf-secsh-transport-08.txt draft-ietf-secsh-userauth-08.txt draft-nisse-secsh-srp-00.txt draft-salowey-secsh-kerbkeyex-00.txt Johannes Franken OpenSSH 4 of 25

5 Konfiguration Client-Konfiguration Der ssh-client liest seine Konfiguration aus Kommandozeilenparametern, ~/.ssh/config und /etc/ssh/ssh_config. Der erste Treffer zählt. Die config-dateien erlauben die Definition von Host-Bereichen. z.b.: Host stunnel.our-isp.org ProxyCommand ~/.ssh/ssh-https-tunnel %h %p Port 443 Host hera 141.* User franken Protocol 1 Host 192.* gate mausi hamster tp Compression no Cipher blowfish Protocol 2 Host * ForwardAgent yes ForwardX11 yes Compression yes Protocol 2,1 Cipher 3des EscapeChar ~ Details: siehe: ssh(1), ssh_config(5) manpages. Server-Konfiguration Der ssh-server liest seine Konfiguration aus Kommandozeilenparametern und /etc/ssh/sshd_config Der erste Treffer zählt. Details: siehe: sshd(8), sshd_config(5) manpages. Johannes Franken OpenSSH 5 of 25

6 Login Sessions Durch Eingabe von ssh hostname eröffnet man eine Shell auf dem Rechner hostname. Die Anmeldung erfolgt mit dem selben Usernamen, mit dem man bereits eingeloggt ist. Wenn man sich auf dem anderen Rechner unter einem anderen Usernamen anmelden möchte, hilft entweder ssh -l username hostname ssh ssh -o User=username hostname ssh hostname und User hostname in der config-datei. Escape-Kommandos Während der ssh-sitzung kann man nach Eingabe von <Enter><Tilde> mit den folgenden Tasten Sonderfunktionen aufrufen:. Beendet die Sitzung inkl. aller Tunnels. & C beendet die Sitzung. Die Tunnels bleiben bestehen. Zeigt einen Prompt (ssh>), an dem man mit den Befehlen -L und -R nachträglich Portforwarding einrichten kann (Details: siehe Teil 2). <Strg-Z> Suspended die ssh. Man landet in der Shell, aus der man ssh aufgerufen hatte. Mit fg geht s weiter. # zeigt alle Verbindungen an, die gerade über die aktuelle ssh tunneln.? Hilfemenü. Zeigt auch die hier nicht genannten, eher unwichtigen Befehle an. Wer ein Keyboard-Layout mit deadkeys verwendet, drückt für ein Tildezeichen zweimal auf die Tilde-Taste. Wer mehrere ssh-sitzungen ineinander geschachtelt hat, erreicht den Escape-Modus der n-ten Shell (von außen gezählt) durch <Enter> und n-fachen Druck (bei deadkeys 2n-fach) auf die Tilde-Taste. Wem das zu kompliziert ist, der kann mit dem -e Parameter für jede ssh einen eigenen Escape-Charakter (z.b. <Strg-B>) bestimmen: jfranken@gate:~ $ ssh -e ^B hamster jfranken@hamster:~ $ <Strg-B>. Connection to hamster closed. jfranken@gate:~ $ Interaktive Programme automatisch starten $ ssh tp -t vim /etc/hosts Johannes Franken OpenSSH 6 of 25

7 Verschlüsselung ssh verschlüsselt die gesamte Kommunikation zum sshd, inkl. der Anmeldung und aller Tunnels. Man kann dabei zwischen verschiedenen Verschlüsselungsalgorithmen wählen, z.b. 3des gilt als besonders sicher, benötigt aber viel Rechenzeit blowfish arbeitet besonders schnell Hier sind einige Möglichkeiten zur Auswahl des blowfish-algorithmus, um im lokalen Netz die beteiligten CPU zu entlasten und somit die Kommunikation zu beschleunigen: ssh -c blowfish... ssh -o Cipher=blowfish... Eintrag Cipher blowfish für einige oder alle Hosts in der ~/.ssh/config oder /etc/ssh/ssh_config. In Verbindung mit Portforwarding lassen sich unsichere Netzwerkabschnitte für den Client völlig transparent verschlüsseln, etwa um zwei Firmenstandorte über das Internet zu verbinden: Komprimierung Wenn sich das Netzwerk als Engpaß herausstellt, kann man die Kommunikation zwischen ssh und sshd komprimieren. Das benötigt auf beiden Seitem etwas mehr CPU, spart jedoch etwa 50% der Netzwerk-Pakete ein. Aufruf: wahlweise ssh -C... ssh -o Compression=yes... Compression yes in ~/.ssh/config oder /etc/ssh/ssh_config einbauen. Zusätzlich sollte auf dem Server in /etc/ssh/sshd_config die Zeile Compression yes stehen. In Verbindung mit Portforwarding lassen sich langsame Netzwerkabschnitte (z.b. ISDN- oder DSL-Strecken) für den Client völlig transparent beschleunigen: Johannes Franken OpenSSH 7 of 25

8 Public key authentication Die Publickey-Authentifizierung beruht auf dem Prinzip asymmetrischer Verschlüsselung: Jeder der beiden Partner besitzt einen Schlüssel und kann damit Nachrichten so verschlüsseln, daß nur der andere sie entschlüsseln kann. Wenn einer nun seinen Schlüssel geheim hält ("private key"), kann der andere von der Authentizität seines Gegenüber ausgehen, sobald er eine Nachricht mit einem seiner eigenen Schlüssel ("public key") entschlüsseln kann. Der genaue Ablauf wird von den Algorithmen RSA, RSA1 oder DSA beschrieben. Auf die Spezialitäten der einzelnen Algorithmen gehe ich hier nicht weiter ein, als daß DSA die meiste CPU-Last erzeugt und RSA1 besonders leicht verwundbar ist. In vielen Fällen bietet RSA einen guten Kompromiss. Johannes Franken OpenSSH 8 of 25

9 ssh-keygen Jedes dieser Verfahren benötigt ein eigenes Schlüsselpaar, das man mit dem Befehl ssh-keygen erstellen kann: $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/export/home/jfranken/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /export/home/jfranken/.ssh/id_rsa. Your public key has been saved in /export/home/jfranken/.ssh/id_rsa.pub. The key fingerprint is: 7c:02:29:1c:d4:8a:90:ad:f2:b0:65:9e:71:92:ef:0f jfranken@hamster Der Fingerprint ist eine gemeinsame Eigenschaft von Private- und Publickey und ermöglicht es später festzustellen, welcher Privatekey zu einem Publickey passt: $ ssh-keygen -l -f.ssh/id_rsa a:b6:c4:50:ce:ec:18:78:e9:b2:e7:5b:04:c2:e4:c7.ssh/id_rsa.pub Mit dem -t-parameter bestimmt man den Algorithmus, zu dem man das Schlüsselpaar erzeugen möchte: Algorithmus Parameter für ssh-keygen Dateinamen Publickey beginnt mit RSA -t rsa für SSH ab Version 2 RSA für SSH Version 1 ~/.ssh/id_rsa[.pub] ssh-rsa -t rsa1 ~/.ssh/identity[.pub] o.ä, (bits exponent) DSA -t dsa ~/.ssh/id_dsa[.pub] ssh-dss Man kann die Passphrase des Privatekey leicht ändern: $ ssh-keygen -p -f ~/.ssh/id_rsa Enter old passphrase: Key has comment /export/home/jfranken/.ssh/id_rsa Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase. $ Der Publickey (~/.ssh/id_rsa.pub) wird mittels uuencode auf 6 bit Ascii codiert, sieht also wie eine lange Text-Zeile aus: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxtWFO8XbyT6+IlBAWYyOb /VWraJ7iymKVsb0TNmieBSzF6fgustkT0nX3udbSqTqiEC/wXFKqeyl27 bkd+recfba+s+wgv9mkraiv0kofvqravwrkns1qi6yzwzihsp7ks5qe0h Rra+gy/47vGwHUn0RxksGOQ6YsKP5lNN8H4E= jfranken@hamster Der Publickey setzt sich wie folgt zusammen: a. Der Key-Type (z.b. ssh-rsa, siehe Tabelle oben) b. Ein Leerzeichen c. Der Modulus (das ist die lange Folge von Buchstaben/Ziffern) d. optional: Ein Leerzeichen, gefolgt von einem Kommentar Man kann aus dem Privatekey einen Publickey erzeugen: $ ssh-keygen -y -f ~/.ssh/id_rsa ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA5+UaqG/zI... Johannes Franken OpenSSH 9 of 25

10 known_hosts Wer beim Aufbau einer ssh-verbindung ganz sicher gehen möchte, daß der erreichte Server auch der richtige ist, gibt die Option -o StrictHostkeyChecking=yes an oder trägt in der ~/.ssh/config für die betreffenden Hosts StrictHostkeyChecking yes ein. Der Client bricht dann die Verbindung ab, wenn der geheime Hostkey des Servers nicht zu dem Public-Key passt, der auf dem Client in ~/.ssh/known_hosts oder /etc/ssh/ssh_known_hosts abgelegt ist: $ ssh -o StrictHostkeyChecking=yes WARNING: REMOTE HOST IDENTIFICATION IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f. Please contact your system administrator. Add correct host key in /export/home/jfranken/.ssh/known_hosts to get rid of this message. Offending key in /export/home/jfranken/.ssh/known_hosts:45 RSA host key for gate has changed and you have requested strict checking. Host key verification failed. jfranken@hamster $ oder, wenn dieser Host noch gar nicht in der known_hosts eingetragen ist: jfranken@hamster $ ssh -o StrictHostkeyChecking=yes gate No RSA host key is known for gate and you have requested strict checking. Host key verification failed. jfranken@hamster $ Wer nicht alle Hostkeys manuell in die known_hosts-datei aufnehmen möchte, sollte StrictHostkeyChecking auf ask setzen: jfranken@hamster $ ssh -o StrictHostkeyChecking=ask gate The authenticity of host gate ( ) can t be established. RSA key fingerprint is 5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added gate, (RSA) to the list of known hosts. jfranken@gate $ Die Zeilen der known_hosts haben folgendes Format: 1. Liste von Hostnamen oder IP-Adressen eines Servers, durch Komma getrennt. Wildcards *? und Negation! sind erlaubt 2. Ein Leerzeichen 3. Der Publickey dieses Servers (ohne Kommentar) 4. optional: ein Leerzeichen, gefolgt von einem Kommentar Die Hostkeys befinden sich auf dem Server an folgenden Stellen: /etc/ssh/ssh_host_dsa_key[.pub] (im DSA-Format) /etc/ssh/ssh_host_rsa_key[.pub] (im RSA-Format für SSH Version ab Version 2) /etc/ssh/ssh_host_key[.pub] (im RSA-Format für SSH Version 1) Man kann diese Schlüssel mit ssh-keygen herstellen. Dabei ist zu beachten. daß man dem Privatekey eine leere Passphrase gibt. Bei vielen Distributionen wird diese Aufgabe beim Einspielen des sshd-pakets automatisch erledigt. Ändert sich der Hostkey eines Servers (z.b. nach einem SSH Versions-Update), muß man die entsprechenden Zeile aus der known_hosts entfernen oder aktualisieren. Details: siehe: sshd(8) manpage Johannes Franken OpenSSH 10 of 25

11 ssh-keyscan Wer viele Hostkeys in eine known_hosts-datei eintragen muß, kann diese mit ssh-keyscan von jedem Client aus abfragen und die Ausgabe direkt an die known_hosts anhängen. Details: siehe: ssh-keyscan(1) manpage authorized_keys Alternativ zu der Eingabe eines Passwortes kann man ein Schlüsselpaar zur Authentifikation verwenden, wobei der Privatekey wiederum mit einer Passphrase geschützt sein kann. Vorteile der Publickey- gegenüber Passwort-Authentifikation: Die Schlüssel sind mit Brute-Force wesentlich aufwendiger zu erraten als Passwörter Wer meinen Publickey hat, kann mich leicht auf seinen Server einladen Ich muß mir für alle Zugänge nur eine einzige Passphrase merken, die ich jederzeit mit einem Kommando ändern kann Auf dem Server liegt nur mein Public-Key, mit dem allein noch niemand auf andere Systeme zugreifen kann. Es besteht insbesondere nicht das Risiko, daß jemand mit Brute-Force auf /etc/shadow mein Passwort ertestet. Wenn mehrere User auf den selben Account zugreifen, kann jeder seine eigene Passphrase verwenden. Die Verwendung von Public-keys ist einfach: Zunächst erstellt man auf dem Client beispielsweise mit ssh-keygen -t rsa ein Schlüsselpaar, wie oben beschrieben. Den Public-key kopiert man dann als eine lange Zeile in die Datei ~/.ssh/authorized_keys auf dem Server. Am Zeilenanfang der Einträge in der ~/.ssh/authorized_keys kann man zusätzlich dem sshd jeweils mitteilen, von welchen Rechnern man sich mit diesem Schlüssel einloggen darf und welche Besonderheiten (Environmentvariablen, Shell, ssh-optionen) dabei gelten. Die genaue Syntax der Zeilen lautet: Optional eine Liste von Optionen, durch Komma getrennt, gefolgt von einem Leerzeichen. Beispiele: a. environment="sshkey=jfranken" b. command="./menu.pl" c. from="*.jfranken.de,egal.our-isp.org" d. no-port-forwarding e. no-x11-forwarding f. permitopen="host:port" g. no-agent-forwarding h. no-pty Der Public-Key (siehe *.pub-datei) ohne Kommentar optional: Ein Leerzeichen und ein Kommentar Wenn dann noch auf dem Server in der /etc/ssh/sshd_config die Option PasswordAuthentication No eingestellt ist, kann man sich nur noch mit dem Schlüssel anmelden, was ziemlich gute Sicherheit bietet. Details: siehe: sshd(8) manpage ssh-copy-id Wer öfters seinen Publickey auf Servern platzieren muß, wird gerne auf ein kleines Shellscript namens ssh-copy-id zurückgreifen, das über eine ssh-pipe einfach den Publickey an die authorized_keys auf dem Server anhängt. Leider verwendet es defaultmäßig den Publickey für RSA1 (~/.ssh/identity.pub). Wer lieber mit RSA(2)-keys arbeitet, kann entweder die Parameter -i ~/.ssh/id_rsa.pub angeben, oder die von mir gepatchte Version verwenden: $./ssh-copy-id2 s password: Now try logging into the machine, with "ssh franken@hera.cs.uni-frankfurt.de ", and check in:.ssh/authorized_keys to make sure we haven t added extra keys that you weren t expecting. jfranken@hamster $ Details: siehe: ssh-copy-id(1) manpage Johannes Franken OpenSSH 11 of 25

12 Login ohne Passwortabfrage Leere Passphrase Wenn die Passphrase eines Privatekey leer und der Publickey in der ~/.ssh/authorized_keys auf dem Server enthalten ist, lässt sich ssh wunderbar in Scripte einbauen. Dann sollte man jedoch sehr darauf achten, daß kein Unbefugter Zugriff auf die Privatekey-Datei hat. ssh-agent, ssh-add Der ssh-agent bietet eine Lösung für User, die es leid sind, immer wieder die selbe Passphrase einzugeben, aber aus Sicherheitsgründen auch nicht ganz auf eine Passphrase verzichten möchten. Damit muß ein Hacker zumindest Zugriff auf den lokalen Rechner und die Socketdatei erlangen, um den Privatekey zu benutzen. Wenn man ssh-agent ohne Parameter aufruft, erstellt er einen Unix-Domain-Socket, teilt uns mit, wie man ihn dort erreichen kann und lauscht im Hintergrund darauf: $ ssh-agent > myagent.sh $ cat myagent.sh SSH_AUTH_SOCK=/tmp/ssh-XXcMloql/agent.21753; export SSH_AUTH_SOCK; SSH_AGENT_PID=21754; export SSH_AGENT_PID; echo Agent pid 21754; $ Mit ssh-add bringt man dem ssh-agent seine Privatekeys und Passphrases bei: $../myagent.sh Agent pid 21754; $ ssh-add ~/.ssh/id_rsa Enter passphrase for /export/home/jfranken/.ssh/id_rsa: Identity added: /export/home/jfranken/.ssh/id_rsa (/export/home/jfranken/.ssh/id_rsa) $ Wenn man keinen Privatekey angibt, werden die Standard-keys (identity,id_rsa und id_dsa) geladen. Eine Übersicht der in den agent geladenen Keys erhält mit ssh-add -l, und die zugehörigen Publickeys mit ssh-add -L. Der ssh-client wird dann bei jedem Verbindungsaufbau die Privatekeys aus dem ssh-agent probieren, statt denen aus den Identity-Dateien: jfranken@hamster $../myagent.sh Agent pid 21754; jfranken@hamster $ ssh gate [...] debug1: userauth_pubkey_agent: testing agent key /export/home/jfranken/.ssh/id_rsa debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x80926f8 hint -1 [...] jfranken@gate $ Details: siehe: ssh-agent(1) manpage ssh-add(1) manpage Johannes Franken OpenSSH 12 of 25

13 SSH-Tunnels X11 Forwarding Unter Unix ist es üblich, Anwendungen ("X-Clients") auf anderen Rechnern aufzurufen und am eigenen Bildschirm ("X-Server") zu bedienen. Es gibt zwei Methoden des Verbindungsaufbaus: ohne X11-Tunnel: $ xhost gate gate being added to access control list $ ssh gate $ export DISPLAY=hamster:0 $ netscape & [1] $ mit X11-Tunnel: $ export DISPLAY=:0 $ ssh -X gate $ echo $DISPLAY localhost:10.0 $ netscape & [1] $ Hierzu muß auf gate die libx.so und xauth installiert sein und X11Forwarding yes in /etc/ssh/sshd_config stehen. Alternativ zu dem -X-Parameter kann man dem ssh den Parameter -o ForwardX11 yes übergeben oder in der ~/.ssh/config-datei ForwardX11 yes eintragen. Bewertung: Kriterium ohne X11-Tunnel mit X11-Tunnel Die Kommunikation läuft unverschlüsselt über s Netz. Ein Verschlüsselung anderer Netzteilnehmer könnte z.b. alle Tastendrücke und eingegebenen Passwörter mitschneiden. X11-Security Der X-Server muß von aussen per tcp-port 6000 erreichbar sein, was weitere Gefahren bietet, z.b. unbefugtes Bildschirmauslesen Die Kommunikation erfolgt verschlüsselt. Der Zeitverlust für die Verschlüsselung wird durch die Kompression mehr als wett gemacht. Der X-Server darf mit -nolisten tcp aufgerufen sein, was vor unberechtigten Zugriffen anderer Netzteilnehmer schützt. Johannes Franken OpenSSH 13 of 25

14 Firewall/NAT Diese Methode funktioniert nicht mehr, sobald eine Firewall dazwischen steht. Die Verwendung von X11-Tunnels über ssh bringt also klare Vorteile. Kein Problem mit Firewalls, solange sie ssh durchlassen. Pipes Wenn man ssh einen Befehl übergibt und nicht den -t-parameter setzt, leitet ssh stdin/stdout/stderr des Befehls unverändert an die aufrufende Shell weiter. Auf diese Weise kann man ssh in Pipes einbauen: Die folgende Befehlsfolge zeigt den Füllstand der Rootpartition des Rechners gate an: $ ssh gate df awk /\/$/ {print $5} 64% $ Die folgende Befehlsfolge kopiert das Verzeichnis mydir in das /tmp-verzeichnis des Rechners gate $ tar cf - mydir/ ssh gate cd /tmp && tar xpvf - Johannes Franken OpenSSH 14 of 25

15 imap Imap ist ein Protokoll zum Übertragen von Mails. Leider sendet es die Mails dabei unverschlüsselt über s Netz. Wer Shellzugriff auf seinen Mailserver hat, sollte es über ssh tunneln, was die Übertragung wesentlich sicherer (Verschlüsselung, Publickey-Authentifikation) und schneller (Kompression) macht. Am einfachsten geht das, indem der Mailuseragent auf dem Mailserver einen imapd im PreAuth-Modus aufruft und sich über stdin/stdout der ssh mit diesem unterhält: jfranken@hamster $ ssh gate imapd * PREAUTH [ ] IMAP4rev1 v server ready Beispiele zur Konfiguration einiger Mailuseragents: fetchmail: Alle Mail an die Domain jfranken.de landet bei meinem Provider (our-isp.org), von wo fetchmail sie regelmäßig über imap auf meinen lokalen Mailserver (gate.jfranken.de) abholt. Mit der folgenden ~/.fetchmailrc tunnelt fetchmail die imap-kommunikation über ssh: poll johannes.our-isp.org with options proto imap, preauth ssh, plugin "ssh -x -C jfranken@%h \ /usr/local/bin/imapd Maildir 2>/dev/null", smtphost gate, fetchall mutt: Meine Mail liegt also auf gate, und ich greife normalerweise lokal mit mutt über imap darauf zu. Falls ich dies von einem anderen Rechner versuche (z.b. mit dem Notebook über s Internet), tunnelt mutt die imap-kommunikation zu gate über ssh. Folgende Zeilen in der ~/.muttrc ermöglichen das: set tunnel="imapd ssh -qc jfranken@gate.jfranken.de imapd" set folder="{gate}~/mail" rsync rsync ist ein geniales Tool zum inkrementellen Spiegeln von Verzeichnissen, z.b. über verschiedene lokale Festplatten, nfs oder smbfs. Wenn man es mit dem Parameter -e ssh aufruft, tunnelt es sämtliche Kommunikation über eine ssh-pipe, gerne auch über s Internet. Mit folgendem Aufruf übertrage ich die Webseiten auf meinen Webserver: rsync --delete -a -e ssh./ jfranken@ Details: siehe rsync web pages scp, sftp Tools zum Kopieren von Dateien über ssh. Details: siehe: scp(1), sftp(1) manpages. Johannes Franken OpenSSH 15 of 25

16 uucp uucp dient dem Bereitstellen, Abholen und und Weiterverarbeiten von Dateien. Die traditionelle Anwendung besteht in der Verteilung von s und usenet-news. Da die Anmeldung unverschlüsselt über s Netz geht, empfehle ich, die gesamte Kommunikation über ssh zu tunneln. Hierzu richte man dem user uucp auf dem antwortenden System für jeden möglichen Anrufer eine Zeile in der ~uucp/.ssh/authorized_keys ein: no-port-forwarding,no-x11-forwarding,no-agent-forwarding, command="/usr/sbin/uucico -l" ssh-rsa AAAAB3NzaC1yc2... Auf dem anrufenden System konfiguriere ich einen speziellen Modemport, der eben alles über ssh piped: /etc/uucp/sys: system YOURPROVIDER call-login * call-password * time any chat "" \d\d\r\c ogin: \d\l word: \P chat-timeout 30 protocol i port ssh /etc/uucp/port: port ssh type pipe command /usr/bin/ssh -qi ~/.ssh/id_rsa.uucp uucp@yourprovider reliable true protocol etyig cvs cvs ist ein Programm zur Versionsverwaltung beliebiger Dateien. Zusätzlich löst es die Konflikte, die dadurch entstehen, daß mehrere User gleichzeitig an den selben Dateien Änderungen vornehmen. Zum Abgleich greift cvs entweder über das Filesystem (also lokal, nfs, samba etc.) auf ein gemeinsames Verzeichnis zu, oder kommuniziert mit einem CVS-Server, den man beispielsweise über ssh ansprechen kann. Zur Einrichtung eines CVS-Servers empfehle ich, auf dem Repository-Rechner einen User cvs anzulegen, in dessen Homedir das Repository liegt und ihm in seiner ~/.ssh/authorized_keys für jeden Benutzer eine Zeile anzulegen, die einen CVS-Server-Prozess startet: no-port-forwarding,no-x11-forwarding,\ command="/usr/bin/cvs server" ssh-rsa AAAAB3NzaC1yc2... Um den CVS-Server anzusprechen, geben Benutzer zuerst folgende Befehle ein: $ export CVS_RSH=ssh $ export CVSROOT=:ext:cvs@host:/export/home/cvs und können dann wie gewohnt mit cvs arbeiten: $ cvs co module Johannes Franken OpenSSH 16 of 25

17 Local port forwarding Wenn ich auf hamster ssh -g -L 4321: gate aufrufe, baut ssh eine Verbindung zu gate auf, lauscht währenddessen auf Port 4321 und reicht alle dort ankommenden TCP-Verbindungen an den sshd an gate weiter, der sie an Port 80 von weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von hamster:4321 auf gelegt. Im Browser würde also genauso aussehen wie die Webseite von IBM. Man muss auf hamster Rootrechte haben, um einen lokalen Port <1024 zu öffnen. Wenn man den -g Parameter weglässt, können Clients den Port nur über die IP-Adresse oder entsprechende Aliase (z.b. localhost) erreichen, müssen also auf dem selben Rechner wie der ssh-client laufen, oder aus einem anderen Tunnel dort umsteigen. Remote port forwarding Wenn ich auf hamster ssh -R 9030:intranet:80 gate eingebe, nimmt der sshd auf gate die Verbindung entgegen, lauscht auf Port 9030 und reicht alle dort ankommenden Verbindungen an den ssh-client auf hamster weiter, der sie auf den Port 80 von intranet weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von gate:9030 nach intranet:80 gelegt. Wer im Browser aufruft, landet auf dem Intranetserver. Man muss auf gate Rootrechte haben, um einen remote Port <1024 zu öffnen. Wer den Rootzugriff per ssh nicht erlauben möchte, kann den ssh-tunnel auf einen hohen Port (z.b. 9030) legen und mit xinetd auf Port 80 umleiten. Hierzu folgende /etc/xinetd.d/intranet: # Leitet alle Requests an Port 80 auf Port 9030 um. service intranet { type = UNLISTED flags = REUSE socket_type = stream protocol = tcp user = root wait = no instances = UNLIMITED port = 80 redirect = localhost 9030 disable = no } Der sshd nimmt normalerweise nur lokale Anfragen entgegen. Wenn er auch die Anfragen von anderen Rechnern entgegen nehmen soll, trage man in der /etc/ssh/sshd_config auf gate die Zeile GatewayPorts yes ein oder leite den Port wie oben beschrieben um. Johannes Franken OpenSSH 17 of 25

18 Tunnels ineinander stecken Mit dem -p Parameter weise ich den ssh-client an, den sshd auf einem anderen Zielport als 22 anzusprechen. Das ist z.b. sinnvoll, wenn ich eine ssh-verbindung über einen bereits bestehenden Tunnel aufbauen möchte. Mit jedem weiteren Tunnel erhöhe ich die Reichweite um bis zu zwei Hosts: Anzahl Tunnels Max. Hops Die folgende Abbildung zeigt, wie man mit zwei ineinander gesteckten Tunnels bereits fünf hosts beteiligen kann, etwa um eine VNC-Verbindung durch drei Firewalls zu tunneln: Johannes Franken OpenSSH 18 of 25

19 ppp over ssh Das Point-to-point-Protokoll beschreibt Verbindungsaufbau und Kommunikation zwischen zwei virtuellen Netzwerkinterfaces. Mit etwas Aufwand kann man es auch über ssh tunneln, und beliebige IP-Pakete transparent über eine ssh-verbindung routen. Konfiguration des Servers: Installation ppp (z.b. Version uus-4 aus Debian GNU/Linux 3.0) Dateirechte ueberpruefen: $ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip Dez 2001 /usr/sbin/pppd* 3. Einen Benutzer anlegen, der zum Aufruf des pppd berechtigt wird: $ adduser --group dip pppuser 4. PAP-Passwort und IP-Adressbereich vergeben: $ echo pppuser * geheim * >> /etc/ppp/pap-secrets 5. In der ~pppuser/.ssh/authorized_keys den RSA-keys IP-Adressen zuordnen (Eine Zeile pro Publickey): no-port-forwarding,no-x11-forwarding,no-agent-forwarding,\ command="/usr/sbin/pppd remotename pppuser\ : notty debug"\ ssh-rsa AAAAB3NzaC Die /etc/ppp/ip-up.d/*-scripte von allen störenden Initialisierungen bereinigen, welche die Distribution für die Interneteinwahl vorgesehen hatte. Konfiguration des Client: Installation ppp (z.b. Version uus-4 aus Debian GNU/Linux 3.0) Sicherstellen, dass der User den pppd setsuid aufrufen kann: $ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip Dez 2001 /usr/sbin/pppd* $ usermod -G dip jfranken 3. Einen neuen Provider anlegen: $ cat >/etc/ppp/peers/ssh <<FERTIG pty ssh -e none pppuser@gate false user pppuser nodetach noauth # debug FERTIG 4. Das PAP-Passwort des Serves eintragen: $ echo pppuser * geheim >> /etc/ppp/pap-secrets 5. /etc/ip-up.d/* ggf. anpassen (z.b. defaultroute auf $PPP_IFACE umsetzen) So sieht der Verbindungsaufbau aus, wenn alle geklappt hat: jfranken@hamster:~ $ /usr/sbin/pppd call ssh Using interface ppp0 Connect: ppp0 <--> /dev/ttyp4 Remote message: Login ok kernel does not support PPP filtering Deflate (15) compression enabled Johannes Franken OpenSSH 19 of 25

20 Cannot determine ethernet address for proxy ARP local IP address remote IP address Übersicht aller Optionen zu pppd: siehe pppd(8) manpage. Johannes Franken OpenSSH 20 of 25

21 Firewalls durchbohren Motivation ssh-verbindungen stellen für Firmen ein enormes Risiko dar, schließlich können darüber an Virenscannern und Logfiles vorbei Tunnels gelegt und Dateien übertragen werden. Viele Firmen haben daher auf ihren Routern oder Firewalls den Zugriff auf Port 22 aller Internetteilnehmer verboten. Da heute jedoch praktisch kein Unternehmen auf einen Internetanschluß verzichten kann, bestehen meist doch gewisse Löcher in der Firewall. Im Folgenden zeige ich, wie man diese entdeckt und eine ssh-verbindung darüber aufbaut. Mit den Kenntnissen aus Teil 2 (insb. ppp-over-ssh) ist es damit trivial, beliebige IP-Verbindungen durch nahezu jede Firewall zu betreiben. Johannes Franken OpenSSH 21 of 25