ssh ya no usa ~ / .ssh / config

No puedo decir nada de lo que pude. Después de un poco de excavación descubrí que no está leyendo ssh config desde mi directorio de inicio.

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

Cuando se encuentra en una computadora idéntica de un amigo, donde todo funciona se ve así:

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

Funcionó antes y no sé nada de lo que podría haber hecho para causar este problema. ¿Cómo podría suceder esto y cómo solucionarlo?

En el enlace de documentación señalado por tike, indica que

Debido a la posibilidad de abuso, este archivo debe tener permisos estrictos: lectura / escritura para el usuario y no accesible para otros.

Mis permisos son:

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

Creo que el problema podría deberse a una confusión sobre el directorio de inicio. Cuando fuerzo el archivo de configuración local, comienza a funcionar y, de repente, comienza a leer/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
                      ^^^^^^^^^^

Pero mi directorio de inicio parece estar configurado bien:

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

Parece estar atrapado entre ssh_config específico del usuario y global.

Verifique la configuración de permisos del archivo de configuración de su usuario ( ~/.ssh/config) y su archivo de configuración de todo el sistema ( /etc/ssh/ssh_config) para comprender con más detalles.

Puedes leer más sobre esto aquí . Prácticamente, todos los archivos en su .sshdirectorio basado en el usuario deben estar en 600, y el configarchivo debe estar en 644. Puede configurar esto con los siguientes comandos en su directorio de inicio:

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

verificar permisos

ls -lsd ~/.ssh

y

ls -ls ~/.ssh/*

Si los permisos son malos, entonces el cliente ssh no intentará leerlo

Tuve el mismo problema y pude solucionarlo configurando el indicador + x en mi ~/.sshdirectorio (0700), y también configurando 0600 ~/.ssh/config.

Para lo que vale, tuve el mismo problema y lo arreglé haciendo ssh para crear nuevamente la .sshcarpeta (solo renombra sshy ejecuta algún comando ssh), y luego copié los archivos necesarios, con los permisos apropiados. (config con 600).

Aparentemente, ssh se vuelve sospechoso si la carpeta .sshse modifica de una manera que no aprueba ...

SSH no leerá la configuración local si está en un sistema de archivos montado en NFS. Vale la pena verificarlo porque todos los permisos pueden estar bien y SSH (al menos la versión 6.6) no le dará ninguna indicación de por qué no está leyendo la configuración del usuario. (Sin embargo, lo leerá de un volumen NFS si usa la -Fopción).

Encontré el mismo problema en MacOs. Al mirar la información de depuración de un inicio de sesión manual (ssh @), descubrí que aparentemente ssh pensaba que mi directorio de inicio estaba /srv/home/<userid>y estaba buscando el .sshdirectorio allí, e ignoré el que estaba en/Users/<userid>/.ssh/

Probablemente tenga algo que ver con el trabajo de configuración de las Mac de una manera específica, pero recomendaría verificar eso sshy el Sistema Operativo acuerda dónde está el directorio de inicio;)

Como 'kasperd' indicó en su comentario sobre la pregunta, tenga en cuenta que sshno necesariamente buscará '$ {HOME} /. Ssh / config'. Como se descubrió, es importante profundizar y aprender dónde estaba el directorio de inicio en el momento del inicio de sesión y antes de que se afirmara un nuevo HOME.

La sugerencia para mirar a través de la salida de ssh -xvvvF ~/.ssh/config serverfue muy perspicaz para ayudar a responder esta misma pregunta. Al encontrarse en un sistema donde dos nombres de usuario diferentes tienen el mismo UID en el archivo '/ etc / passwd', se encontró este problema. Los dos usuarios tienen diferentes directorios HOME configurados en '/ etc / passwd'.

En tal escenario, resulta que si uno está conectado como el segundo usuario con un UID duplicado en el archivo '/ etc / passwd', sshusa el directorio de inicio del primer usuario con un UID coincidente del usuario que ejecuta el SSH mando.

Por supuesto, este caso de uso es bastante extraño y no ayudará a la mayoría de las personas, pero en realidad sucedió, y este Q / A ayudó a resolver un problema.

Esto fue causado por la configuración de permisos de archivo.

Verifique los .sshpermisos de su directorio y archivos, también verifique la configuración de permisos de su directorio de inicio.

Para mí, no quiero que otros vean mis archivos personales, por lo que elimino el xpermiso del directorio de mi casa. Lo que lleva a ssh a encontrar claves autorizadas para la ruta incorrecta.

Una forma de solucionar esto era establecer otra ruta de autoridad /etc/ssh/sshd_config, por ejemplo:

AuthorizedKeysFile .ssh / Authorizedkeys / etc / ssh / Authorizedkeys

luego copia tu pub a /etc/ssh/authorized_keys, funcionó para mí.