ssh client mini-howto

Annahmen und Ziel

Ich gehe davon aus, daß der Benutzer unter X11 arbeitet und den xdm zum login verwendet (das ganze funktioniert aber sinngemäß auch mit einer normalen Shell). Bei anderen Szenarien bleibt das Prozedere im Prinzip gleich, es ändern sich allerdings eventuell einige Filenamen.

Weiters gehe ich davon aus, daß root auf dem Client-Rechner eine vertrauenswürdige Person ist. Dies ist eine wichtige Einschränkung. Root auf dem Client-Rechner hat Zugriff auf den laufenden Ssh-Agent und damit auf alle Accounts des Benutzers auf anderen Rechnern! (Der Verzicht auf den sshd hilft allerdings nur begrenzt: Root könnte auch den SSH-Client durch ein trojanisches Pferd ersetzen, das Passwörter bzw. Passphrases mitschreibt).

Ziel soll sein, daß man nach dem Login nur einmal die Passphrase eingeben muß, und sich danach auf allen Rechnern, auf denen man einen Account hat, ohne weitere Angabe eines Passwortes oder einer Passphrase einloggen kann.

SSH Installieren

Als root: Je nach persönlicher Paranoia entweder ein vorgefertigtes RPM (oder .deb oder was auch immmer die bevorzugte Distribution verwendet) installieren oder Sourcen von der OpenSSH Homepage holen und selber compilieren. In letzterem Fall sollte man auch mittels

ssh-keygen -f /etc/ssh_host_key -P ""

einen Host-Key generieren. Bei Packages passiert dies (hoffentlich) beim Installieren automatisch.

Vorbereitung am Arbeitsplatzrechner

Diese Arbeiten muß jeder User machen

1. Mittels

   ssh-keygen [-t type]
   

   wird ein Private/Public-Keypaar erzeugt und in ~/.ssh/filename bzw. ~/.ssh/filename.pub abgelegt. Der Filename hängt vom Typ ab. Wird kein Typ angegeben, so wird ein SSH1-RSA-Key erzeugt und in "identity" abgelegt. Die Typen "rsa" und "dsa" sind für SSH2, das File heißt in dem Fall "id_type". Achtung: Nicht alle Server verstehen alle Algorithmen: SSH-1.x-Server verstehen nur SSH1-RSA, SSH-2.x (dazu zählt auch OpenSSH) nur die SSH-2-Typen wobei manche Versionen (z.B. die auf den LUGA-Servern installierte) nur DSA können, aber nicht RSA. Im Zweifelsfall erzeugt man am besten alle drei Keys mit der gleichen Passphrase und überläßt SSH die Auswahl.

   Die Passphrase kann und sollte länger sein als 8 Zeichen aber kurz genug, daß man sie blind tippen kann. Es gelten die üblichen Regeln für gute Passwörter (leicht zu merken aber schwer zu erraten, also keine ganzen Wörter, Telefonnummern, etc.). Die Passphrase wird verwendet, um den Private Key zu ver- und entschlüsseln, man braucht also sowohl das File ~/.ssh/identity (bzw. ~/.ssh/id_type) als auch die Passphrase, um sich zu identifizieren.

2. Nun kann man sich statt mit seinem Passwort mit seiner Passphrase identifizieren, hat damit aber noch nicht viel gewonnen. Um die Passphrase während einer Session nur einmal einmal eingeben zu müssen, gibt es den ssh-agent , ein kleines Programm, das sich Private Keys merkt und bei Bedarf an die ssh abgibt.

   Dieses starten wir ganz am Anfang des ~/.xsession Files (auf manchen System auch ~/.Xclients ) indem wir die Zeilen

   eval `/usr/local/bin/ssh-agent`
   /usr/local/bin/ssh-add 
   

   einfügen. ssh-agent gibt beim Starten die Werte zweier Environmentvariablen auf stdout aus. Damit diese in der Shell gesetzt werden, muß dieser Output von der Shell evaluiert werden. Das ssh-add Programm öffnet ein kleines Fenster und fragt nach der Passphrase, entschlüsselt ~/.ssh/identity und teilt dem ssh-agent den private Key mit.

   Ganz am Ende des ~/.xsession kann man dann noch ein

   kill $SSH_AGENT_PID
   

   einfügen, um den ssh-agent beim Logout wieder zu killen. Das funktioniert natürlich nur, wenn der Window-Manager nicht mittels exec gestartet wird.

   Sinngemäß kann man das gleiche auch im mit einem Shell-Login statt einem graphischen Login machen. Ich starte z.B. in meinem .zprofile den ssh-agent (aber nur wenn die Environment-Variable SSH_AUTH_SOCK nicht gesetzt ist und eines der Private Key Files existiert) und kille ihn im .zlogout wieder (ich verwende die zsh). Ob das sehr sinnvoll ist, bin ich mir aber nicht sicher.

3. Weiters empfiehlt sich, AgentForwarding zu aktivieren, damit vom Zielrechner aus auch ohne Passwort auf andere Rechner kommt. Wenn dies nicht schon der Fall ist, trägt man im ~/.ssh/config die Zeile

   ForwardAgent yes
   

   (am besten in einer Host-Section, damit nur vertrauenswürdige Hosts Zugang zum Agent bekommen).
4. Hat man am Zielrechner einen anderen Usernamen als am Client, kann man diesen ebenfalls in einer Host-Section im ~/.ssh/config eintragen, z.B.:

   Host server.at
     User dau4711
   

Vorbereitung auf den Zielrechnern

Alles was nun noch zu tun bleibt, ist den Zielrechnern, den eigenen Public Key mitzuteilen, damit man sich mit dem Private-Key authentifizieren kann. Dazu kopiert man mittels

scp ~/.ssh/id*.pub server.at:

die Public Keys in sein Homedirectory am Rechner server.at (man beachte den Doppelpunkt). Anschließend loggt man sich mit ssh server.at auf diesem ein und hängt die Public Keys an das File ~/.ssh/authorized_keys (für SSH1) bzw. ~/.ssh/authorized_keys2 (für SSH2) an:

umask 077
mkdir ~/.ssh
cat ~/identity.pub >> ~/.ssh/authorized_keys
rm ~/identity.pub
cat ~/id_*.pub >> ~/.ssh/authorized_keys2
rm ~/id_*.pub

Geschafft

Beim nächsten Login unter X11 sollte am Anfang ein kleines Fenster mit der Aufforderung

Enter Passphrase for user@localhost

aufgehen. Anschließend wird dann wie üblich der Windowmanager gestartet, und man kann von einem xterm aus mittels

ssh server.at

ohne weitere Angabe einer Passphrase am Server einloggen.

Weitere Informationen

• Secure Shell auf Wikipedia.
• SSH Introduction and Resources bei WhoIsHostingThis.