Come posso configurare SSH in modo da non dover digitare una password e senza usare una chiave pubblica?

So che ci sono dozzine di domande qui su come connettersi a un server SSH senza digitare la password ogni volta e la risposta è sempre "utilizzare una chiave pubblica". Bene, mi trovo nella rara circostanza in cui questa non è davvero un'opzione. Per qualche motivo inspiegabile, il demone OpenSSH sul server a cui sto tentando di connettermi è configurato

RSAAuthentication no
PubkeyAuthentication no

in /etc/ssh/sshd_config. Non ho alcun accesso amministrativo sul server, quindi non posso modificare queste o altre opzioni di configurazione del server. (Ovviamente, ho il pieno controllo della configurazione del client: OpenSSH 5.8 su Linux.)

Quali sono le mie opzioni, e in particolare qual è l'opzione più sicura, per evitare di dover digitare la mia password ogni volta che voglio SSH in questo server? Mantengo i miei computer abbastanza ben protetti, quindi supponiamo che i rischi di sicurezza legati alla memorizzazione della password in un file sul client siano accettabilmente bassi, se ciò è effettivamente necessario.

Gli altri metodi di autenticazione che il server può accettare sono evidentemente API GSS (di cui non so nulla), tastiera interattiva (di cui non so nulla) e password. Ecco alcune opzioni di configurazione rilevanti:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

ed ecco una -vvtraccia di debug ( ):

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 questo caso, scrivere (o meglio registrare) uno script prevede sarebbe una delle tue opzioni.

Ogni sistema è diverso, quindi non ci sarà uno script, ma con Autoexpect è molto semplice registrare uno script per questo scopo.

Dalle informazioni raccolte finora, il server sftp.pass.psu.edusupporta l'autenticazione Kerberos 5 (GSSAPI) ed è nel dce.psu.eduregno.

Kerberos è molto comune su reti con molti server e workstation; molte grandi istituzioni educative lo hanno istituito. Uno se i suoi vantaggi rispetto all'autenticazione con chiave pubblica è che un singolo kinitfornisce automaticamente le credenziali a tutte le macchine nel regno Kerberos, senza dover copiare le chiavi pubbliche su ciascuna. Un altro è il supporto del protocollo: le stesse credenziali Kerberos possono essere utilizzate con oltre 30 protocolli (posta, file system, database ...), non solo SSH.

^{(Riguardo agli "amministratori solo per Windows": il dce.psu.eduregno sembra in realtà essere basato su Active Directory e ospitato da server Windows.)}

Prova a seguire questi passaggi:

1. Accedi a Kerberos. (Gli strumenti kinite klistpossono essere in "krb5-user" o pacchetto simile, se non sono già inclusi nel sistema.)

   kinit nome_utente @ dce.psu.edu
   

   Se non vengono visualizzati errori, l'accesso ha avuto esito positivo. klistdovrebbe mostrare un " krbtgt/dce.psu.edu@..." oggetto.

2. Ora connettiti al server SSH, con le -vvopzioni; se l'autenticazione riesce, bene.

   In caso contrario, potrebbe essere necessario modificare il /etc/krb5.conffile. Nella [domain_realm]sezione, aggiungi quanto segue:

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

3. Con le impostazioni predefinite di Krb5, il biglietto ottenuto nel numero 1 dovrebbe essere valido per 10 ore e rinnovabile fino a una settimana. Non ho modo di verificare le impostazioni, tuttavia.

   Se vuoi mantenere la password in un file, un semplice kinit your_principal < password.txtdovrebbe funzionare, anche se non è completamente affidabile.

   Con ktutilè possibile creare un "keytab" da utilizzare al posto della password.

   $ ktutil
   ktutil: addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96
   Password per your_principal : *********
   ktutil: wkt keytab_file 
   ktutil:  CtrlD
   

   e accedi usando:

   $ kinit -kt keytab_file  your_principal
   

Vorrei prendere in considerazione una soluzione mista, in cui si immette la password una sola volta e il computer mantiene un socket al server SSH remoto. È possibile seguire questi passaggi per configurare ControlMasterproprio per questo motivo.