SSH Spickzettel
|
Download | |
|---|---|
|
Publikum : Fortgeschrittene | |
| Du bist hier : | Wiki home -> LUG Projekte -> Spickzettel -> SSH Spickzettel |
<latex titlecmd>ssh</latex> starten und per <latex titlecmd>ssh</latex> anmelden
<latex inline>ssh</latex> baut abgesicherte Verbindungen zu anderen Rechnern auf. Auf dem Server, zu dem man Kontakt aufnehmen will, muß ein <latex inline>ssh</latex>-Daemon laufen. <latex inline>ssh</latex> wird bei den meisten Linux Distributionen defaultmäßig installiert. Der <latex inline>ssh</latex>-Daemon wird wie folgt gestartet:
/etc/init.d/ssh start
Läuft ein <latex inline>ssh</latex>-Server auf der Gegenseite z.B. auf einer Maschine namens <latex inline>rmt</latex>, und ist auf dieser Maschine ein User namens <latex inline>arthur</latex> eingerichtet, so kann sich <latex inline>arthur</latex> auf <latex inline>rmt</latex> anmelden
ssh arthur@rmt
Der Rechner <latex inline>rmt</latex> fragt nach dem Passwort für <latex inline>arthur</latex>, bei korrekter Passworteingabe ist <latex inline>arthur</latex> eingeloggt und der Datentransfer erfolgt verschlüsselt. Auch das Passwort ist verschlüsselt übertragen worden.
Mit <latex titlecmd>ssh</latex> sicher kopieren
Will <latex inline>arthur</latex> eine Datei aus dem Rechner an dem er gerade sitzt zu <latex inline>rmt</latex> übertragen, kann er es so machen:
scp meinFile arthur@rmt:/home/arthur/tee/sorte/schwarz/
Andersherum geht es auch, <latex inline>arthur</latex> kann Dateien aus <latex inline>rmt</latex> 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 <latex inline>ssh</latex>-Server nach dem Passwort für den User <latex inline>arthur</latex>. Das kann auf die Dauer lästig werden. Umgehen kann man dies wenn man sich ein Key-Paar generiert. Dies geschieht mit:
ssh-keygen -t rsa -b 2048
<latex inline>ssh-keygen</latex> wird fragen wohin er die Dateien mit den keys (<latex inline>id_rsa</latex> und <latex inline>id_rsa.pub</latex>) ablegen soll. <latex inline>Return</latex> drücken um die Defaults zu übernehmen. Das Programm fragt auch nach einer Passphrase, da auch <latex inline>Return</latex> 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.
<latex render=red>Achtung:</latex> Die Sicherheit des Gesamtsystems entspricht nur noch der Sicherheit des Passworts der lokalen Maschine.
<latex render=red>Ausweg:</latex> Die Datei <latex inline>id_rsa</latex> 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 <latex inline>~/.ssh/id_rsa</latex> kopieren oder mounten (Beim gemounteten USB-Stick <latex inline>ssh -i /mount/pfad/id_rsa</latex> als Kommandozeile verwenden). So ist der <latex inline>ssh</latex>-Zugang so sicher wie das Auto oder das eigene Haus.
Wie geht's weiter? Die Datei <latex inline>id_rsa</latex> ist der private Schlüssel, die soll geheim bleiben. <latex inline>id_rsa.pub</latex> ist der öffentliche Schlüssel und muß zum <latex inline>ssh</latex>-Server. Das erledigt man am besten mit <latex inline>scp</latex> :-)
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.
<latex render=green>Alternative:</latex> Public-Keys können auch mit <latex inline>ssh-copy-id</latex> auf den Zielrechner kopiert werden.
ssh-copy-id arthur@rmt
Wenn sich die Public-Keys nicht in <latex inline>/.ssh/id_rsa.pub</latex> befinden, muß man mit dem Schalter <latex inline>-i</latex> den Pfad angeben
ssh-copy-id -i /pfadzumkey/keyFile arthur@rmt
<latex inline>ssh-copy-id</latex> setzt auch die Rechte der Datei <latex inline>.ssh/authorized_keys</latex> richtig.
<latex render=green>Alternative:</latex> Alles in einem für Kommandozeilenninjas:
cat /.ssh/*.pub|ssh arthur@rmt 'cat >> ~/.ssh/authorized_keys&& \<latex latexonly>textbackslash</latex> 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 <latex inline>VisualHostKey</latex>, 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 <latex inline>ssh arthur@rmt</latex> 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 <latex inline>rmt</latex>, dazu will er noch den Inhalt von einem anderen Verzeichnis namens <latex inline>public</latex> 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 <latex inline>arthur</latex> die <latex inline>X11</latex> Ausgabe von Programmen, die auf <latex inline>rmt</latex> laufen, auf seiner lokalen Maschine ansehen, so braucht er nur
ssh -X arthur@rmt
Von jetzt an werden <latex inline>X11</latex>-Fenster zu seiner lokalen Maschine geleitet. <latex inline>xhost</latex>-Freigaben werden ebensowenig gebraucht wie das Setzen der <latex inline>DISPLAY</latex> 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 Kompressionsalgorithmus entspricht dem vom gzip. Sowohl <latex inline>ssh</latex> als auch <latex inline>scp</latex> kennen den <latex inline>-C</latex> Schalter um die Kompression zu aktivieren.
scp -C ./grosseDatei.txt arthur@eddie:~/
Man kann auch eine X-Session komprimiert Übertragen:
ssh -C -X arthur@eddie
Arbeiten mit pipes
Pipes gehen mit <latex inline>ssh</latex> auch. Ein Beispiel:
tar cvf- . | gzip -c | ssh arthur@rmt 'cd tmp; cat>myTarfile.tgz'
Schauen wir uns die Einzelteile im Detail an: <latex inline>tar cvf-</latex> läßt <latex inline>tar</latex> auf <latex inline>stdout</latex> schreiben. Die Daten werden dem <latex inline>gzip -c</latex> über die Pipe weitergereicht. <latex inline>gzip</latex> holt sich die Daten von <latex inline>stdin</latex> weil wir keinen Dateinamen zum Komprimieren angegeben haben. Der Schalter <latex inline>-c</latex> bewirkt daß <latex inline>gzip</latex> auf <latex inline>stdout</latex> schreibt. <latex inline>ssh arthur@rmt</latex> <latex inline>arthur</latex> loggt sich auf <latex inline>rmt</latex> ein, wechselt nach <latex inline>/tmp</latex> mit dem Befehl <latex inline>cd /tmp;</latex> dort wird mit <latex inline>cat>myTarfile.tgz</latex> der Datenstrom vom <latex inline>gzip -c</latex> übernommen und auf <latex inline>myTarFile.tgz</latex> 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 <latex titlecmd>ssh</latex>
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 <latex inline>root</latex> User zu mounten ist durch <latex inline>fuse</latex> möglich. Für <latex inline>fuse</latex> gibt es den <latex inline>sshfs</latex> Treiber, der es möglich macht Dateisysteme, die per <latex inline>ssh</latex> erreichbar sind, lokal zu mounten. Alle Daten werden verschlüsselt übertragen und man braucht die <latex inline>scp</latex>-Orgien nicht mehr.
- Wenn nicht vorhanden <latex inline>fuse</latex> und/oder <latex inline>sshfs</latex> installieren (root, lokale Maschine)
apt-get install sshfs
- User in fuse-Gruppe eintragen <latex render=red>(root, lokale Maschine)</latex>
usermod -G -a fuse arthur
- <latex inline>fuse</latex> starten wenn nicht in <latex inline>/etc/modules</latex> vorhanden <latex render=red>(root, lokale Maschine)</latex>
modprobe fuse
Jetzt ist alles vorbereitet, <latex inline>arthur</latex> hat schon auf seiner lokalen Maschine ein Verzeichnis <latex inline>~/rmtdata</latex> vorbereitet.
- Mounten als sterblicher mit <latex inline>sshfs</latex>
sshfs arthur@rmt:~/ ~/rmtdata
<latex inline>arthur</latex>s Homeverzeichnis auf <latex inline>rmt</latex> 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 <latex titlecmd>ssh</latex>: 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 E-Mails 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 E-Mails über den AEther schicken wo jeder mithören kann).
Hier hilft <latex inline>ssh</latex> 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 <latex inline>ssh</latex> kann man einen Tunnel einrichten über den die Kommunikation mit den entsprechenden Diensten erfolgen kann.
ssh arthur@rmt -L10025:smtp.server.net:25
Alle Datenpakete die zum lokalen Port 10025 geschickt werden, werden über <latex inline>ssh</latex> (verschlüsselt) an <latex inline>rmt</latex> übertragen. Der rechner <latex inline>rmt</latex> schickt diese Pakete weiter zum Port 25 (SMTP Port) auf <latex inline>smtp.server.net</latex> .
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 arthur@rmt -L10025:smtp.server.net:25 -L10110:pop3.svr.net:110
Den Mail-Client muß man umkonfigurieren um die neuen Ports zu nutzen. Zum Mail senden muß <latex inline>SMTP-Server=localhost</latex> und <latex inline>Port=10025</latex> gesetzt werden.
Der Empfang funktioniert nachdem man <latex inline>POP3-Server=localhost</latex> und <latex inline>Port=10110</latex> konfiguriert hat. Danach funktioniert das Abrufen und senden der E-Mails verschlüsselt und wird nicht mehr durch Firewallregeln, die die Ports 25 und 110 filtern, blockiert.
Tunnelbauen mit <latex titlecmd>ssh</latex>: 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! <latex inline>ssh</latex> kann da auch helfen. Mit:
ssh -N -D 8080 arthur@rmt
verwandeln wir unsere <latex inline>ssh</latex>-Verbindung in ein SOCKS-Server. Der <latex inline>-N</latex> Schalter weist <latex inline>ssh</latex> 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 <latex titlecmd>ssh</latex>: 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 <latex inline>tsocks</latex> auf dem Rechner installiert ist. Wenn nicht: local installieren. Dann einen Tunnel mit <latex inline>ssh</latex> aufbauen, also <latex inline>ssh -N -D 8080 arthur@rmt</latex> ausführen. Danach ein Paar Zeilen in der shell ausführen:
TSOCKS_CONF_FILE=$HOME/.tsocks.conf export TSOCKS_CONF_FILE
In die Datei <latex inline>~/.tsocks.conf</latex> schreibt man :
server = 127.0.0.1 server_port = 8080
Wenn man jetzt ein Program aufruft das eine Verbindung zum Internet herstellen muß, dann muß man <latex inline>tsocks</latex> voranstellen:
tsocks wget -r -k -np de.wikipedia.org
Was jetzt passiert ist daß <latex inline>tsocks</latex> die <latex inline>connect</latex>-Funktion des Kernels durch seine eigene ersetzt, und dadurch alle Verbindungen (außer lokale Netzwerkverbindungen) auf <latex inline>127.0.0.1:8080</latex> umbiegt. Da hört ja unser <latex inline>ssh</latex>-Proxy der alles weiterleitet. Damit hat unser Program eine Verbindung zum Internet ohne was von einem Proxy oder von SOCKS zu wissen.
<latex titlecmd>ssh</latex> ohne port 22
Manchmal werden Firewalls so konfiguriert daß Verbindungen zu Port 22 (<latex inline>ssh</latex> Port) nicht zugelassen sind. In diesem Fall kann <latex inline>arthur</latex> von seinem Rechner aus nichts machen. Sobald er Zugang zu <latex inline>rmt</latex> hat, kann er den dort laufenden <latex inline>ssh</latex> 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.
- <latex inline>/etc/ssh/sshd_config</latex> ändern, als root auf <latex inline>rmt</latex>
- Zeile mit <latex inline>Port=22</latex> in der Datei finden, wenn nicht vorhanden einfügen.
- <latex inline>Port=443</latex> der Datei hinzufügen.
- <latex inline>sshd</latex> neu starten als root auf <latex inline>rmt</latex>
/etc/init.d/ssh restart
Um den gesperrten Port 22 nicht mehr benuten zu müssen kann <latex inline>arthur</latex> jetzt seinen <latex inline>ssh</latex> client anweisen einen anderen Port zu verwenden. Dies macht er indem er den <latex inline>-p</latex> Schalter verwendet.
ssh -p 443 arthur@rmt -D 8080
Damit hat <latex inline>arthur</latex> jetzt einen SOCKS server auf <latex inline>rmt</latex> gestartet. Der Server nimmt alle Daten vom lokalen Port 8080 und leitet sie an <latex inline>rmt</latex> über den Port 443 (Kommunikation über <latex inline>ssh</latex> wie immer verschlüsselt) weiter.
Wenn ein Server im Internet steht, ist es immer von Vorteil den <latex inline>ssh</latex> 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 <latex inline>ssh</latex> Daemon mehr. Somit gehen diese automatischen Attacken daneben.
Tunnel kontrolliert dauerhaft offen halten
Ein sehr nützliches Tool beim Umgang mit Tunnels ist <latex inline>autossh</latex>. <latex inline>autossh</latex> dient dazu eine <latex inline>ssh</latex> 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 <latex inline>SMTP</latex> und die <latex inline>POP3</latex> Verbindung vom vorhergehenden Beispiel dauerhaft aufrecht erhalten
autossh -M 20000 arthur@rmt -L10025:smtp.server.net:25 -L10110:pop3.svr.net:110
<latex inline>autossh</latex> benötigt nur die Angabe eines Management-Ports mit <latex inline>-M</latex>. Der Port kann frei zwischen 1025-65535 gewählt werden. Danach hängt man einfach den gesamten <latex inline>ssh</latex> Befehl an.
<latex titlecmd>ssh</latex> 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 <latex inline>sshd_config</latex> 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 root@rmt
Durch den Parameter <latex inline>-w any:any</latex> wird auf Server und Client das nächste freie <latex inline>tun</latex> Device initialisiert. Sind noch keine <latex inline>tun</latex> Devices vorhanden wird auf beiden Seiten das <latex inline>tun0</latex> angelegt. Dann muss man am Server und am Client jeweils das <latex inline>tun0</latex> konfigurieren.
Client:
ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2
Server:
ifconfig tun0 10.0.0.2 pointopoint 10.0.0.1
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