Mi LAN comprende una computadora de escritorio que ejecuta Linux (Debian Wheezy), una MacBook con OS X Mavericks y un módem-router; ssh con Linux host y OS X client funciona bien, sin problemas de conexión de cliente a host.
Además, he intentado implementar el sistema inverso: la computadora Linux también se convirtió en un cliente y la computadora OS X también se convirtió en un host. Pero intentar ssh desde un cliente Linux a un host OS X da como resultado
ssh_exchange_identification: Connection closed by remote host
Esto sucede independientemente de si el firewall de Mac está activado o desactivado.
He intentado numerosas soluciones sugeridas por las búsquedas de Google, incluso en:
introduzca la descripción del enlace aquí introduzca la descripción del enlace aquí
(El sistema no me permitió publicar más enlaces).
Estoy bastante seguro de que la propiedad de los archivos, los permisos, las configuraciones son correctas.
El mismo puerto, digamos 1234, está configurado para ssh en cada computadora como host y cliente; Los comandos de netstat de ambas computadoras indican que se escucha el puerto 1234. Ni DenyHosts ni fail2ban están instalados.
En el cliente Linux, /var/log/auth.log no da ningún mensaje relevante.
Telneting de cliente a host da
Connection closed by foreign host.
En el host OS X, en el momento de un intento de conexión ssh:
/var/log/appfirewall.log muestra
MacBook.local socketfilterfw[636] <Info>: sshd-keygen-wrapper: Allow TCP CONNECT (in:1 out:0 )
/var/log/system.log muestra
MacBook.local com.apple.preference.security.remoteservice[662]: nsc_smb XPC: handle_event error : < Connection invalid >
Parece que el problema reside en el host OS X y que la clave para resolverlo podría estar en estos mensajes, pero no he podido encontrar información útil.
En la MacBook, Preferencias del sistema & gt; Seguridad y amp; Privacidad & gt; Cortafuegos & gt; Las opciones de firewall, "Inicio de sesión remoto (SSH)" y "sshd-keygen-wrapper" están configuradas para "Permitir conexiones entrantes".
"Inicio de sesión remoto" está habilitado en Preferencias del sistema & gt; Compartiendo
¿Qué podría estar causando el problema de conexión ssh y cómo resolverlo?
Información adicional desde la publicación inicial
Gracias por las respuestas, pero ya había hecho todo lo que se describe en los enlaces, había iniciado sesión de forma remota con mi nombre de usuario (alex) como usuario, y reinicié ssh en ambas computadoras después de cada cambio relacionado con ssh, seguido de reiniciar las dos computadoras. También reinstalé ssh varias veces en la computadora con Linux y generé nuevas claves varias veces en ambas computadoras.
Quizás debería haberlo aclarado en ssh_config para ambos clientes
PasswordAuthentication no
PubkeyAuthentication yes
Aquí está la salida solicitada del host OS X: (no estoy seguro de lo útil que es porque cambié el puerto ssh de los 22 predeterminados, por ejemplo, 1234)
MacBook:~ alex$ ssh -vvv localhost
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: connect to address ::1 port 22: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
debug1: Connecting to localhost [fe80::1%lo0] port 22.
debug1: connect to address fe80::1%lo0 port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused
Información adicional aclaratoria:
MacBook:~ alex$ ssh -vvv -p 1234 localhost
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 1234.
debug1: connect to address ::1 port 1234: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 1234.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/alex/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/alex/.ssh/id_rsa type 1
debug1: identity file /Users/alex/.ssh/id_rsa-cert type -1
debug1: identity file /Users/alex/.ssh/id_dsa type -1
debug1: identity file /Users/alex/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: Connection closed by remote host
MacBook:~ alex$
Salida solicitada desde el cliente de Linux:
alex@desktop:~$ ssh -v alex@MacBook.local
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 102: Applying options for *
debug1: Connecting to MacBook.local [192.168.0.3] port 1234.
debug1: Connection established.
debug1: identity file /home/alex/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alex/.ssh/id_rsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
alex@desktop:~$
Después de esforzarme mucho para que ssh trabajara con Linux como host y OS X como cliente, pensé que hacer lo contrario sería relativamente simple. Tal vez sea, pero no tan lejos! Otra ayuda sería muy apreciada.
Lars
MacBook:~ alex$ sudo sshd -t
Password:
/etc/sshd_config: No such file or directory
MacBook:~ alex$
El archivo sshd_config está en / private / etc / ssh, al igual que ssh_config y los archivos de claves ssh_host.
Problema resuelto
Coloqué una copia de sshd_config en / private / etc e hice sudo sshd -t. La salida dio errores de formato que sugieren errores de estilo con una referencia a rtf. La fuente era Times. Había copiado el archivo desde la computadora Linux y en el proceso la fuente cambió de texto sin formato.
Cambié el archivo sshd_config en / private / etc / ssh a texto sin formato, alterné "Inicio de sesión remoto" en Preferencias del sistema & gt; Compartir en la Mac, emitió el comando ssh desde el cliente de Linux y pudo conectarse al host OS X por primera vez.
No había encontrado el sshd -t comando antes, así que gracias Lars por llamarme la atención y señalarme la dirección correcta. La solución era realmente simple, pero identificarla no lo era.
sudo sshd -t¿En tu Mac nota algún problema de configuración?