Schlagwort-Archive: ssh

SSH trouble

Schlichte Meldung meines Clients beim ersten Anmeldeversuch:

Received disconnect from host ... Too many authentication failures for ...

Mein erster Versuch war in .ssh/config mit einer Veränderung ServerAliveInterval und ServerAliveCountMax zum Erfolg zu kommen, aber als es mit

ServerAliveInterval 30
ServerAliveCountMax 10

immer noch nicht klappen wollte, war auch mir klar, dass die Ursache an einer anderen Stelle zu suchen sein muss. Schließlich kam die Verbindung überhaupt nicht zustande. An den Alive-Werten zu spielen macht demnach keinen Sinn.

Die Ursache für das Verbindungsproblem ist, dass ssh zuerst jeden DSA/RSA identity file in .ssh/ durchprobiert, bevor es am Ende auf den default password authentication zurückfällt.

Wenn jedoch auf Serverseite der SSHD nach 5 Verbindungsversuchen (das scheint der default unter Ubuntu zu sein) dicht macht, lokal aber mehr als 5 ID Dateien vorhanden sind … läuft man vor die Wand. Die Lösung ist einfach: Man teilt SSH mit, dass man ohne ID Datei verbinden will:

ssh -o PubkeyAuthentication=no user@host

und dann klappt es.

Passwortänderung, PuTTY und Kollegen

Damit meine Kollegen ihre Passwörter auf dem schulischen Mailserver selbst ändern können will ich diesen keine Möglichkeit direkt über Horde5 zur Verfügung stellen. Im Kontext von Heartbleed wurde mir klar, dass Aufrufe zur Passwortänderung nämlich von Lehrer/innen schlicht ignoriert werden oder Passwörter gewählt werden, die diesen Namen nicht verdienen.

Ich habe nun vor, die Passwortverwaltung einerseits selbst in der Hand zu halten, so weit es eben geht, und andererseits aber auch nicht zu sehr zu gängeln.

Es wird deswegen die Möglichkeit geben, sich über SSH mit einem Passwort-geschützten Schlüssel am Mailserver anzumelden und dort passwd zu nutzen, das wiederum ein paar Prüfroutinen auf die Eingaben loslässt. Restricted Shell sollte genug Sicherheit bieten. So richtig böse ist keiner und wenn doch, dann ist der Mailserver eben weg.

Will also ein Lehrer sein Passwort selbst verwalten, dann erhält er von mir in einer verschlüsselten Mail einen TrueCrypt Container und das zugehörige Passwort. im Container befinden sich PuTTYPortable.exe, puttygen.exe und seine private Schlüsseldatei im SSH Format. Weiter kommt noch eine Anleitung mit dazu – denn: Die Ersteinrichtung von PuTTY überlasse ich ebenfalls dem Benutzer.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Mit puttygen muss man zuerst den SSH Key über /Conversions /Import key importieren und dann den privaten Schlüssel im PPK Format wieder abspeichern. Beim Import fragt puttygen nach dem Passwort für den Schlüssel.

http://portableapps.com/apps/internet/putty_portable

In PuTTYPortable sind dann die folgenden Einstellungen vorzunehmen:

  • unter /Session sind der Server und der Port einzustellen
  • unter /Connection /Data /Auto-login-username ist der Benutzername einzutragen
  • unter /Connection /SSH /Auth wird über den Schalter /Browse die vorher erstellte PPK Datei mit dem privaten Schlüssel ausgewählt

Ist PuTTY erst einmal zufrieden gestellt, dann speichert man die ganze Geschichte unter /Session ab, so dass man sich dieses Gefrickel in Zukunft sparen kann.

Pam_unix prüft bei entsprechender Konfiguration und in Zusammenarbeit mit pam_cracklib einiges ab, was zu simple Einfälle unmöglich macht. Da muss ich aufpassen, dass ich nicht übertreibe.

Da an keiner Stelle im Prozess der Passwortänderung auch nur Sternchen angezeigt werden, sind die Fehlerquellen sicherlich Legion. Dazu kommt, dass ein solches Verfahren die meisten schlicht abschrecken wird. Schwarze Felder mit blinkenden grünem Strichlein sind die wenigsten gewohnt.

Das ist dann eben so. Ein Kollateralschaden.

VirtualBox, rdesktop und ssh Tunnel

sshtunnel_rdesktop

Folgendes Setup: In der Schule steht ein VMHost auf dem einige VMs mit Hilfe von VirtualBox virtualisiert wurden. Der VMHost ist von Außen nur über SSH und dort nur über Port 2233 zu erreichen.

Säße man direkt am VMHost würde man die rdesktop-Sitzung mit dem folgenden Befehl aufrufen:

rdesktop localhost:3389

Diese Sitzung will man nun auf dem Laptop zu Hause haben. Also braucht man einen SSH Tunnel in die Schule, über den man sich die rdesktop Sitzung nach Hause holt.

Ein derartiger Aufbau des SSH Tunnels erfolgt wie hier angegeben, wenn man auch lokal die rdesktop Session auf Port 3389 sehen will:

ssh -p 2233 benutzer@vmhost.schule.tld -L 3389:localhost:3389

Lokal macht man dann (in einem zweiten Terminal) die rdesktop Session auf, wie wenn man direkt am VMHost sitzen würde: rdesktop localhost:3389

SSH absichern

Mein root Server bei Hetzner nutzt schon lange das publickey-Verfahren, um sich gegen Attacken gegen Port 22 und damit SSH zu schützen. Dafür hat Frank gesorgt. Meine Server in der Schule nun endlich auch … und damit bestand das Problem, dass ich nicht den gleichen Key für zwei Server nutzen wollte bzw die Neuerstellung eines weiteren Keys den Inhalt der id_dsa Datei im .ssh Verzeichnis überschreibt und ich so meinen alten Key verloren hätte. Wer zwei oder mehr getrennte Keys wünscht, muss also Pfade zu denselben angeben.

Während der gesamten folgenden Schritte immer eine root-shell auf dem Server offen haben, damit man sich die alten Einstellungen im Notfall zurück holen kann, sollte man sich aussperren.

Zur Vorbereitung die /etc/ssh/sshd_config an einen sicheren Ort wegkopieren und dann anpassen – und zwar die folgenden Zeilen in derselben, sofern man unter einem Debian / einer SuSE mit installiertem sudo bzw. Ubuntu arbeitet:

Port 222222
PermitRootLogin no
X11Forwarding no
PrintMotd no
ChallangeResponseAuthentication no
PasswordAuthentication no

Port 22222 ist evtl. etwas übertrieben – aber Paranoia schadet ja nicht.

Auf dem Client dann den Key erstellen und die Rückfrage nach einem Passwort für den Key mit einer entsprechend komplizierten und langen Passphrase beantworten:

ssh-keygen -f /home/benutzer/.ssh/benutzer-servername

Der öffentliche Teil muss dann mit Hilfe von scp auf den Server transferiert werden:

scp /home/benutzer/.ssh/benutzer-servername.pub benutzer@servername.domain:/home/benutzer

Dort den öffentlichen Schlüssel in den Schlüsselbund kopieren:

cat benutzer-servername.pub >> /home/benutzer/.ssh/authorized_keys

Ein

/etc/init.d/ssh restart

schaltet die Änderungen scharf.

Jetzt die Verbindung vom Client aus testen:

ssh benutzer@servername.domain -p 22222 -i /home/benutzer/.ssh/benutzer-servername

Wenn alles klappt, man also nach der Passphrase für den Key und nicht mehr nach einem Serverkennwort gefragt wird, sich also anmelden und mit Hilfe von sudo auch root werden kann, ist alles gut. Wenn nicht, dann zuerst die Rechte der eben angelegten Dateien und Verzeichnisse kontrollieren.

rsync über ssh mit Hop

Einer meiner Laptops steht in der Schule – also hinter einer Firewall und nur über seine schulinterne IP erreichbar. Angenehm ist, wenn der Datenbestand auf dieser Maschine dem Datenbestand auf meinem heimischen Arbeitsplatzrechner entspricht. Bisher trug ich den Schullaptop deswegen immer in den Ferien mit nach Hause, synchronisierte diesen im heimischen Netz und nahm diesen dann am ersten Schultag wieder mit zum Arbeitsplatz. Der Datenbestand hinkte demnach etwas hinterher.

Für eine Erstsynchronisation ist dieses Vorgehen immer noch ratsam. Aber jetzt aktualisiere ich öfter – mit Hilfe von rsync über ssh und einem Hop über einen anderen Rechner im Schulnetz, der – so zu sagen – „in der Mitte“ steht, von Außen erreichbar ist und immer am Netz hängt. Ich nenne diese Maschine hier „rechnermitte“.

Die Maschine rechnermitte ist nicht über den Standard SSH Port 22, sondern (sagen wir mal) über Port 2244 zu erreichen. Der SSH Server auf dem Schullaptop jedoch hört auf Port 22.

Hinweis: Damit keiner Blödsinn mit meinem Schullaptop macht, ist der Login über SSH nur für einen bestimmten User (hier: schullaptopnutzer) erlaubt und außerdem hab ich auf diesem als zusätzliche Hürde fail2ban installiert.

Zuerst wird ein SSH-Tunnel zum Schullaptop geöffnet, und zwar so, dass dessen Port 22 über rechnermitte an den Port 2223 am Heimarbeitsplatz (localhost) gebunden wird:

ssh -L 2223:interne_ip_schullaptop:22 user_mitte@rechnermitte.schuldomain.de -p 2244

Der Aufruf verlangt nach dem Passwort für user_mitte auf rechnermitte.

Steht diese Verbindung, kann ich meinen Schullaptop vom heimischen Rechner aus schon wie folgt über SSH erreichen:

ssh schullaptopnutzer@localhost -p 2223

Es folgt der Aufruf von rsync auf dem heimischen Rechner, mit dem Ziel, die zu Hause geänderten Daten auf den Schulrechner zu übertragen (umgekehrt geht das auch – aber das ist nicht Teil dieser Beschreibung):

rsync -r -t -p -x -v –progress –delete -z /home/heimrechnernutzer/Dokumente/Schule/ –rsh=’ssh -p2223′ schullaptopnutzer@localhost:/home/schullaptopnutzer/Dokumente/schule

Selbstverständlich dauert eine derartige Synchronisation über das Internet wesentlich länger – ich hab hier nur „Bauern-DSL“ und entsprechend niedrige Upload-Raten. Aber es klappt trotz aller Einschränkungen erstaunlich flott – die Zeit für das Abendessen reicht fast immer.

Nach einer erfolgreichen Synchronisation kann ich den Schullaptop dann von zu Hause aus herunterfahren.

Vereinfachend für mich ist, dass ich auf dem Schullaptop nur selten viele Dateien überarbeite: Die Maschine dient im Wesentlichen als Präsentationsrechner. Wenn doch umfangreichere Änderungen vorgenommen werden, dann schick ich mir diese meist per Mail oder werf sie nach Dropbox, so dass ich extrem selten einen rsync vom Laptop in Richtung Heimrechner benötige. Sollte dies sich ändern, dann käme evtl. noch unison ins Spiel und würde weitere Vereinfachungen ermöglichen: http://wiki.ubuntuusers.de/Unison

Eine gute Sammlung verschiedener Methoden für rsync über ssh liefert die folgenden Website inklusive Sicherheitshinweise: http://samba.anu.edu.au/rsync/firewall.html