Arrêter le client ssh d'offrir toutes les clés publiques qu'il peut trouver?


32

Comme la plupart des administrateurs système, j'utilise openssh tout le temps. J'ai environ une douzaine de clés ssh, j'aime avoir une clé ssh différente pour chaque hôte. Cependant, cela pose problème lorsque je me connecte à un hôte pour la première fois et que je n'ai qu'un mot de passe. Je veux juste me connecter à l'hôte en utilisant un mot de passe, pas de clé ssh dans ce cas. Cependant, le client ssh offrira toutes les clés publiques de mon ~/.ssh/(je le sais en regardant la sortie de ssh -v). Étant donné que j'en ai tellement, je serai déconnecté pour trop d'échecs d'authentification.

Existe-t-il un moyen de dire à mon client ssh de ne pas offrir toutes les clés ssh?


2
Pourquoi voudriez-vous une clé différente pour chaque hôte? Les clés peuvent également être partagées entre les hôtes au sein d'un même domaine administratif. De toute évidence, vous utiliseriez une clé pour vos machines de travail et une autre pour vos machines privées, mais quelle est la logique derrière l'utilisation d'une clé distincte pour chaque machine au travail?
Alex Holst

@AlexHolst J'utilise plusieurs clés. J'ai un cryptage par défaut (qui nécessite que j'entre un mot de passe) pour l'infrastructure interne. J'en ai un autre non crypté (sans mot de passe) que j'utilise pour un service spécifique où je ne pouvais pas utiliser d'agent ni vouloir taper à chaque minute le mot de passe. J'en ai d'autres pour les connexions qui ne font pas partie de notre infrastructure interne. C'est une bonne pratique, car même s'il devrait être assez difficile pour quelqu'un de récupérer la clé privée à partir de la clé publique, cela peut être fait. par exemple le bug Debian openssh il y a quelques années ...
Huygens

@Huygens J'adorerais voir votre document d'analyse des risques qui a abouti à la conclusion que vous devez utiliser plusieurs clés SSH, mais avoir des clés en texte clair est très bien. Pouvez-vous poster un lien?
Alex Holst

@AlexHolst, vous n'êtes pas obligé d'être aussi "direct". Tout d'abord, ma réponse portait sur les raisons d'avoir plusieurs paires de clés. Je pense que je vous en ai donné plusieurs. Après, nous devons tous faire face aux caprices et à quoi d'autre. J'ai un système de test pour lequel je ne peux pas utiliser une application qui tunnelise des données via SSH sans être invité en continu pour le mot de passe clé rendant le logiciel inutilisable. Il semble que ce soit un bug dû à l'incompatibilité des versions ou autre. Je reçois une notification par e-mail pour toute connexion SSH, et je suis le seul à me connecter à cette boîte. Le risque est donc acceptable.
Huygens

Réponses:


31

Il s'agit d'un comportement attendu selon la page de manuel de ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Fondamentalement, la spécification de IdentityFiles ajoute simplement des clés à une liste actuelle de l'agent SSH déjà présenté au client.

Essayez de remplacer ce comportement avec ceci au bas de votre .ssh/configfichier:

Host *
  IdentitiesOnly yes

Vous pouvez également remplacer ce paramètre au niveau de l'hôte, par exemple:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

4
Vous pouvez également utiliser ssh -o "IdentitiesOnly true" -v -A user@hostce que j'utilise pour me connecter à une machine qui n'a aucune de mes clés, mais je veux proposer le transfert d'agent pour continuer. ( -vpour le débogage détaillé).
vérifie

1
@eckes c'est un bon conseil, mais ne devrait-il pas l'être yes(et non true)?
aexl

IdentitiesOnlypeut ne pas toujours aider, vous devrez peut-être exclure un hôte spécifiquement; voir superuser.com/questions/859661/…
aexl

38

Bien que d'autres aient fait allusion à cela avec des solutions basées sur la configuration, il convient probablement de souligner que vous pouvez facilement le faire une seule fois sur la ligne de commande avec:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

3
Parfait .. LA solution à
mon humble avis

1
Corriger cela aurait dû être la réponse acceptée.
JM Becker

11

Suite à la solution de James Sneeringer, vous voudrez peut-être simplement définir un ssh_config dans le sens de:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Si vous vous connectez avec une clé particulière à de nombreuses machines n'appartenant pas à un domaine commun, pensez à leur attribuer tous les CNAME de votre propre DNS. Je le fais avec tous les systèmes clients.


2

Semblable à la solution de user23413, vous pouvez désactiver complètement l'authentification par clé publique pour un hôte particulier (ou modèle générique):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

-1

Si vous pointez sur un fichier de clé particulier avec ssh -i / chemin / vers / clé, il ne l'utilisera que si d'autres sont chargés dans l'agent, et vous ne serez pas invité à entrer le mot de passe. Vous pouvez également modifier votre ~ / .ssh / config et publier quelque chose comme ça ...

Hôte foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

vous pouvez aussi faire ...

Hôte * .example.org
IdentityFile .ssh / id_rsa_example.org


Cela ajoute simplement à la clé cible à la fin de la liste, ce qui ne résoudra pas le problème. IdentitiesOnlyseulement avec cette volonté.
Jo Rhett
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.