Administración del servidor

SSH Conexión Rechazada (Causas y soluciones)

Este tutorial se ocupará del error más común que probablemente encuentre con SSH: Conexión Rechazada. Continúe leyendo para ver más de cerca este problema y las diferentes soluciones al mismo.

Secure Shell (SSH) es una de las herramientas más comunes que utiliza un administrador de sistemas. Es esencial para administrar todos sus servidores y realizar las tareas diarias.


 

 

El Servicio SSH no está trabajando

La solución de problemas más básica que puede hacer es verificar primero que SSH está instalado en el sistema. Existe una versión cliente de SSH (usada para remover en otros sistemas) y una versión servidor (usada para aceptar conexiones entrantes en el sistema).

Para ver si su cliente SSH está correctamente instalado, sólo tiene que escribir “ssh” en la terminal.

$ ssh

sshclient

Verás alguna salida como la captura de pantalla de arriba si tienes el cliente SSH instalado en tu sistema.

Para comprobar si tu sistema tiene instalado el servidor SSH, intenta iniciar una conexión remota al propio sistema:

$ ssh localhost

ssh-localhost

Tratar de usar SSH en el localhost es una gran manera de ver si su sistema está aceptando conexiones actualmente.

Aquí obtenemos el temido mensaje de error “conexión rechazada”. Esto significa que el paquete del servidor SSH no está instalado en el sistema, o podría significar que el servicio no se está ejecutando actualmente.

Intentemos comprobar el estado del servicio SSH:

$ systemctl status sshd

ssh-status

Al comprobar el estado del daemon SSH, el sistema nos informa de que no se ha podido encontrar el servicio. Eso significa que tenemos que instalarlo.

En este ejemplo estamos usando Ubuntu, así que vamos a usar apt-get para instalar el paquete openssh-server. Es posible que tenga que usar un comando ligeramente diferente, dependiendo de la distribución que esté usando.

$ sudo apt-get install openssh-server

Instalar el servidor openssh

Luego de la instalación, del servicio SSH puede iniciar automáticamente. Para revisar si está corriendo, revise el estatus nuevamente:

SSH trabajando

Systemctl nos muestra que los servicios SSH ahora está corriendo (presiones “q” para salir de esta pantalla y regresar a la terminal).

Si el daemon SSH no está corriendo en su sistema todavía, usted puede comenzar con:

$ systemctl start sshd

Iniciar SSH


Olvidar Abrirlo en el Inicio de sesión Y Solución

Iniciar el servicio de SSH cada vez que lo necesita es obviamente un poco molesto, así que si quiere asegurarse de que su sistema está abierto a recibir conexiones SSH automáticamente cuando se inicia, puede usar el siguiente comando como raíz o con sudo:

$ sudo systemctl enable ssh

Habilitar SSH al inicio

La ejecución de este comando le indica a su sistema que inicie el servicio de SSH cada vez que la computadora se inicia. Si necesita revertir esta configuración más adelante, simplemente escriba el mismo comando, pero con “disable” en lugar de “enable”.


El puerto SSH no está abierto

Si todavía tienes problemas de conexión después de verificar que el servicio SSH está funcionando, quizás la conexión SSH está siendo bloqueada antes de que tenga la oportunidad de llegar al sistema – como en tu router.

Es común que los routers bloqueen las conexiones SSH entrantes en el puerto 22. Puedes usar cualquier prueba de reenvío de puertos para ver si el puerto es visible o no en Internet. Si no lo es, la conexión puede ser bloqueada en su router o en el cortafuegos de su sistema, lo que veremos a continuación.

Para configurar su router para permitir conexiones SSH entrantes, necesitará consultar las instrucciones del fabricante con respecto al reenvío de puertos en su modelo de router en particular.


El cortafuegos está bloqueando el puerto SSH

Otra cosa que hay que comprobar es el cortafuegos de su sistema operativo. Ubuntu y muchas otras distribuciones tienen ufw (cortafuegos sin complicaciones) instalado de forma predeterminada y suele ser una de las formas más comunes de emitir rápidamente comandos relacionados con el cortafuegos a su sistema.

Para permitir SSH a través de su cortafuegos a través de ufw, utilice este comando:

$ sudo ufw allow ssh

UFW firewall SSH

Ufw es sólo una interfaz para el iptables firewall, así que si prefiere usar un comando de iptables (o tal vez ni siquiera tenga instalado ufw), aquí está el comando de iptables para permitir conexiones SSH entrantes:

$ sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Si está corriendo firewalld y necesita permitir las conexiones SSH, utilice este comando:

$ firewall-cmd --zone=public --add-service=ssh

 

SELinux Bloqueando SSH

Algunas distribuciones, como Red Hat y las que se basan en ella, ejecutan SELinux (Security Enhanced Linux). SELinux debería estar configurado automáticamente para escuchar en el puerto 22 para SSH, y puede verificarlo con el siguiente comando:

$ semanage port -l | grep ssh

SELinux Bloqueando SSH

En la captura de pantalla anterior, el comando semanage nos muestra que está escuchando las conexiones SSH entrantes en el puerto 22 (el puerto por defecto para SSH). No debería necesitar hacer ninguna configuración extra para esto, a menos que esté intentando cambiar el puerto en el que su sistema ejecuta el servicio SSH.

Si necesita configurar SELinux para que escuche SSH en un puerto diferente, puede usar este comando:

$ semanage port -a -t ssh_port_t -p tcp 1234

Reemplace “1234” con el nuevo puerto que ha configurado para que el SSH corra.

Asegúrese de reiniciar el servicio SSH luego que realice estos cambios:

$ systemctl restart sshd

 


Problema de conflicto de direcciones IP

Si su sistema tiene una dirección IP duplicada en la red, es probable que SSH (y otros servicios que dependen de su red) tengan problemas para funcionar correctamente. Esto es siempre algo bueno para comprobar, y es bastante simple de hacer con el comando host.

$ host x.x.x.x

Problema de conflicto de direcciones IP

El comando host regresa con información sobre la dirección IP que le acabamos de pasar. Utiliza el nombre del host para determinar que efectivamente está intentando llegar al sistema correcto.

En Windows, puede utilizar ping -a en la línea de comandos para lograr un resultado similar:

comando ping

Cambio en la clave publica luego de la reinstalación

El servicio de SSH genera una clave pública única para cada sistema. Esto se hace de manera que los clientes que se conectan a un sistema tienen una forma de asegurarse de que se están conectando al servidor deseado.

Por ejemplo, ¿qué pasa si el servidor al que te conectas normalmente tiene direcciones IP cambiadas? No querrá escribir su información de inicio de sesión en el sistema equivocado que ha asumido la dirección IP anterior.

Claves SSH

Si se produce una situación como esta, tu cliente SSH debería advertirte que las claves públicas han cambiado. La ruta $HOME/.ssh contiene todas las claves de los hosts a los que tu sistema se ha conectado anteriormente. Puede revisar el archivo known_hosts de la siguiente manera:

$ cat ~/.ssh/known_hosts

SSH conocidos hosts

Sólo hay un host en nuestro archivo, pero incluso eso nos parece un galimatías. En lugar de editar este archivo nosotros mismos, es mejor usar el comando ssh-keygen para eliminar una clave de host concreta del archivo.

$ ssh-keygen -r x.x.x.x

O

$ ssh-keygen -r example.com

Utilice la dirección IP o el nombre de host del servidor. En nuestro ejemplo, la clave de nuestro archivo es sólo de localhost, así que la eliminamos así:

Eliminar clave SSH


Permisos de archivos de claves SSH

Dado que el cliente SSH lee del archivo known_hosts cuando se conecta a un sistema diferente, el usuario actual necesitará tener los permisos adecuados sobre ese archivo.

Sin los permisos adecuados, puede ver un error como este:

Permisos de clave SSH

Si utiliza claves para autentificar (en lugar de una contraseña), se le bloqueará el sistema por completo hasta que arregle los permisos de sus archivos de claves. La ejecución de estos comandos debería remediar el problema:

$ chmod 700 ~/.ssh

$ chmod 644 ~/.ssh/authorized_keys

$ chmod 644 ~/.ssh/known_hosts

$ chmod 644 ~/.ssh/config

$ chmod 600 ~/.ssh/id_rsa

$ chmod 644 ~/.ssh/id_rsa.pub

 

Inicio de sesión raíz, si está desactivado y cómo activarlo

Por razones de seguridad, Linux casi nunca quiere que haga nada como raíz por defecto. Cuando sea posible, se supone que debes usar una cuenta con menos permisos, y sólo elevar a raíz cuando sea necesario.

Bueno, esto se recomienda en muy pocas situaciones, y a veces puede que quieras entrar directamente a raíz. SSH está configurado por defecto para denegar los inicios de sesión de raíz.

Si está intentando entrar en un sistema como raíz y no ha hecho ninguna configuración para permitirlo, sólo podrá entrar usando una cuenta de usuario normal.

Puede configurar su servidor SSH para permitir el acceso a raíz editando el archivo sshd_config. Utilice nano, vi, o su otro editor de texto favorito para abrir el archivo aquí:

$ sudo vi /etc/ssh/sshd_config

Deslice hacia abajo este archivo hasta que vea PermitRootLogin.

Inicio de sesión raíz

En nuestra instalación de Ubuntu, PermitRootLogin está, por defecto, configurado como “prohibit-password”. Esto significa que podemos iniciar sesión como raíz a través de la autenticación de la clave, pero no suministrando la contraseña de raíz.

En algunos sistemas, puede que sólo diga “no”, lo que significa que no se permiten los inicios de sesión de raíz de ningún método de autenticación.

Para permitir que el usuario raíz inicie sesión a través de SSH, puede cambiar esta línea para que diga “yes”. Asegúrese de quitar el # al principio para que no se comente más. Tendría que verse así para permitir los inicios de sesión de raíz:

Inicio de sesión raíz permitido

Siempre que haga cambios en este archivo, tiene que reiniciar el servicio SSH para que surtan efecto:

$ sudo systemctl restart ssh

Advertencia: Por favor, asegúrese de tener una contraseña de raíz muy segura antes de editar el fichero de configuración SSH para permitir el acceso a raíz con una contraseña. Hay bots que constantemente analizan Internet en busca de servidores en los que usar SSH, e intentarán entrar en la cuenta de raíz más que cualquier otro.

Por eso SSH está configurado de forma predeterminada para no permitir ningún tipo de acceso a la cuenta de raíz mediante contraseña. En la siguiente sección se muestra cómo ver estos intentos de conexión y se muestra un ejemplo real de cómo se ejecutan constantemente los ataques contra nuestro servidor de producción en vivo.

Backlog de solicitudes de conexión (Flooding)

Todos los intentos de conexión que se han hecho a su servidor se mantienen en un log file. El uso de este archivo de registro puede ser útil para solucionar problemas de conexión o de cuentas de usuario, pero también puede utilizarlo para determinar si su servidor se ha visto inundado de solicitudes de conexión.

Compruebe si hay intentos de conexión fallidos con este comando:

$ cat /var/log/auth.log | grep "Failed password"

Si tiene un servidor abierto a Internet en el puerto 22, va a ser común recibir al menos unos pocos intentos de conexión cada 10 minutos más o menos, sólo por el hecho de que los bots navegan constantemente por Internet en busca de servidores débiles para hackear.

Aquí está un vistazo al archivo auth.log de uno de mis servidores públicos:

Contraseñas incorrectas

No hay nada alarmante en esta captura de pantalla, ya que los intentos de conexión se espacian por lo menos unos segundos cada vez.

Para endurecer su servidor de ataques de fuerza bruta SSH, le recomendamos que instale el Firewall de CSF. Está configurado por defecto para detener los repetidos intentos de SSH desde la misma dirección IP. Puede ajustar esta configuración a su gusto, pero el valor predeterminado debería ser adecuado para la mayoría de los sistemas:

$ vi /etc/csf/csf.conf

# [*]Habilitar la detección de fallos de conexión de las conexiones sshd

LF_SSHD = "5"

LF_SSHD_PERM = "1"

LF_SSHD ajustado a “5” es el número máximo de conexiones fallidas antes de bloquear la dirección IP.

LF_SSHD_PERM ajustado a “1” hace que este bloqueo sea permanente.

Otro método popular para limitar estos intentos de conexión falsos es poner en una lista blanca las IPs de confianza y bloquear todas las demás. Esto sólo funciona si las mismas IPs son siempre SSHing a su servidor. Para lograr esto con iptables, usted usaría este comando:

$ sudo iptables -A INPUT -p tcp -s 10.1.1.1,10.1.1.2 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Este comando sólo permitirá conexiones SSH de 10.1.1.1 y 10.1.1.2. Puede listar tantas IPs como necesite en ese comando, o listar una subred completa, como en 10.1.1.0/24. Tenga en cuenta que la política de cadena de su entrada debe estar configurada para que se elimine.

Utilizar ssh -vvvv para depurar la conexión SSH y comprobar los registros

Obtener un simple error como “conexión rechazada” no es tan útil para averiguar cuál es el problema. Si quieres ver más información acerca de lo que está sucediendo durante el intento de conexión SSH, puedes usar ssh -v.

$ ssh -v hostname

O

$ ssh -vvv hostname

Colocar tres V’s en el comando aumentara aún más la verbosidad.

ssh-verbose manual

Obtendrá mucha salida con el interruptor -vvvv, pero aquí tiene una pequeña muestra de cómo se ve algo de esto:

comando ssh-verbose

Con suerte, imprimirá un error que le dará una pista de lo que hay que arreglar. Si no es así, intente buscar en Google el error que recibe para ver si ha habido una sugerencia publicada en línea.

He cubierto la mayoría de las causas del problema de la conexión SSH rechazada y espero que encuentres el tutorial útil.

Sigue volviendo.

Mokhtar Ebrahim
Estoy trabajando como administrador de sistemas Linux desde 2010. Soy responsable de mantener, proteger y solucionar problemas de servidores Linux para múltiples clientes de todo el mundo. Me encanta escribir guiones de shell y Python para automatizar mi trabajo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *