Estoy intentando conectarme desde una MacBook Air (MacOS 10.14.6) a través de ssh (sin contraseña) a una máquina Ubuntu (16.04.6), usando un comando como
ssh aaa.bbb.ccc.ddd
Siempre funcionó bien, recibí un mensaje y pude comenzar a trabajar en la máquina remota.
Sin embargo, durante aproximadamente una semana, esto ya no funciona, sin saber ningún cambio que haya realizado en el proceso de inicio de sesión, nuevos usuarios, cambio de contraseña, cambio de claves, actualización del sistema operativo, cambios, .profileetc. .bashrcTambién verifiqué /etc/hosts.allowy /etc/hosts.denyno hay nada allí. y reinicié la máquina ubuntu y la Mac, pero no hubo cambios.
En el momento en que inicio sesión correctamente, veo un mensaje
Last login: ... from www.xxx.yyy.zzz
Connection to aaa.bbb.ccc.ddd closed
¿Cómo puedo depurar lo que está pasando?
Apéndice
Al verificar /var/log/auth.logveo las siguientes entradas:
Oct 16 07:02:38 mac353 systemd-logind[1173]: New session 11 of user alex.
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Oct 16 07:02:38 mac353 sshd[11834]: Disconnected from www.xxx.yyy.zzz port 61437
Respuesta1
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
¿Es www.xxx.yyy.zzzla dirección IP correcta para su MacBook Air en este momento?
Puede ser que haya otro sistema en la red que utilice la misma dirección IP. Puede iniciar una conexión normalmente, pero las respuestas se entregan aleatoriamente a ambos sistemas que participan en el conflicto de direcciones IP, por lo que es posible que el servidor tenga que volver a enviar algunos de sus paquetes salientes. Normalmente, el sistema que está intentando activamente establecer una conexión responderá más rápido, por lo que para algunos paquetes iniciales puede parecer que funciona bien.
Pero eventualmente el controlador TCP/IP del sistema en conflicto pensará: "¿Qué es este tráfico? No tengo ninguna conexión TCP activa en este momento". y enviar un paquete de reinicio de TCP a la fuente del tráfico de apariencia espuria, es decir, al servidor. Debido a que el sistema en conflicto tiene la misma dirección IP que su MacBook, el servidor no tiene forma de saber que el reinicio de TCP en realidad no pertenece a su conexión, por lo que el servidor asumirá que el reinicio de TCP significatúquería desconectar. No sucede inmediatamente porque el envío de paquetes de reinicio de TCP suele ser un trabajo de baja prioridad dentro del controlador TCP/IP.
Este sería un síntoma muy típico de un conflicto de direcciones IP.
Para encontrar el sistema en conflicto, puede intentar consultar las tablas de direcciones MAC del conmutador de red (si es un conmutador administrado) o el AP WiFi de su segmento de red local. Si su dirección IP está asociada con una dirección MAC que no pertenece a su MacBook, ha encontrado la dirección MAC del sistema en conflicto. En una red cableada, puede verificar qué puerto del conmutador ha visto esa dirección MAC y luego ver qué hay en el otro extremo del cable.
Si no tiene conmutadores administrados o no tiene acceso a ellos, puede intentar hacer ping a su propia dirección IP y ver si obtiene respuestas duplicadas. O podría probar la arpingherramienta de línea de comandos para hacer lo mismo con los paquetes ARP: eso detectará incluso los sistemas que no responden a los pings.
Respuesta2
La solución a este problema fue set -eque estaba en un archivo /etc/profile.dque se instaló en un contexto completamente diferente. Después de cambiar el nombre de ese archivo, el sshinicio de sesión funcionó nuevamente.
`set -e`
detiene la ejecución de un script si un comando tiene un error (mira aquí) y algunos lo consideran una mala práctica.