<<TableOfContents: execution failed «] (ver también el log)>>
OpenSSH (o Secure SHell) se ha convertido en un estándar de facto para el acceso remoto sustituyendo al protocolo telnet. SSH ha hecho que protocolos como telnet sean redundantes debido, en gran parte, a que la conexión está encriptada y las contraseñas ya no se envían en texto plano para que todos las vean.
Sin embargo, una instalación por defecto de ssh no es perfecta, y cuando se ejecuta un servidor ssh hay algunos pasos simples que pueden endurecer dramáticamente una instalación.
Use contraseñas/nombres de usuario fuertes
Una de las primeras cosas que notará si tiene ssh funcionando y expuesto al mundo exterior es que probablemente registrará los intentos de los hackers de adivinar su nombre de usuario/contraseña. Normalmente, un hacker buscará el puerto 22 (el puerto por defecto en el que escucha ssh) para encontrar máquinas con ssh en funcionamiento, y luego intentará un ataque de fuerza bruta contra él. Con contraseñas fuertes en su lugar, se espera que cualquier ataque sea registrado y notado antes de que pueda tener éxito.
Es de esperar que usted ya utilice contraseñas fuertes, pero si no lo está entonces trate de elegir contraseñas que contengan:
- Mínimo 8 caracteres
- Mezcla de letras mayúsculas y minúsculas
- Mezcla de letras y números
- Caracteres no alfanuméricos (por ejemplo, caracteres especiales como ! » £ $ % ^ etc)
Los beneficios de las contraseñas fuertes no son específicos de ssh, sino que tienen un impacto en todos los aspectos de la seguridad de los sistemas. Más información sobre las contraseñas se puede encontrar en la documentación de CentOS:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Si absolutamente no puede evitar que sus usuarios elijan contraseñas débiles, entonces considere usar nombres de usuario generados aleatoriamente o difíciles de adivinar para sus cuentas de usuario. Si los malos no pueden adivinar el nombre de usuario, no podrán forzar la contraseña. Sin embargo, esto sigue siendo la seguridad a través de la oscuridad y ser conscientes de la fuga de información de los nombres de usuario de cosas tales como el correo electrónico enviado desde las cuentas de usuario.
Desactivar los inicios de sesión de root
La configuración del servidor SSH se almacena en el archivo /etc/ssh/sshd_config. Para deshabilitar los inicios de sesión de root, asegúrese de tener la siguiente entrada:
# Prevent root logins:PermitRootLogin no
y reinicie el servicio sshd:
service sshd restart
Si necesita acceso de root, inicie sesión como un usuario normal y utilice el comando su.
Limitar los inicios de sesión de los usuarios
Los inicios de sesión de SSH se pueden limitar sólo a ciertos usuarios que necesitan acceso remoto. Si tiene muchas cuentas de usuario en el sistema, entonces tiene sentido limitar el acceso remoto sólo a aquellos que realmente lo necesitan, limitando así el impacto de que un usuario casual tenga una contraseña débil. Añada una línea AllowUsers seguida de una lista de nombres de usuario separados por espacios en /etc/ssh/sshd_config:
AllowUsers alice bob
y reinicie el servicio sshd.
Desactivar el protocolo 1
SSH tiene dos protocolos que puede utilizar, el protocolo 1 y el protocolo 2. El protocolo 1, más antiguo, es menos seguro y debería deshabilitarse a menos que sepa que lo necesita específicamente. Busque la siguiente línea en el archivo /etc/ssh/sshd_config, descoméntela y modifíquela como se muestra:
# Protocol 2,1Protocol 2
y reinicie el servicio sshd.
Utilizar un puerto no estándar
Por defecto, ssh escucha las conexiones entrantes en el puerto 22. Para que un hacker determine que ssh se está ejecutando en su máquina, lo más probable es que escanee el puerto 22 para determinarlo. Un método efectivo es ejecutar ssh en un puerto no estándar. Cualquier puerto no utilizado servirá, aunque es preferible uno por encima de 1024. Mucha gente elige el 2222 como puerto alternativo (ya que es fácil de recordar), al igual que el 8080 se conoce a menudo como el puerto HTTP alternativo. Por esta misma razón, probablemente no sea la mejor opción, ya que cualquier hacker que escanee el puerto 22 probablemente también escaneará el puerto 2222 por si acaso. Es mejor elegir algún puerto alto al azar que no se utilice para ningún servicio conocido. Para hacer el cambio, añada una línea como esta a su archivo /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
y reinicia el servicio sshd. No te olvides de hacer los cambios necesarios en el reenvío de puertos en tu router y cualquier regla de firewall aplicable. Por ejemplo, en CentOS 7 (y superior) puede cambiar el servicio ssh de firewalld haciendo un duplicado de su archivo de servicio en /etc/firewalld/ y cambiando su línea de puerto:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Entonces cambia la línea del puerto en /etc/firewalld/services/ssh-custom.xml para que el puerto sea el mismo que en el archivo de configuración de ssh:
<port protocol="tcp" port="2345"/>
Por último, elimine el servicio ssh, añada el servicio ssh-custom y recargue firewalld para que el cambio surta efecto:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
O en CentOS 6, añade una regla iptable para abrir el nuevo puerto ssh:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
No olvides cerrar también el puerto antiguo.
En CentOS 6 y superiores también debes actualizar selinux, etiquetando correctamente el puerto elegido, de lo contrario se impedirá el acceso a sshd. Por ejemplo:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Debido a que ssh ya no está a la escucha de conexiones en el puerto estándar, tendrá que decirle a su cliente en qué puerto conectarse. Usando el cliente ssh desde la línea de comandos, podemos especificar el puerto usando el interruptor -p:
$ ssh -p 2345 myserver
o si estás usando el protocolo fish en konqueror, por ejemplo:
fish://myserver:2345/remote/dir
Si estás pensando que esto suena como una molestia tener que especificar el puerto cada vez que te conectas, simplemente añade una entrada especificando el puerto en tu archivo local ~/.ssh/config:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Y el archivo ~/.ssh/config debe tener los siguientes permisos:
$ chmod 600 ~/.ssh/config
Filtrar SSH en el Firewall
Si sólo necesita acceso remoto desde una dirección IP (digamos desde el trabajo a su servidor de casa), entonces considere filtrar las conexiones en su firewall añadiendo una regla de firewall en su router o en iptables para limitar el acceso en el puerto 22 sólo a esa dirección IP específica. Por ejemplo, en iptables esto podría lograrse con el siguiente tipo de regla para iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
o usando firwalld (CentOS 7) utilizar rich-rules para permitir ssh sólo en un puerto específico. La dirección de origen puede ser una sola dirección o una dirección base con una máscara de bits:
SSH también soporta de forma nativa envoltorios TCP y el acceso al servicio ssh puede ser controlado de forma similar usando hosts.allow y hosts.deny.
Si no puede limitar las direcciones IP de origen, y debe abrir el puerto ssh globalmente, entonces iptables todavía puede ayudar a prevenir los ataques de fuerza bruta registrando y bloqueando los intentos repetidos de inicio de sesión desde la misma dirección IP. Por ejemplo, con iptables
La primera regla registra la dirección IP de cada nuevo intento de acceso al puerto 22 utilizando el módulo recent. La segunda regla comprueba si esa dirección IP ha intentado conectarse 4 o más veces en los últimos 60 segundos, y si no es así, se acepta el paquete. Tenga en cuenta que esta regla requeriría una política por defecto de DROP en la cadena de entrada.
No olvide cambiar el puerto según corresponda si está ejecutando ssh en un puerto no estándar. Siempre que sea posible, el filtrado en el firewall es un método extremadamente efectivo para asegurar el acceso a un servidor ssh.
Para los sistemas que utilizan el servicio FirewallD (CentOS 7 o superior), utilice firewall-cmd:
El primer comando elimina la regla de servicio más permisiva, el segundo instala una regla para aceptar sólo 4 conexiones en un minuto y registrar todas las conexiones.
Utilizar claves públicas/privadas para la autenticación
Utilizar claves encriptadas para la autenticación ofrece dos beneficios principales. En primer lugar, es conveniente, ya que no es necesario introducir una contraseña (a menos que cifre sus claves con protección de contraseña) si utiliza claves públicas/privadas. En segundo lugar, una vez que la autenticación de pares de claves públicas/privadas se ha configurado en el servidor, puedes desactivar por completo la autenticación por contraseña, lo que significa que sin una clave autorizada no puedes acceder, así que se acabaron los intentos de descifrar la contraseña.
Es un proceso relativamente sencillo crear un par de claves públicas/privadas e instalarlas para su uso en su servidor ssh.
Primero, crea un par de claves públicas/privadas en el cliente que utilizarás para conectarte al servidor (tendrás que hacerlo desde cada máquina cliente desde la que te conectes):
$ ssh-keygen -t rsa
Si no quieres que te sigan pidiendo una frase de paso (que es básicamente una contraseña para desbloquear una clave pública determinada) cada vez que te conectes, simplemente pulsa enter cuando te pidan una frase de paso al crear el par de claves. Tú decides si debes añadir o no la frase de contraseña para proteger tu clave cuando la creas. Si no proteges tu clave con una frase de paso, entonces cualquiera que acceda a tu máquina local tendrá automáticamente acceso ssh al servidor remoto. Además, el root de la máquina local tiene acceso a tus claves, aunque se supone que si no puedes confiar en el root (o el root está comprometido) entonces estás en verdaderos problemas. Cifrar la clave añade seguridad adicional a expensas de eliminar la necesidad de introducir una contraseña para el servidor ssh que sólo se sustituye por la introducción de una frase de contraseña para el uso de la clave. Esto puede simplificarse aún más mediante el uso del programa ssh_agent
Ahora establezca los permisos de su clave privada:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Copie la clave pública (id_rsa.pub) en el servidor e instálela en la lista authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Nota: una vez importada la clave pública, puedes borrarla del servidor.
y finalmente establecer los permisos de los archivos en el servidor:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Los permisos anteriores son necesarios si StrictModes se establece en sí en /etc/ssh/sshd_config (el valor predeterminado).
Asegúrese de que los contextos SELinux correctos se establecen:
$ restorecon -Rv ~/.ssh
Ahora cuando inicie sesión en el servidor no se le pedirá una contraseña (a menos que haya introducido una frase de contraseña cuando creó su par de claves). Por defecto, ssh intentará primero autenticarse usando claves. Si no se encuentran claves o la autenticación falla, entonces ssh volverá a la autenticación de contraseña convencional.
Una vez que haya comprobado que puede iniciar sesión con éxito en el servidor utilizando su par de claves públicas/privadas, puede desactivar completamente la autenticación por contraseña añadiendo la siguiente configuración a su archivo /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Preguntas frecuentes (FAQ)
Q: CentOS utiliza la versión X de OpenSSH y la última versión es la Y. La versión X contenía un grave fallo de seguridad, ¿debo actualizarla?
A: No. El proveedor de versiones anteriores tiene una política de backporting parches de seguridad de las últimas versiones en la versión de distribución actual. Mientras tenga las últimas actualizaciones aplicadas para su distribución de CentOS estará completamente parcheado. Vea aquí para más detalles de los parches de seguridad de backporting:
http://www.redhat.com/advice/speaks_backport.html
Q: ¿Cómo consigo que ssh permita la autenticación basada en clave sin contraseña entre máquinas que comparten directorios personales de usuarios por NFS?
A: SElinux bloquea el acceso de root a los directorios y archivos compartidos por NFS que no son legibles por el mundo por defecto y así sshd no puede leer los archivos de claves de los usuarios en ~/.ssh. Para habilitar el acceso, cambie la configuración de use_nfs_home_dirs ejecutando el siguiente comando como superusuario:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Enlaces
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html