Tutorial acerca de este magnífico protocolo que empezó sus andanzas en 1997, ofreciendo una gran variedad de herramientas que destacan por su seguridad, al ser muy extenso lo dividiré en varias entradas tratando de cubrir lo más importante tanto al nivel de cliente como servidor.
SSH se suele utilizar para iniciar una sesión en una máquina remota, donde poder ejecutar órdenes, pero también permite la tunelización, el reenvío de puertos TCP de forma arbitraria y de conexiones X11; también se pueden realizar transferencias de archivos usando protocolos SFTP o SCP asociados.
Podemos ver que su gran atractivo es la se característica más que suficiente para desplazar al antiguo protocolo TELNET el cual carece de cifrado de información, comprometiendo los datos incluso los credenciales de acceso.
El servidor SSH, ofrece por defecto el puerto TCP 22. Un cliente de SSH es utilizado, generalmente, para establecer conexiones a un servidor sshd que acepta conexiones remotas. Ambos se encuentran comúnmente en los sistemas operativos más modernos, incluyendo Mac, Linux, Solaris y OpenVMS.
El soporte para windows de su versión Servidor se espera sea liberada este año de manera oficial mientras que a nivel de clientes ofrece una gran variedad de opciones destacando a PuTTY sobre los demás.
1. Instalar Secure Shell SSH
En casi todas las distribuciones su versión cliente viene preinstalada mientras que su versión server está disponible por repositorio su instalación debería ser muy sencilla.
sudo apt-get install openssh-server
sudo yum install openssh-server
pacman -Syu openssh
Verificamos que esté corriendo con:
curl localhost:22En caso de correr de manera correcta debería arrojar:
[color=#696969]
[/color]
Utilizando el cliente podemos conectarnos al servidor que puede ser remoto incluso si tenemos las dos versiones conectarnos de manera interna usando localhost.
La manera más básica de conectarnos sería:
ssh usuario@direcciondelhostEn caso de conectarnos internamente sería:
ssh usuario@localhostTenemos una gran variedad de opciones al momento de conectar explicaré unas muy útiles, puedes listar todas sus opciones con:
man sshA continuación os las mostramos:
Nos conectaremos al servidor prueba.solvetic.com con el usuario jcarrillo utilizando una llave privada diferente ubicada en nuestro folder /home/jcarrillo/llaves-aws usando el puerto 8022 de nuestro instancia en AWS.
Ejemplo → ssh -C -i “~/llaves-aws/” -p 8022 -l jcarrillo prueba.solvetic.comComo vemos es una herramienta extensa pero muy completa que merece más entradas para poder abarcar sus funciones necesarias para cualquier Sysadmin de nivel intermedio o Profesional.
Ahora pasamos a su configuración a nivel cliente-servidor, generar llaves públicas y privadas, el uso de port forwarding en situaciones reales, redirección del Servidor X por medio de X11 Forwarding, el uso scp, sftp , ssh-agent entre otras.
2. Securizar servidor SSH
Seguimos con OpenSSH centrándonos en securizar nuestro Servidor SSH, para evitar todo tipos de Ataques que puedan comprometer nuestro Servidor. Todas estas configuraciones las haremos en el archivo sshd_config ubicado en /etc/ssh/ el cual podemos modificar con cualquier editor de texto en mi caso usar vim:
sudo vim /etc/ssh/sshd_configAhora vemos como modificarlo.
Dentro veremos un fichero de configuración típico basado en “opción valor” si alguna de las opciones no se encuentra por defecto debemos colocar la línea por completo en otros casos será sólo cambiar de 0 a 1 de No a Yes o descomentar una línea.
Es esencial cambiar el puerto por defecto a uno aleatorio muchos scripts están configurados a atacar este puerto, lo recomendable es cambiarlo en el rango de 1000 a 23000 procurando que el puerto no este usado por otro servicio.
Tampoco debemos usar puertos como el 2222, 8022 o 1022 son igual de comunes que el 22 y muchos scripts están configurados para atacarlos.
port 2345
Si tenemos SELINUX habilitado debemos de usar un comando adicional para permitir el acceso desde el exterior al nuevo puerto.
semanage port -a -t ssh_port_t -p tcp 2345 #Cambiando puerto 22 por Seguridad
Debemos asegurarnos que todas nuestras conexiones se realizan bajo el Protocol 2 el 1 tiene muchas vulnerabilidades.
Protocol 2
Buscar la sección “Authentication”. Sus dos primeras opciones son también importantes. La primera es el número de segundos que tendrá el usuario remoto para hacer login en tu máquina. Colocar ese valor a pocos segundos, no tardamos mucho en hacer login si sabemos la cuenta y la password.
De esta forma evitamos ciertos scripts que se aprovechan de ese tiempo. El valor típico en términos de seguridad es 30, aunque puede ser incluso menos.
LoginGraceTime 30
Esta es la opción más importante para ser víctima de un ataque, necesitan de 3 cosas:
- Usuario
- Puerto
- Contraseña
Si nos deshabilitamos el root ya tienen una al ser root un usuario común en todos los sistemas. Adicional a esto, este usuario puede causar estragos al tener todos los permisos habilitados.
PermitRootLogin no
Podemos controlar que usuario puede hacer login por medio de SSH e incluso colocar una cláusula para que se conecte solo desde cierta IP. Esto es similar a lo que ofrece AWS para conectarnos a sus instancias.
AllowUsers fulanito@83.45.258.21
Es importante permitir el acceso a solo usuarios que necesiten acceso remoto y si es posible limitarlos a una IP conocida.
Si colocamos mal la contraseña el servidor nos da varios intentos para volver a ingresarla, esto debemos limitarlo o puedes ser víctima de un script de fuerza bruta, podemos colocarlo a 2 o 3 veces.
MaxAuthTries 2
Esto puede variar dependiendo del uso que le des al servidor, pero lo ideal es tenerlo controlado, basta con añadir el total de usuarios permitidos por SSH.
MaxStartups X
Después de realizar todos los cambios en nuestro archivo debemos de reiniciar nuestro servicio de sshd, Puede variar dependiendo del gestor de servicios.
systemctl restart sshd
service restart sshd
Todos estos cambios añaden un nivel extra de Seguridad pero debemos de tener presentes:
- Usar contraseñas alfanuméricas.
- Usar Autenticación por Llaves Públicas/Privadas cuando sea posible.
- Complementar la Seguridad con SELINUX y Firewalls.
- Controlar el acceso a qué usuarios necesitan entrar remotamente.
Autenticar Llaves Públicas / Privadas SSH
En la actualidad usar Llaves SSH es un requisito indispensable, esta autenticación es muy usada por los Administradores para automatizar tareas entre varios servidores e incluso es usada por desarrolladores para acceder a SCM como GIT, GITHUB, GITLAB entre otros.
Ofrece una gran seguridad y la posibilidad de crear Tareas Automatizadas basadas en scripts como un Respaldo o Replicar cambios a varios nodos a la vez.
Al usar una llave SSH (pública y privada), pueden conectarse fácilmente a un servidor, o a múltiples servidores, sin tener que ingresar un password cada vez. Es posible configurar tus llaves sin una frase-de-paso, sin embargo eso sería imprudente, si alguien obtiene tu clave, podría usarla. Hablaremos de cómo generar Llaves, distribuirlas, y usar ssh-agent para obtener mayor Seguridad.
Ante todo asegurarse de tener OpenSSH instalado no hace falta, el servidor solo el cliente.
Empezamos por Generar una llave del Tipo DSA con una seguridad 1024 bits, más que suficiente aunque puedes ir más allá y generar una llave del tipo RSA con un tope de 4096.
ssh-keygen -b 1024 -t dsaNos pedirá la ubicación donde guardará las llaves por defecto ~/.ssh
Enter file in which to save the key (/home/test/.ssh/id_dsa)Luego preguntará por una frase por ahora no usaremos ninguna y la dejaremos en blanco y nos dirá que la llave se ha creado y nos refleja.
La imagen siempre será diferente se genera de manera aleatoria, luego si vamos al folder .ssh debemos de tener 2 archivos
id_dsa -----> Llave Privada (No la compartas con nadie es como tu TDC).
id_dsa.pub ----> Es la que compartimos para poder conectarnos.
En caso de querer compartir la llave pública en SCM o Chef, Puppet, Jenkins visualizamos el archivo de la llave pública lo copiamos y lo pegamos donde corresponde.
more id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef+ifR29v2IknXCFwefKK8jorSDiUEY/1F/yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s+fx+xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R+L22sV7GkCHPxAAAAFQCyF1Gdh3 Cap4xr/0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP+J44xDDn+03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB+bFNbP/2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP 1oXguj+OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq+UGNkee96D2by+2GAQ S7daieIKNmFer2hO/SBxzepMrWAiIUnUsP5irmYspkjGlQxP+hxw= test@solveticEn caso de querer compartirla para acceder a un servidor yo siempre recomiendo usar ssh-copy-id viene incluido en OpenSSH y es muy sencillo de usar:
ssh-copy-id user@remote-server-ip -i especifica la ubicación de la llave a usar.Hay otras formas como:
ssh user@remote-server-ip \ 'cat >> .ssh/authorized_keys2' < .ssh/id_dsa.pub
scp ~/.ssh/id_dsa.pub user@remote-server-ipA partir de ahora las llaves están conectadas y solo necesitar ingresar al host.
ssh -l user remote-server-ipEsta vez no pedirá ninguna contraseña y podemos usar scripts sin interacción.
La seguridad de las Llaves SSH se basa en nuestra llave privada que funciona como una tarjeta de acceso, pero en caso de que alguien robe nuestra llave podrá acceder a todos los lugares donde tengamos acceso. Pero al generar una passphrase podemos tener un nivel extra, no solo es necesario la llave si no introducir nuestra frase.
Esta vez crearemos una llave rsa con mayor seguridad configurando una frase.
ssh-keygen -b 4096 -t rsa -C “Llave con Passphrase” # -C Añadir un comentario.Al ser una frase podemos usar espacios puntos y caracteres especiales
ejemplo ---> Est@ es mi nuev@ llave con Fr@S3.Compartimos la nueva llave:
scp ~/.ssh/id_rsa.pub user@remote-server-ipEsta vez necesitamos la llave y el Passphrase pero introducirla varias veces es tedioso pero podemos complementarlo con ssh-agent debemos iniciarlo.
ssh-agentAñadimos nuestra llave
ssh-add Enter passphrase for /home/user/.ssh/id_rsa: #Introducimos la frase que hemos configurado.Ahora podemos conectarnos a cualquier servidor que use nuestra llave sin necesidad de ingresar nuestra passphrase.
Este método lo recomiendo si se está fuera de la intranet, cliente y servidor en distintos puntos de Internet, y no haremos uso de tareas automatizadas, sino que más bien nos conectaremos al servidor con propósitos de administración remota, lo mejor será indicar una contraseña o frase de contraseña muy larga (15 o más caracteres, mayúsculas, minúsculas, números y símbolos) a la llave pública.
De esta manera será prácticamente imposible ser hackeados por este método, ya que no solo el hacker tendrá que saber la contraseña sino que tendrá que tener un certificado público válido en el servidor para que pueda ser autentificado. (Claro suponiendo que el servidor nunca haya sido comprometido y esté completamente actualizado y con la mejor seguridad posible).
Estaré atento, me ha encantado este tutorial Jonathan