Wie richte ich SSH ein, damit ich kein Passwort eingeben muss und keinen öffentlichen Schlüssel verwenden muss?

Ich weiß, dass es hier Dutzende von Fragen gibt, wie man eine Verbindung zu einem SSH-Server herstellt, ohne jedes Mal Ihr Passwort einzugeben , und die Antwort lautet immer "Verwenden Sie einen öffentlichen Schlüssel". Nun, ich befinde mich in einem seltenen Fall, in dem das wirklich keine Option ist. Aus irgendeinem unerklärlichen Grund ist der OpenSSH-Dämon auf dem Server, mit dem ich eine Verbindung herstellen möchte, konfiguriert

RSAAuthentication no
PubkeyAuthentication no

in /etc/ssh/sshd_config. Ich habe keinen Administratorzugriff auf den Server, daher kann ich diese oder andere Serverkonfigurationsoptionen nicht ändern. (Ich habe natürlich die volle Kontrolle über die Client-Konfiguration: OpenSSH 5.8 unter Linux.)

Was sind meine Optionen und insbesondere die sicherste Option, um zu vermeiden, dass ich mein Kennwort jedes Mal eingeben muss, wenn ich SSH auf diesen Server übertragen möchte? Ich halte meine eigenen Computer ziemlich gut geschützt. Nehmen wir also an, dass die Sicherheitsrisiken beim Speichern des Kennworts in einer Datei auf dem Client akzeptabel gering sind, falls dies tatsächlich erforderlich ist.

Die anderen Authentifizierungsmethoden, die der Server akzeptieren kann, sind offensichtlich die GSS-API (von der ich nichts weiß), die interaktive Tastatur (von der ich auch nichts weiß) und das Kennwort. Hier sind einige relevante Konfigurationsoptionen:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

und hier ist eine debug ( -vv) - Ablaufverfolgung:

debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information

debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

In diesem Fall ist das Schreiben (oder bessere Aufzeichnen) eines Erwartungsskripts eine Ihrer Optionen.

Jedes System ist anders, so dass es kein Skript gibt, aber mit Autoexpect ist es sehr einfach, ein Skript für diesen Zweck aufzuzeichnen.

Nach den bisher gesammelten Informationen sftp.pass.psu.eduunterstützt der Server die Kerberos 5-Authentifizierung (GSSAPI) und befindet sich im dce.psu.eduBereich.

Kerberos ist in Netzwerken mit vielen Servern und Workstations sehr verbreitet. Viele große Bildungseinrichtungen haben es eingerichtet. Einer der Vorteile gegenüber der Authentifizierung mit öffentlichem Schlüssel besteht darin, dass ein einzelner kinitComputer automatisch Anmeldeinformationen für alle Computer im Kerberos-Bereich bereitstellt, ohne die öffentlichen Schlüssel auf jeden Computer kopieren zu müssen. Ein weiterer Grund ist die Protokollunterstützung. Dieselben Kerberos-Anmeldeinformationen können mit über 30 Protokollen (E-Mail, Dateisysteme, Datenbanken ...) verwendet werden, nicht nur mit SSH.

^{(In Bezug auf "ahnungslose Windows-Administratoren": Der dce.psu.eduBereich scheint tatsächlich auf Active Directory zu basieren und von Windows-Servern gehostet zu werden.)}

Führen Sie die folgenden Schritte aus:

1. Melden Sie sich bei Kerberos an. (Die Tools kinitund klistkönnen sich in "krb5-user" oder einem ähnlichen Paket befinden, sofern sie nicht bereits im System enthalten sind.)

   kinit your_username @ dce.psu.edu
   

   Wenn keine Fehler angezeigt werden, war die Anmeldung erfolgreich. klistsollte ein " krbtgt/dce.psu.edu@..." Element anzeigen.

2. Stellen Sie nun mit den -vvOptionen eine Verbindung zum SSH-Server her . Wenn die Authentifizierung erfolgreich ist, gut.

   Wenn dies nicht der Fall ist, müssen Sie möglicherweise Ihre /etc/krb5.confDatei bearbeiten . Fügen Sie unter dem [domain_realm]Abschnitt Folgendes hinzu:

   [domain_realm]
       .psu.edu = dce.psu.edu
   

3. Mit den Standardeinstellungen für Krb5 sollte das in Nummer 1 erhaltene Ticket 10 Stunden gültig und bis zu einer Woche verlängerbar sein. Ich habe jedoch keine Möglichkeit, die Einstellungen zu überprüfen.

   Wenn Sie das Passwort in einer Datei behalten möchten, sollte ein einfaches kinit your_principal < password.txtfunktionieren, obwohl es nicht vollständig zuverlässig ist.

   Mit ist ktutiles möglich, anstelle des Passworts ein "Keytab" zur Verwendung zu erstellen .

   $ ktutil
   ktutil: addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96
   Passwort für your_principal : *********
   ktutil: wkt keytab_file 
   ktutil:  CtrlD
   

   und melden Sie sich an mit:

   $ kinit -kt keytab_file  your_principal
   

Ich würde eine gemischte Lösung in Betracht ziehen, bei der Sie das Kennwort nur einmal eingeben und der Computer einen Socket zum Remote-SSH-Server verwaltet. Sie können diese Schritte ausführen, um das ControlMasteraus genau diesem Grund einzurichten.