miércoles, 24 de junio de 2009

ssh_exchange_identification

Ayer por la tarde, configurando vsftpd en una máquina con Debian GNU/Linux añadí una interfaz de red a mayores. En principio todo parecía funcionar sin problemas. Probe la conectividad desde el segmento de red vía ICMP, pedí vía HTTP un documento al servidor web de esta misma máquina y todo parecía funcionar. La sorpresa es cuando, al llegar a casa ,intento conectarme vía SSH. Misión imposible, devuelve el error: ssh_exchange_identification. La solución fue muy sencilla :

echo 'SSHD: ALL' >> /etc/hosts.allow

Pero mi pregunta es la siguiente: ¿ por qué ? Esto es lo que odio muchas veces de los foros de Internet. La gente resuelve un problema despreocupándose del porqué, algo que a mi modo de ver es tanto o más importante que el propio problema en sí. Saber el origen ayuda a no volver a cometer el mismo error en un futuro. Pues manos a la obra. Vamos a intentar averiguar el por qué del ssh_exchange_identification.
Leo en este post, que OpenSSH usa TCPWrappers, escrito por el maestro Wietse Venema , os suena de algo. Postfix quizá? TCPWrappers es un sistema de Listas de Control de Acceso(ACL) para servicios de la pila de protocolos TCP/IP. Incluye una librería libwrap que incluye las principales funcionalidades de filtrado. Intuyo que al detectar que se ha añadido una nueva interfaz, la acción por defecto es denegar el acceso a SSH; y puesto que TCPWrapper usa /etc/hosts.allow y /etc/hosts.deny para definir qué servicios "envuelve",la explicación ahora, a mi modo de ver, queda un poco más clara, verdad?

Comprobamos si efectivamente OpenSSH está compilado con libwrap:

root@pilarrubio#ldd /usr/sbin/sshd
linux-gate.so.1 => (0xffffe000)
libwrap.so.0 => /lib/libwrap.so.0 (0xb7f3c000)
libpam.so.0 => /lib/libpam.so.0 (0xb7f31000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f2c000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7f12000)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7efc000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7da4000)
(...)

No hay comentarios: