ssh n'utilise plus ~ / .ssh / config

Je ne peux rien faire de ce que j'ai pu. Après avoir creusé un peu, j'ai découvert qu'il ne lisait pas la configuration ssh de mon répertoire personnel.

$ ssh -xvvv server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
(...)

Lorsque sur un ordinateur identique d'un ami, où tout fonctionne, cela ressemble à ceci:

$ ssh -xvvv server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/kuba/.ssh/config
(...)

Cela a fonctionné plus tôt et je ne suis au courant de rien que j'aurais pu faire pour causer ce problème. Comment cela pourrait-il arriver et comment y remédier?

Dans le lien de documentation pointé par tike, il indique que

En raison du risque d'abus, ce fichier doit avoir des autorisations strictes: lecture / écriture pour l'utilisateur, et non accessible par d'autres.

Mes autorisations sont:

$ ls -la ~/.ssh
total 80
drwx------+ 42 kuba  1029   1428 Jul  1 16:33 ..
-rwx------   1 kuba  1029   1528 May 15 13:07 config
(...)

Je pense que le problème pourrait provenir d'une confusion au sujet du répertoire personnel. Lorsque je force le fichier de configuration local, il commence à fonctionner, puis commence soudainement à lire/nas/kuba

$ ssh -xvvvF ~/.ssh/config server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/kuba/.ssh/config
debug1: /Users/kuba/.ssh/config line 1: Applying options for *
debug1: /Users/kuba/.ssh/config line 39: Applying options for bio
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXXX [YYYY.YYY.YYY.YYY] port 22.
debug1: Connection established.
debug1: identity file /nas/kuba/.ssh/id_dsa type -1
                      ^^^^^^^^^^

Mais mon répertoire d'origine semble être réglé correctement:

$ cd ~; pwd
/Users/kuba
$ echo $HOME
/Users/kuba

Vous semblez être coincé entre ssh_config spécifique à l'utilisateur et global.

Veuillez vérifier les paramètres d'autorisation du fichier de configuration de votre utilisateur ( ~/.ssh/config) et de votre fichier de configuration à l'échelle du système ( /etc/ssh/ssh_config) pour mieux comprendre.

Vous pouvez en savoir plus à ce sujet ici . En pratique, tous les fichiers de votre .sshrépertoire utilisateur doivent être sur 600 et le configfichier sur 644. Vous pouvez définir cela avec les commandes suivantes dans votre répertoire personnel:

chmod 600 ~/.ssh/* 
chmod 644 ~/.ssh/config

vérifier les autorisations

ls -lsd ~/.ssh

et

ls -ls ~/.ssh/*

Si les autorisations sont mauvaises, le client ssh n'essaiera pas de lire

J'ai eu le même problème et j'ai pu le résoudre en définissant l'indicateur + x sur mon ~/.sshdir (0700), tout en activant 0600 ~/.ssh/config.

Pour ce que ça vaut, j'ai eu le même problème et l'ai résolu en faisant ssh pour recréer le .sshdossier (juste renommer sshet exécuter une commande ssh), et en copiant les fichiers nécessaires par la suite, avec les autorisations appropriées. (config avec 600).

Apparemment, ssh devient suspect si le dossier .sshest modifié d'une manière qu'il n'approuve pas ...

SSH ne lira pas la configuration locale si elle se trouve sur un système de fichiers monté sur NFS. Cela vaut la peine d'être vérifié car toutes les autorisations peuvent être très bien et SSH (au moins la version 6.6) ne vous donnera aucune indication de pourquoi il ne lit pas la configuration utilisateur. (Il le lira cependant à partir d'un volume NFS si vous utilisez l' -Foption.)

J'ai rencontré le même problème sur MacOs. En regardant les informations de débogage d'une connexion manuelle (ssh @), j'ai découvert qu'apparemment ssh pensait que mon répertoire personnel était /srv/home/<userid>et cherchait le .sshrépertoire là-dedans, et a ignoré celui de/Users/<userid>/.ssh/

Cela a probablement quelque chose à voir avec le travail de configuration des Mac d'une manière spécifique, mais je recommanderais de vérifier cela sshet le système d'exploitation s'accorde sur l'emplacement du répertoire personnel;)

Comme 'kasperd' l'a indiqué dans son commentaire sur la question, notez qu'il sshne recherchera pas nécessairement '$ {HOME} /. Ssh / config'. Comme cela a été découvert, il est important de creuser plus profondément et d'apprendre où se trouvait le répertoire personnel au moment de la connexion et avant qu'un nouveau HOME ne soit affirmé.

L'astuce pour parcourir la sortie de a ssh -xvvvF ~/.ssh/config serverété très utile pour aider à répondre à cette même question. En se trouvant sur un système où deux noms d'utilisateur différents ont le même UID dans le fichier '/ etc / passwd', ce problème a été rencontré. Les deux utilisateurs ont des répertoires HOME différents définis dans '/ etc / passwd'.

Dans un tel scénario, il s'avère que si l'on est connecté en tant que deuxième utilisateur avec un UID en double dans le fichier '/ etc / passwd', il sshutilise le répertoire personnel du premier utilisateur avec un UID correspondant de l'utilisateur exécutant le SSH commander.

Certes, ce cas d'utilisation est assez étrange et n'aidera pas la plupart des gens, mais cela s'est effectivement produit et ce Q / A a aidé à résoudre un problème.

Cela était dû aux paramètres d'autorisation des fichiers.

Vérifiez vos .sshautorisations de dir et de fichiers, vérifiez également vos paramètres d'autorisation de dir.

Pour moi, je ne veux pas que les autres voient mes fichiers personnels, je supprime donc la xpermission de mon répertoire home. Ce qui conduit ssh à trouver les clés autorisées vers le mauvais chemin.

Une façon de résoudre ce problème était de définir un autre chemin d'accès d'autorité /etc/ssh/sshd_config, par exemple:

AuthorizedKeysFile .ssh / authorized_keys / etc / ssh / authorized_keys

puis copiez votre pub à /etc/ssh/authorized_keys, a travaillé pour moi.