SSH Spickzettel. ssh starten und per ssh anmelden. Verzeichnisse können auch rekursiv (samt Unterverzeichnissen) kopiert werden:

Transkript

1 SSH Spickzettel c LUG-Ottobrunn.de :27 ssh starten und per ssh anmelden ssh baut abgesicherte Verbindungen zu anderen Rechnern auf. Auf dem Server, zu dem man Kontakt aufnehmen will, muß ein ssh-daemon laufen. ssh wird bei den meisten Linux Distributionen defaultmäßig installiert. Der ssh-daemon wird wie folgt gestartet: /etc/init.d/ssh start Läuft ein ssh-server auf der Gegenseite z.b. auf einer Maschine namens rmt, und ist auf dieser Maschine ein User namens arthur eingerichtet, so kann sich arthur auf rmt anmelden ssh arthur@rmt Der Rechner rmt fragt nach dem Passwort für arthur, bei korrekter Passworteingabe ist arthur eingeloggt und der Datentransfer erfolgt verschlüsselt. Auch das Passwort ist verschlüsselt übertragen worden. Mit ssh sicher kopieren Will arthur eine Datei aus dem Rechner an dem er gerade sitzt zu rmt übertragen, kann er es so machen: scp meinfile arthur@rmt:/home/arthur/tee/sorte/schwarz/ Andersherum geht es auch, arthur kann Dateien aus rmt zu seiner lokalen Maschine holen: scp arthur@rmt:/home/arthur/tee/sorten/schwarz/ziehzeit.txt./ Verzeichnisse können auch rekursiv (samt Unterverzeichnissen) kopiert werden: scp -r arthur@rmt:/home/arthur/tee./ Lästige Passwortabfragen vermeiden Bei allen zuvor gezeigten kommandozeilen fragt der ssh-server nach dem Passwort für den User arthur. Das kann auf die Dauer lästig werden. Umgehen kann man dies wenn 1

2 man sich ein Key-Paar generiert. Dies geschieht mit: ssh-keygen -t rsa -b 2048 ssh-keygen wird fragen wohin er die Dateien mit den keys (id_rsa und id_rsa.pub) ablegen soll. Return drücken um die Defaults zu übernehmen. Das Programm fragt auch nach einer Passphrase, da auch Return drücken, sonst wird jedesmal nach der Passphrase gefragt, da wo früher nach dem Passwort gefragt wurde. Unser Ziel ist es ja ohne Passworteingabe durchzukommen. Achtung: Die Sicherheit des Gesamtsystems entspricht nur noch der Sicherheit des Passworts der lokalen Maschine. Ausweg: Die Datei id_rsa nicht auf den Rechnern liegen lassen die man benutzt, sondern in einem USB-Stick in der Hosentasche mit den anderen Schlüsseln aufbewahren und bei bedarf nach /.ssh/id_rsa kopieren oder mounten (Beim gemounteten USB-Stick ssh -i /mount/pfad/id_rsa als Kommandozeile verwenden). So ist der ssh-zugang so sicher wie das Auto oder das eigene Haus. Wie geht s weiter? Die Datei id_rsa ist der private Schlüssel, die soll geheim bleiben. id_rsa.pub ist der öffentliche Schlüssel und muß zum ssh-server. Das erledigt man am besten mit scp :-) scp /home/arthur/.ssh/id_rsa.pub arthur@rmt:/home/arthur/ ssh arthur@rmt cat id_rsa.pub >>.ssh/authorized_keys chmod go-rwx.ssh/authorized_keys Von jetzt an braucht man kein Passwort mehr eingeben. Alternative: Public-Keys können auch mit ssh-copy-id auf den Zielrechner kopiert werden. ssh-copy-id arthur@rmt Wenn sich die Public-Keys nicht in /.ssh/id_rsa.pub befinden, muß man mit dem Schalter -i den Pfad angeben ssh-copy-id -i /pfadzumkey/keyfile arthur@rmt ssh-copy-id setzt auch die Rechte der Datei.ssh/authorized_keys richtig. Alternative: Alles in einem für Kommandozeilenninjas: cat /.ssh/*.pub ssh arthur@rmt cat >> ~/.ssh/authorized_keys&& \ chmod 700 ~/.ssh&&chmod 600 ~/.ssh/authorized_keys Wenn man mit Keys arbeitet ist man bereits sicher im Netz unterwegs. Um eventuellen Man-in-the-middle-Attacken vorzubeugen gibt es die Möglichkeit sich den Key beim Login graphisch anzeigen zu lassen. Das erreicht man mit der Konfigurationsoption 2

3 VisualHostKey, die standardmäßig deaktiviert ist. ssh -o VisualHostKey=yes your.host.name Host key fingerprint is aa:bb:cc:dd:ee:ff:aa:bb:cc:dd:ee:ff:11 +--[ RSA 1024]----+ oo. +o o.. E S... o o ooo.. ooo Kommandos auf andere Rechner ausführen Mit ssh arthur@rmt haben wir gesehen daß man sich an einem anderen Rechner einloggen kann. Fügt man der Kommandozeile einen Befehl an, so wird er auf dem anderen Rechner ausgeführt. Die Ergebnisse werden auf dem lokalen Rechner angezeigt. Beispiel: arthur will eine Liste der Dateien in seinem Homeverzeichnis auf rmt, dazu will er noch den Inhalt von einem anderen Verzeichnis namens public unter seinem home. Das Ganze will er in eine lokale Datei abspeichern. Dies kann arthur so tun ssh arthur@rmt cd;echo -home-;ls;cd public;echo -public-;ls > rmtlist Remote X11 Programme auf lokalem Display Will arthur die X11 Ausgabe von Programmen, die auf rmt laufen, auf seiner lokalen Maschine ansehen, so braucht er nur ssh -X arthur@rmt Von jetzt an werden X11-Fenster zu seiner lokalen Maschine geleitet. xhost-freigaben werden ebensowenig gebraucht wie das Setzen der DISPLAY Variable. Wenn man weiß daß man nur ein Programm braucht, dann genügt: ssh -X arthur@rmt xpdf ssh_cheat.pdf Arbeiten mit einer langsamen Verbindung Bei einer langsamen Verbindung kann man den Datenstrom komprimieren. Der Kom- 3

4 pressionsalgorithmus entspricht dem vom gzip. Sowohl ssh als auch scp kennen den -C Schalter um die Kompression zu aktivieren. scp -C./grosseDatei.txt Man kann auch eine X-Session komprimiert Übertragen: ssh -C -X Pipes gehen mit ssh auch. Ein Beispiel: Arbeiten mit pipes tar cvf-. gzip -c ssh cd tmp; cat>mytarfile.tgz Schauen wir uns die Einzelteile im Detail an: tar cvf- läßt tar auf stdout schreiben. Die Daten werden dem gzip -c über die Pipe weitergereicht. gzip holt sich die Daten von stdin weil wir keinen Dateinamen zum Komprimieren angegeben haben. Der Schalter -c bewirkt daß gzip auf stdout schreibt. ssh arthur loggt sich auf rmt ein, wechselt nach /tmp mit dem Befehl cd /tmp; dort wird mit cat>mytarfile.tgz der Datenstrom vom gzip -c übernommen und auf mytarfile.tgz geschrieben. Was hier gemacht wird könnte durchaus Schritt für Schritt durchgeführt werden. Für einen Kommandozeilenfanatiker hat diese Befehlskette einen gewissen ästhetischen Wert. Außerdem kann sowas nützlich sein wenn auf der lokalen Maschine nur noch wenig Festplattenplatz vorhanden ist und man trotzdem die Daten übertragen muß. Filesystem mounten (als User) mit ssh Wenn viele Dateibewegungen zwischen der lokalen Maschine und dem Server stattfinden, ist es vorteilhafter das Dateisystem des Servers auf der lokalen Maschine zur Verfügung zu haben. Ein Dateisystem als nicht root User zu mounten ist durch fuse möglich. Für fuse gibt es den sshfs Treiber, der es möglich macht Dateisysteme, die per ssh erreichbar sind, lokal zu mounten. Alle Daten werden verschlüsselt übertragen und man braucht die scp-orgien nicht mehr. Wenn nicht vorhanden fuse und/oder sshfs installieren (root, lokale Maschine) apt-get install sshfs User in fuse-gruppe eintragen (root, lokale Maschine) usermod -G -a fuse arthur 4

5 fuse starten wenn nicht in /etc/modules vorhanden (root, lokale Maschine) modprobe fuse Jetzt ist alles vorbereitet, arthur hat schon auf seiner lokalen Maschine ein Verzeichnis /rmtdata vorbereitet. Mounten als sterblicher mit sshfs sshfs ~/rmtdata arthurs Homeverzeichnis auf rmt ist jetzt lokal verfügbar. Seine Daten werden verschlüsselt transportiert. Alle Dateisystemfunktionen stehen ihm zur Verfügung. Nach getaner Arbeit an den Dateien wird unmounted: fusermount -u ~/rmtdata Tunnelbauen mit ssh: Mail senden und empfangen Es passiert oft im Hotel, bei Benutzung eines Wireless-Access Point oder einfach wenn man hinter einer etwas restriktiven Firewall sitzt, daß man entweder keinen Zugang zu den privaten s hat (Hotel-Firewall falsch konfiguriert, restriktive Firewall läßt keine Verbindung mit den benötigten Ports zu. Im Falle vom Wireless-Access Point: keiner will seine s über den AEther schicken wo jeder mithören kann). Hier hilft ssh durch die tunnelfähigkeit weiter. Das Szenario sieht wie folgt aus: Dienst Server Port SMTP smtp.svr.net 25 POP3 pop3.svr.net 110 Mit ssh kann man einen Tunnel einrichten über den die Kommunikation mit den entsprechenden Diensten erfolgen kann. ssh -L10025:smtp.server.net:25 Alle Datenpakete die zum lokalen Port geschickt werden, werden über ssh (verschlüsselt) an rmt übertragen. Der rechner rmt schickt diese Pakete weiter zum Port 25 (SMTP Port) auf smtp.server.net. Jetzt können wir Mails empfangen, senden können wir aber noch nicht. Das wird auch mit einem Tunnel erledigt, die Kommandozeile für den ganzen Mailtunnel ist dann: ssh -L10025:smtp.server.net:25 -L10110:pop3.svr.net:110 5

6 Den Mail-Client muß man umkonfigurieren um die neuen Ports zu nutzen. Zum Mail senden muß SMTP-Server=localhost und Port=10025 gesetzt werden. Der Empfang funktioniert nachdem man POP3-Server=localhost und Port=10110 konfiguriert hat. Danach funktioniert das Abrufen und senden der s verschlüsselt und wird nicht mehr durch Firewallregeln, die die Ports 25 und 110 filtern, blockiert. Tunnelbauen mit ssh: Proxy gefällig? Szenario: Port 22 ist noch offen. Andere Ports werden von der Firewall nicht durchgelassen oder gefiltert. Wir wollen aber trotzdem surfen/chatten/usw. und zwar ohne einschränkungen! ssh kann da auch helfen. Mit: ssh -N -D 8080 verwandeln wir unsere ssh-verbindung in ein SOCKS-Server. Der -N Schalter weist ssh an keine Befehle auf dem Remotehost auszuführen. Danach müssen die Clients entsprechend konfiguriert werden. Bei allen Clients herausfinden wo die Verbindungseinstellungen konfiguriert werden Dort suchen wir nach Einstellmöglichkeiten für einen SOCKS-Server Zur Sicherheit alle alten Einstellungen aufschreiben Eintragen von localhost als Server und 8080 als Port SOCKS-Version 5 einstellen (wenn möglich) Was machen wenn der Client keinen SOCKS-Protokoll versteht? Tunnelbauen mit ssh: Kur für SOCKS-taube Clients Wenn Clients gebraucht werden die SOCKS nicht verstehen können, muß man zusätzlich nachschauen ob ein Programm namens tsocks auf dem Rechner installiert ist. Wenn nicht: local installieren. Dann einen Tunnel mit ssh aufbauen, also ssh -N -D 8080 arthur@rmt ausführen. Danach ein Paar Zeilen in der shell ausführen: TSOCKS_CONF_FILE=$HOME/.tsocks.conf export TSOCKS_CONF_FILE In die Datei /.tsocks.conf schreibt man : server = server_port = 8080 Wenn man jetzt ein Program aufruft das eine Verbindung zum Internet herstellen muß, dann muß man tsocks voranstellen: tsocks wget -r -k -np de.wikipedia.org 6

7 Was jetzt passiert ist daß tsocks die connect-funktion des Kernels durch seine eigene ersetzt, und dadurch alle Verbindungen (außer lokale Netzwerkverbindungen) auf :8080 umbiegt. Da hört ja unser ssh-proxy der alles weiterleitet. Damit hat unser Program eine Verbindung zum Internet ohne was von einem Proxy oder von SOCKS zu wissen. ssh ohne port 22 Manchmal werden Firewalls so konfiguriert daß Verbindungen zu Port 22 (ssh Port) nicht zugelassen sind. In diesem Fall kann arthur von seinem Rechner aus nichts machen. Sobald er Zugang zu rmt hat, kann er den dort laufenden ssh Daemon so umkonfigurieren daß er auf andere Ports hört. Ein Port der selten gesperrt wird ist Port 443, dieser wird von SSL-Verbindungen benutzt die für sichere Webseiten gebraucht werden. /etc/ssh/sshd_config ändern, als root auf rmt Zeile mit Port=22 in der Datei finden, wenn nicht vorhanden einfügen. Port=443 der Datei hinzufügen. sshd neu starten als root auf rmt /etc/init.d/ssh restart Um den gesperrten Port 22 nicht mehr benuten zu müssen kann arthur jetzt seinen ssh client anweisen einen anderen Port zu verwenden. Dies macht er indem er den -p Schalter verwendet. ssh -p 443 -D 8080 Damit hat arthur jetzt einen SOCKS server auf rmt gestartet. Der Server nimmt alle Daten vom lokalen Port 8080 und leitet sie an rmt über den Port 443 (Kommunikation über ssh wie immer verschlüsselt) weiter. Wenn ein Server im Internet steht, ist es immer von Vorteil den ssh Daemon auf einen Port größer 1024 laufen zu lassen, weil die meisten Portscans auf die unteren 1024 Ports ausgeführt werden. Außerdem sind alle Attacken auf Port 22 ausgelegt und dort läuft dann ja kein ssh Daemon mehr. Somit gehen diese automatischen Attacken daneben. Tunnel kontrolliert dauerhaft offen halten Ein sehr nützliches Tool beim Umgang mit Tunnels ist autossh. autossh dient dazu eine ssh Verbindung zu starten und zu überwachen, wenn notwendig wird diese neugestartet, sollte sie abreißen und aufhören Datenverkehr durchzulassen. Die Verwendung gestaltet sich denkbar einfach: Zum Beispiel wollen wir die SMTP und die POP3 Verbindung vom vorhergehenden Beispiel dauerhaft aufrecht erhalten 7

8 autossh -M L10025:smtp.server.net:25 -L10110:pop3.svr.net:110 autossh benötigt nur die Angabe eines Management-Ports mit -M. Der Port kann frei zwischen gewählt werden. Danach hängt man einfach den gesamten ssh Befehl an. ssh als VPN verwenden OpenVPN unterstützt TUN/TAP Devices. Über diese lassen sich richtige VPN Verbindungen aufbauen. Damit man diese Funktion verwenden kann müssen nachfolgende Parameter in der sshd_config des Servers gesetzt sein: PermitTunnel yes PermitRootlogin yes Nur wenn man root auf dem Client und dem Server ist kann man dann diese Funktion nutzen. ssh -w any:any Durch den Parameter -w any:any wird auf Server und Client das nächste freie tun Device initialisiert. Sind noch keine tun Devices vorhanden wird auf beiden Seiten das tun0 angelegt. Dann muss man am Server und am Client jeweils das tun0 konfigurieren. Client: ifconfig tun pointopoint Server: ifconfig tun pointopoint Nun muss man noch entsprechende routen einrichten und dann kann man auch schon loslegen. route add -host rmt dev eth0 route add -net <ip adresse von rmt>/24 dev tun0 Bitte noch an eventuelle Firewall oder NAT Einstellungen denken! Könnte zum Beispiel so aussehen: echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 8

9 Notizen 9

10 Notizen 10

11 Notizen 11

12 Notizen 12

13 Notizen 13

14 Notizen 14

15 Notizen 15

16 Notizen 16