Comment configurer SSH pour ne pas avoir à taper de mot de passe et sans utiliser de clé publique?

Je sais qu'il y a des dizaines de questions ici sur la façon de se connecter à un serveur SSH sans taper votre mot de passe à chaque fois , et la réponse est toujours «utilisez une clé publique». Eh bien, je me retrouve dans la rare circonstance où ce n'est vraiment pas une option. Pour une raison inexplicable, le démon OpenSSH sur le serveur auquel j'essaie de me connecter est configuré avec

RSAAuthentication no
PubkeyAuthentication no

dans /etc/ssh/sshd_config. Je n'ai aucun accès administratif sur le serveur, je ne peux donc pas modifier ces options ni aucune autre option de configuration du serveur. (J'ai, bien sûr, un contrôle total sur la configuration du client: OpenSSH 5.8 sous Linux.)

Quelles sont mes options, et en particulier, quelle est l'option la plus sûre, pour éviter d'avoir à taper mon mot de passe chaque fois que je veux SSH sur ce serveur? Je garde mes propres ordinateurs assez bien sécurisés, supposons donc que les risques de sécurité liés au stockage du mot de passe dans un fichier sur le client sont suffisamment faibles, si cela est effectivement nécessaire.

Les autres méthodes d'authentification que le serveur peut accepter sont évidemment l'API GSS (dont je ne sais rien), le clavier interactif (dont je ne sais rien non plus) et le mot de passe. Voici quelques options de configuration pertinentes:

#ChallengeResponseAuthentication yes

#KerberosAuthentication no

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

#UsePAM no

et voici une -vvtrace 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

Dans ce cas, l'écriture (ou mieux l'enregistrement) d'un script attendu serait l'une de vos options.

Chaque système est différent donc il n'y aura pas de script, mais avec autoexpect, il est très facile d'enregistrer un script à cet effet.

D'après les informations recueillies jusqu'à présent, le serveur sftp.pass.psu.eduprend en charge l'authentification Kerberos 5 (GSSAPI) et se trouve sur le dce.psu.edudomaine.

Kerberos est très courant sur les réseaux avec de nombreux serveurs et postes de travail; de nombreux grands établissements d'enseignement l'ont créé. L'un de ses avantages par rapport à l'authentification par clé publique est qu'un seul kinitfournit automatiquement des informations d'identification à toutes les machines du domaine Kerberos, sans avoir à copier les clés publiques sur chacune. Un autre est la prise en charge des protocoles - les mêmes informations d'identification Kerberos peuvent être utilisées avec plus de 30 protocoles (courrier, systèmes de fichiers, bases de données ...), pas seulement SSH.

^{(Concernant les "administrateurs Windows uniquement": le dce.psu.edudomaine semble en fait être basé sur Active Directory et hébergé par des serveurs Windows.)}

Essayez de suivre ces étapes:

1. Connectez-vous à Kerberos. (Les outils kinitet klistpeuvent être dans "krb5-user" ou un package similaire, s'ils ne sont pas déjà inclus avec le système.)

   kinit your_username @ dce.psu.edu
   

   Si aucune erreur ne s'affiche, la connexion a réussi. klistdevrait afficher un krbtgt/dce.psu.edu@...élément " ".

2. Connectez-vous maintenant au serveur SSH, avec les -vvoptions; si l'authentification réussit, c'est bien.

   Si ce n'est pas le cas, vous devrez peut-être modifier votre /etc/krb5.conffichier. Sous la [domain_realm]section, ajoutez ce qui suit:

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

3. Avec les paramètres par défaut de Krb5, le ticket obtenu en # 1 devrait être valide pendant 10 heures et renouvelable jusqu'à une semaine. Je n'ai cependant aucun moyen de vérifier les paramètres.

   Si vous souhaitez conserver le mot de passe dans un fichier, un simple kinit your_principal < password.txtdevrait fonctionner, bien qu'il ne soit pas complètement fiable.

   Avec, ktutilil est possible de créer un "keytab" à utiliser à la place du mot de passe.

   $ ktutil
   ktutil: addent -password -p your_principal -k 1 -e aes256-cts-hmac-sha1-96
   Mot de passe pour votre_principal : *********
   ktutil: wkt keytab_file 
   ktutil:  CtrlD
   

   et connectez-vous en utilisant:

   $ kinit -kt keytab_file  votre_principal
   

Je considérerais une solution mixte, où vous entrez le mot de passe une seule fois, et l'ordinateur maintient un socket pour le serveur SSH distant. Vous pouvez suivre ces étapes pour configurer le ControlMasterpour cette raison.