Problemstellung:

UserA auf HostB will sich als UserC auf HostD einloggen, bzw. via scp Dateien übertragen und dabei soll nicht nach einem Passwort gefragt werden.

Voraussetzungen:

• Auf den Solaris Rechnern läuft ein ssh2-Daemon von http://www.ssh.com/
• Die ssh2-Kommandos stehen im Pfad, z.B über das ATIS-/sw-Verzeichnis

Vorgehensweise:

• Auf HostB erzeugt sich UserA ein Schlüssel-Paar. Wichtig ist hierbei die Option -P (Assume empty passphrase), sonst wird man nach einer Passphrase gefragt.
  
  #HostB#UserA> ssh-keygen -P
  oder wenn auf HostA OpenSSL installiert ist muss das pub Zertifikat umgewandelt werden, damit es von SSH2 verarbeitet werden kann:
  ssh-keygen -P test -t rsa
  ssh-keygen -x -f id_dsa > ssh2.dsa.pub



• Dies erzeugt die beiden Dateien
  ~/.ssh2/id_dsa_1024_a und
  ~/.ssh2/id_dsa_1024_a.pub
  In ihnen befindet sich der Private und der Public Key des eben erzeugten Schlüsselpaares.



• Diese werden erst mal umgenannt (damit man später andere Key-Paare erzeugen kann):
  
  #HostB#UserA> mv ~/.ssh2/id_dsa_1024_a ~/.ssh2/key_for_UserC_on_HostD
  #HostB#UserA> mv ~/.ssh2/id_dsa_1024_a.pub ~/.ssh2/key_for_UserC_on_HostD.pub
  
  
• Nun fügt man den Private Key seinem "Schüsselbund" hinzu, mit dem man sich bei diversen Rechnern identifizieren möchte hinzu. Dies regelt die Datei "identification"
  
  #HostB#UserA> echo "IdKey  key_for_UserC_on_HostD" >> ~/.ssh2/identification



• Als nächstes erfolgt der Transfer des eben erzeugten Public Keys auf den Zielrechner HostD. Entweder mit Copy&Paste mit der Maus oder per scp:
  
  #HostB#UserA> scp ~/.ssh2/key_for_UserC_on_HostD.pub UserC@HostD:.ssh2
  
  hierbei wird man (noch) nach dem Passwort gefragt.



• Nun loggt man sich (auch noch mit Passwort) als UserC auf HostD ein



• Man fügt den eben übertragenen Public Key der Autorisierungsdatei hinzu:
  
  #HostD#UserC> echo "Key  key_for_UserC_on_HostD.pub" >> ~/.ssh2/authorization
  


• Nun kann man sich von HostD wieder ausloggen und sich zum Test noch einmal als UserC auf HostD via ssh anmelden. Es sollte keine Passwortabfrage erscheinen.

Achtung:

Dadurch, dass keine Passphrase vereinbart wurde, ist der Account von UserC auf HostD dann gehackt, wenn der UserA auf HostB gehackt wurde.
Der "Schutz" besteht in den UNIX-Filepermissions der Datei mit dem Private Key ~/.ssh2/key_for_UserC_on_HostD auf HostB. Diese sind entsprechend zu setzen.
Ebenso hat UserC seine Datei ~/.ssh2/authorization zu schützen.

Bei Verwendung von NFS

Wenn UserA und UserC gleich sind und die Heimatverzeichnisse (via NFS) identisch ist, vereinfacht sich die Vorgehensweise wie folgt:

• ssh-keygen -P und umbenenen wie oben
• Hinzufügen zum Schlüsselbund wie oben
  
  echo "IdKey  key_for_UserC_on_HostD" >> ~/.ssh2/identification
  
  
• Transfer des Public Keys ist nicht notwendig da ~/.ssh ja identisch
• Hinzufügen zur Autorisierungsdatei (auf Ursprungsrechner)
  
  echo "Key  key_for_UserC_on_HostD.pub" >> ~/.ssh2/authorization