
Ich weiß, es gibt hier Dutzende von Fragen zuSo stellen Sie eine Verbindung zu einem SSH-Server her, ohne jedes Mal Ihr Kennwort einzugeben, und die Antwort lautet immer: „Verwenden Sie einen öffentlichen Schlüssel.“ Nun, ich befinde mich in der seltenen Situation, in der das wirklich keine Option ist. Aus irgendeinem unerklärlichen Grund ist der OpenSSH-Daemon auf dem Server, mit dem ich eine Verbindung herstellen möchte, mit
RSAAuthentication no
PubkeyAuthentication no
in /etc/ssh/sshd_config
. Ich habe keinen Administratorzugriff auf den Server und kann daher diese oder andere Serverkonfigurationsoptionen nicht ändern. (Ich habe natürlich die volle Kontrolle über die Clientkonfiguration: OpenSSH 5.8 unter Linux.)
Welche Optionen habe ich und welche ist insbesondere die sicherste Option, um nicht jedes Mal mein Passwort eingeben zu müssen, wenn ich mich per SSH mit diesem Server verbinden möchte? Ich halte meine eigenen Computer relativ gut geschützt, also gehen wir davon aus, dass die Sicherheitsrisiken, die mit der Speicherung des Passworts in einer Datei auf dem Client verbunden sind, akzeptabel gering sind, falls dies tatsächlich notwendig ist.
Die anderen Authentifizierungsmethoden, die der Server akzeptieren kann, sind offensichtlich GSS API (von dem ich nichts weiß), Keyboard Interactive (von dem ich auch nichts weiß) und Passwort. Hier sind einige relevante Konfigurationsoptionen:
#ChallengeResponseAuthentication yes
#KerberosAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
#UsePAM no
und hier ist eine Debug- -vv
Verfolgung ():
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
Antwort1
In diesem Fall wäre das Schreiben (oder besser Aufzeichnen) eines Expect-Skripts eine Ihrer Optionen.
Da jedes System anders ist, gibt es kein Skript. Mit Autoexpect ist es jedoch sehr einfach, zu diesem Zweck ein Skript aufzuzeichnen.
Antwort2
Den bisher gesammelten Informationen zufolge sftp.pass.psu.edu
unterstützt der Server die Kerberos 5-Authentifizierung (GSSAPI) und befindet sich im dce.psu.edu
Realm.
Kerberos istsehrHäufig in Netzwerken mit vielen Servern und Workstations; viele große Bildungseinrichtungen haben es eingerichtet. Einer der Vorteile gegenüber der Authentifizierung mit öffentlichem Schlüssel besteht darin, dass ein einziger Rechner kinit
automatisch Anmeldeinformationen für alle Rechner im Kerberos-Bereich bereitstellt, ohne dass die öffentlichen Schlüssel auf jeden Rechner kopiert werden müssen. Ein weiterer Vorteil ist die Protokollunterstützung – dieselben Kerberos-Anmeldeinformationen können für über 30 Protokolle (Mail, Dateisysteme, Datenbanken usw.) verwendet werden, nicht nur für SSH.
(Bezüglich „ahnungsloser Windows-Administratoren“: Der dce.psu.edu
Bereich scheint tatsächlich auf Active Directory zu basieren und von Windows-Servern gehostet zu werden.)
Versuchen Sie, die folgenden Schritte auszuführen:
Melden Sie sich bei Kerberos an. (Die
kinit
Toolsklist
befinden sich möglicherweise in „krb5-user“ oder einem ähnlichen Paket, sofern sie nicht bereits im System enthalten sind.)kinitdein Benutzername@dce.psu.edu
Wenn keine Fehler angezeigt werden, war die Anmeldung erfolgreich.
klist
Es sollte ein "krbtgt/dce.psu.edu@...
"-Element angezeigt werden.Stellen Sie jetzt mit den Optionen eine Verbindung zum SSH-Server her
-vv
. Wenn die Authentifizierung erfolgreich ist, ist alles gut.Wenn dies nicht der Fall ist, müssen Sie möglicherweise Ihre
/etc/krb5.conf
Datei bearbeiten. Fügen Sie unter dem[domain_realm]
Abschnitt Folgendes hinzu:[domain_realm] .psu.edu = dce.psu.edu
Mit den Standardeinstellungen von Krb5 sollte das in #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 Kennwort in einer Datei speichern möchten,
kinit your_principal < password.txt
sollte eine einfache Methode funktionieren, die jedoch nicht völlig zuverlässig ist.Mit
ktutil
ist es möglich, eine"Tastenkombination"zur Verwendung anstelle des Passwortes.$ ktutil ktutil: Addent -Passwort -pIhr Auftraggeber-k 1 -e aes256-cts-hmac-sha1-96 Passwort fürIhr Auftraggeber: ********* ktutil: wktKeytab-Datei ktutil: CtrlD
und melden Sie sich an mit:
$ kinit -ktKeytab-Datei Ihr Auftraggeber
Antwort3
Ich würde eine gemischte Lösung in Betracht ziehen, bei der Sie das Passwort nur einmal eingeben und der Computer einen Socket zum Remote-SSH-Server aufrechterhält. Sie können folgendiese StufenControlMaster
um es genau aus diesem Grund einzurichten .