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.

Aprende a usar Putty

OpenSSH
OpenSSH (Open Secure Shell) es un conjunto de aplicaciones que permiten
realizar comunicaciones cifradas a través de una red, usando el protocolo SSH.
Fue creado como una alternativa libre y abierta al protocolo SSH, es el más usado
bajo Linux y será el que utilizaremos a los largo de las entradas.

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.

Debian, Ubuntu, Linux Mint y Derivadas

sudo apt-get install openssh-server

Centos, Rhel, Fedora

sudo yum install openssh-server

Arch-Linux

pacman -Syu openssh

Verificamos que esté corriendo con:

curl localhost:22

En caso de correr de manera correcta debería arrojar:

[color=#696969]

Conectándonos al Servidor

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@direcciondelhost
En caso de conectarnos internamente sería:

ssh usuario@localhost

Tenemos una gran variedad de opciones al momento de conectar explicaré unas

muy útiles, puedes listar todas sus opciones con:

man ssh

A continuación, os las mostramos:

Opciones man SSH

-C: Solicitar compresión de datos ahorrando ancho de banda o datos en caso de

estar por una red móvil.

-l: Especificar el usuario con el cual nos conectaremos.

-E: Crear un log file donde se desviará el standard error.
-F: Seleccionamos otro config file útil para servidores con opciones poco usuales.
-g: Necesario para hacer port tunneling.
-i: Elegimos el folder que usaremos para una llave privada alterna.
-K: Habilitar al utilizar GSSAPI credentials.
-n: Utilizarlo en conjunto con X11 de esta forma todo el log generado por la
aplicación se desvía a /dev/null.
-o: Necesario para utilizar opciones más avanzadas como ServerAliveInterval 30.
-p: Seleccionar un puerto diferente al 22 para conectarse al host.
-v: Muestra todos los pasos necesarios para establecer la conexión puedes
obtener aún más información con -vv -vvv.
-X: Necesario si queremos usar el X11 Forwarding.
-Y: Habilita el X11 Forwarding seguro.
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 nuestra instancia en AWS.

Ejemplo → ssh -C -i “~/llaves-aws/” -p 8022 -l jcarrillo prueba.solvetic.com

Como 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_config

Ahora vemos como modificarlo.

Modificar sshd_config

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.

Modificar Puerto 22
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

Usar por defecto Protocol 2

Debemos asegurarnos que todas nuestras conexiones se realizan bajo el Protocol

2 el 1 tiene muchas vulnerabilidades.

Protocol 2

Tiempo para introducir Credenciales

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

Deshabilitar Acceso Root

Esta es la opción más importante para ser víctima de un ataque, necesitan de
3 cosas:
1. Usuario
2. Puerto
3. 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

Habilitar Acceso controlado

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.

Configurar el número de Intentos errados

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

Número Conexiones Permitidas de Manera Simultánea

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.

SystemD

systemctl restart sshd

Upstart/Sysinit

service restart sshd

Todos estos cambios añaden un nivel extra de Seguridad pero debemos de

tener presentes:

1. Usar contraseñas alfanuméricas.

2. Usar Autenticación por Llaves Públicas/Privadas cuando sea
posible.
3. Complementar la Seguridad con SELINUX y Firewalls.
4. 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.

Generando Llaves sin Passphrase

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 dsa

Nos 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.

Compartir Llave Pública

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+if
R29v2IknXCFwefKK8jorSDiUEY/1F/yp0xao

mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s+fx+xQiW3mf3y4IX654O82SLGl7V
hh5UsvG8r8d8pV6R+L22sV7GkCHPxAAAAFQCyF1Gdh3

Cap4xr/0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP+J44xDDn+03anWgyoZq
SPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4

Hxo4Y5skKihnPMtB+bFNbP/2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiB
VVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP

1oXguj+OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNC
BIvCO3uQYOozyzNGBhqHE7FVq+UGNkee96D2by+2GAQ

S7daieIKNmFer2hO/SBxzepMrWAiIUnUsP5irmYspkjGlQxP+hxw= test@solvetic

En 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-ip

A partir de ahora las llaves están conectadas y solo necesitar ingresar al host.

ssh -l user remote-server-ip

Esta vez no pedirá ninguna contraseña y podemos usar scripts sin interacción.

Generar Passphrase y Asociar con ssh-agent

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-ip

Esta vez necesitamos la llave y el Passphrase pero introducirla varias veces es
tedioso pero podemos complementarlo con ssh-agent debemos iniciarlo.

ssh-agent

Añ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.e