Header Ads Widget

Ticker

6/recent/ticker-posts

Conexión SSH rechazada (causas y soluciones)

 Este tutorial analizará el error más común que probablemente encontrará con SSH Connection Refused. Siga leyendo para ver más de cerca este problema y las diversas soluciones al mismo.

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

El servicio SSH no funciona

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 de cliente de SSH (que se utiliza para la comunicación remota con otros sistemas) y una versión de servidor (que se utiliza para aceptar conexiones entrantes en el sistema).

Para ver si su cliente SSH está instalado correctamente, simplemente escriba "ssh" en la terminal.

1
$ssh

Verá un resultado como la captura de pantalla anterior si tiene el cliente SSH instalado en su sistema.

Para comprobar si su sistema tiene el servidor SSH instalado, intente iniciar una conexión remota con el propio sistema:

1
$ ssh localhost

Intentar SSH en el host local es una excelente manera de ver si su sistema está aceptando conexiones actualmente.

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

Intentemos verificar el estado del servicio SSH:

1
$ systemctl status sshd

Al verificar el estado del demonio SSH, el sistema nos informa que no se pudo encontrar el servicio. Eso significa que necesitamos instalarlo.

Estamos usando Ubuntu en este ejemplo, entonces usaremos apt-get para instalar el paquete openssh-server. Es posible que deba usar un comando ligeramente diferente, dependiendo de la distribución que esté usando.

1
$ sudo apt-get install openssh-server

Después de la instalación, el servicio SSH puede iniciarse automáticamente. Para comprobar si se está ejecutando, vuelva a comprobar el estado:

Systemctl nos muestra que el servicio SSH ahora se está ejecutando (presione 'q' para salir de esta pantalla y regresar a la terminal).

Si el demonio SSH aún no se está ejecutando en su sistema, puede iniciarlo con:

1
$ systemctl start sshd

Olvídese de abrirlo al inicio y solución

Iniciar el servicio SSH cada vez que lo necesita es obviamente un poco molesto, por lo que si desea asegurarse de que su sistema esté abierto para recibir conexiones SSH automáticamente cuando se inicie, puede usar el siguiente comando como root o con sudo :

1
$ sudo systemctl enable ssh

La ejecución de este comando le dice a su sistema que inicie el servicio SSH cada vez que se inicie la computadora. Si necesita revertir esta configuración más adelante, simplemente escriba el mismo comando pero con "deshabilitar" en lugar de "habilitar".

El puerto SSH no está abierto

Si aún tiene problemas de conexión después de verificar que el servicio SSH está funcionando, tal vez la conexión SSH se esté bloqueando antes de que tenga la oportunidad de llegar al sistema, como en su enrutador.

Es común que los enrutadores bloqueen las conexiones SSH entrantes en el puerto 22. Puede usar cualquier probador de reenvío de puertos para ver si el puerto es visible o no en Internet. Si no es así, es posible que la conexión esté bloqueada en su enrutador o en el firewall de su sistema, que veremos a continuación.

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

El firewall está bloqueando el puerto SSH

Otra cosa que debe verificar es el firewall de su sistema operativo. Ubuntu y muchas otras distribuciones tienen ufw (firewall sin complicaciones) instalado de forma predeterminada y generalmente es una de las formas más comunes de emitir rápidamente comandos relacionados con el firewall en su sistema.

Para permitir SSH a través de su firewall a través de ufw, use este comando:

1
$ sudo ufw allow ssh

Ufw es solo un front-end para el firewall de iptables , por lo que si prefiere usar un comando de iptables (o tal vez ni siquiera tiene ufw instalado), aquí está el comando de iptables para permitir conexiones SSH entrantes:

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

Si está ejecutando firewalld y necesita permitir conexiones SSH, use este comando:

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

SELinux bloqueo SSH

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

1
$ semanage port -l | grep ssh

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

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

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

Reemplace "1234" con el nuevo puerto en el que ha configurado SSH para que se ejecute.

Asegúrese de reiniciar el servicio SSH después de realizar estos cambios:

1
$ systemctl restart sshd

Problema de conflicto de dirección 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. Siempre es bueno comprobarlo, y es bastante sencillo de hacer con el comando host.

1
$ host x.x.x.x

El comando host regresa con información sobre la dirección IP que le acabamos de pasar. Utilice el nombre de host para determinar que realmente está tratando de comunicarse con el sistema correcto.

En Windows, puede usar ping -a en el símbolo del sistema para lograr un resultado similar:

Cambio de claves públicas después de reinstalar

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

Por ejemplo, ¿qué pasa si el servidor al que normalmente se conecta ha cambiado de dirección IP? No desea ingresar su información de inicio de sesión en el sistema incorrecto que asumió la dirección IP anterior.

Si ocurre una situación como esta, su cliente SSH debería advertirle que las claves públicas han cambiado. La ruta $ HOME / .ssh contiene todas las claves de los hosts a los que su sistema se ha conectado antes. Puede consultar el archivo known_hosts así:

1
$ cat ~/.ssh/known_hosts

Solo 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 en particular del archivo.

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

O

1
$ ssh-keygen -r example.com

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

Permisos de archivos de clave SSH

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

Sin los permisos adecuados, es posible que vea un error como este:

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

1
2
3
4
5
6
$ chmod 700 ~/.ssh</p><font></font>
<p>$ chmod 644 ~/.ssh/authorized_keys</p><font></font>
<p>$ chmod 644 ~/.ssh/known_hosts</p><font></font>
<p>$ chmod 644 ~/.ssh/config</p><font></font>
<p>$ chmod 600 ~/.ssh/id_rsa</p><font></font>
<p>$ chmod 644 ~/.ssh/id_rsa.pub

Inicio de sesión de root si está deshabilitado y cómo habilitarlo

Por razones de seguridad, Linux casi nunca quiere que hagas nada como root de forma predeterminada. Cuando sea posible, se supone que debe usar una cuenta con menos permisos y solo elevar a root cuando sea necesario.

Bueno, esto se recomienda en muy pocas situaciones y, a veces, es posible que desee iniciar sesión directamente en la raíz. SSH está configurado de forma predeterminada para denegar los inicios de sesión de root.

Si está intentando iniciar sesión en un sistema como root y no ha realizado ninguna configuración para permitirlo, solo podrá acceder utilizando una cuenta de usuario normal.

Puede configurar su servidor SSH para permitir inicios de sesión de root editando el archivo sshd_config. Utilice nano, vi o su otro editor de texto favorito para abrir el archivo aquí:

1
$ sudo vi /etc/ssh/sshd_config

Desplácese hacia abajo en este archivo hasta que vea PermitRootLogin.

En nuestra instalación de Ubuntu, PermitRootLogin está, por defecto, configurado en "prohibir-contraseña". Esto significa que podemos iniciar sesión como root mediante autenticación de clave, pero no proporcionando la contraseña de root.

En algunos sistemas, puede ver que simplemente dice "no", lo que significa que no se permiten los inicios de sesión de root de ningún método de autenticación.

Para permitir que el usuario root inicie sesión a través de SSH, puede cambiar esta línea para decir que sí. Asegúrese de eliminar el # al principio para que ya no esté comentado. Debería verse así para permitir inicios de sesión de root:

Siempre que realice cambios en este archivo, debe reiniciar el servicio SSH para que surtan efecto:

1
$ sudo systemctl restart ssh

Advertencia: asegúrese de tener configurada una contraseña de root muy segura antes de editar el archivo de configuración SSH para permitir el inicio de sesión de root con una contraseña. Hay bots que escanean constantemente Internet en busca de servidores para SSH, e intentarán iniciar sesión en la cuenta raíz más que cualquier otro.

Es por eso que SSH está configurado de forma predeterminada para no permitir ningún tipo de inicio de sesión de root mediante contraseña. Mostramos en la siguiente sección cómo ver estos intentos de conexión y mostramos un ejemplo real de cómo los ataques se ejecutan constantemente contra nuestro servidor de producción en vivo.

Pila de solicitudes de conexión (Flooding)

Todos los intentos de conexión que se han realizado a su servidor se guardan en un archivo de registro . Examinar este archivo de registro puede ser útil para solucionar problemas de conexión o de cuentas de usuario, pero también puede usarlo para determinar si su servidor se ha inundado de solicitudes de conexión.

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

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

Si tiene un servidor abierto a Internet en el puerto 22, será común obtener al menos algunos intentos de conexión cada 10 minutos aproximadamente, solo porque los bots navegan constantemente por Internet en busca de servidores débiles para piratear.

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

Nada alarmante en esta captura de pantalla, ya que los intentos de conexión se espacian al menos unos segundos cada vez.

Para proteger su servidor de ataques de fuerza bruta SSH, le recomendamos instalar CSF Firewall . Está configurado de forma predeterminada para detener los intentos repetidos de SSH desde la misma dirección IP. Puede ajustar estas configuraciones a su gusto, pero la predeterminada debería adaptarse bien a la mayoría de los sistemas:

1
$ vi /etc/csf/csf.conf

# [*] Habilitar la detección de errores de inicio de sesión de las conexiones sshd

1
2
LF_SSHD = "5"</p><font></font>
<p>LF_SSHD_PERM = "1"

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

LF_SSHD_PERM establecido en "1" hace que este bloqueo sea permanente.

Otro método popular para limitar estos intentos de conexión falsos es incluir en la lista blanca las direcciones IP confiables y bloquear todas las demás. Esto solo funciona si las mismas direcciones IP están siempre conectando SSH a su servidor. Para lograr esto con iptables, usaría este comando:

1
$ 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 solo permitirá conexiones SSH desde 10.1.1.1 y 10.1.1.2. Puede enumerar tantas IP como necesite en ese comando, o enumerar una subred completa, como 10.1.1.0/24. Tenga en cuenta que la política de cadena de su entrada debe estar configurada para eliminarse.

Uso de ssh -vvv para depurar la conexión SSH y verificar los registros

Obtener un error simple como "conexión rechazada" no es tan útil para averiguar cuál es el problema. Si desea ver más información sobre lo que sucede durante el intento de conexión SSH, puede usar ssh -v.

1
$ ssh -v hostname

O

1
$ ssh -vvv hostname

Poner tres v en el comando aumentará aún más la verbosidad.

Obtendrá una gran cantidad de resultados con el modificador -vvv, pero aquí hay una pequeña muestra de cómo se ve:

Con suerte, imprimirá un error que le dará una pista sobre lo que debe solucionarse. De lo contrario, intente buscar en Google el error que recibe para ver si se ha publicado una sugerencia en línea.

Cubrí la mayoría de las causas del problema de conexión SSH rechazada y espero que el tutorial le resulte útil.

Sigue regresando.

Publicar un comentario

0 Comentarios