SSH

Key Authentication

Si un servidor SSH es visible a través de Internet, en lugar de las contraseñas, se recomienda utilizar la autenticación mediante llave pública.

Con la autenticación mediante llave pública, cada equipo tiene una llave privada y cada equipo remoto de confianza una llave pública (un gran número con propiedades particularmente matemáticas).

La llave privada se mantiene en el equipo de confianza desde el cual hacemos ingreso, mientras que la llave pública se almacena en el archivo .ssh/authorized_keys dentro de todos los equipos a los cuales se necesita ingreso para iniciar sesión.

Cuando se ingresa a otro equipo, el servidor SSH utiliza la llave pública para “bloquear” los mensajes de una manera que sólo pueden ser “desbloqueados” con nuestra propia llave privada – esto significa que incluso el atacante más curioso le será muy difícil espiar, o interferir con nuestra sesión.

Passphrase

Como medida de seguridad adicional, los programas SSH pueden almacenar la llave privada en un formato de contraseña-protegida, de modo que si el equipo es robado o quebrantado, se puede tener un tiempo suficiente para desactivar nuestra llave pública, antes de que terceros puedan romper la contraseña e iniciar sesióon utilizando nuestra propia llave privada.

Bruteforce

Las llaves son mucho más difíciles de quebrantar mediante la fuerza bruta, o de suponer contraseñas simples, presentan longitud de llave amplia de la clave.

Key Pairs

La autenticación mediante llaves utiliza “dos llaves”, una llave “pública” que nadie pueda ver, y otra llave “privada” que sólo cada propietario pueda ver. Para lograr una comunicación segura con otro equipo, mediante la autenticación basada en llaves, se debe crear una llave pública para cada equipo que se necesite acceder, de la misma manera se debe copiar de manera segura la llave pública que le vamos a confiar.

mkdir ~/.ssh

chmod 700 ~/.ssh

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -P "" -q

-f

Define el nomnbre de archivo de la llave.

-q

Genera las llaves en silencio.

-P

Proporciona la contraseña-protegida vieja.

Transferir la llave cliente al equipo

La llave que hay que transferir al otro equipo de confianza es la llave pública. Si podemos ingresar a otro equipo a través de SSH mediante una contraseña, entonces sí se puede transferir nuestra clave RSA desde nuestro propio ordenador:

ssh-copy-id user@example

ssh-copy-id -i ~/.ssh/id_rsa.pub user@example.com

Si el directorio ~/.ssh sí existe en el equipo remoto:

cat ~/.ssh/id_rsa.pub | ssh user@example.com 'cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys_original_backup; cat >> ~/.ssh/authorized_keys'

cat ~/.ssh/id_rsa.pub | ssh user@example.com 'cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys_original_`date +%F_%T | sed 's/[:-]/_/g'`; cat >> ~/.ssh/authorized_keys'

Si el directorio ~/.ssh no existe en el equipo remoto:

cat ~/.ssh/id_rsa.pub | ssh user@example.com 'mkdir ~/.ssh; chmod 700 ~/.ssh; cat >> ~/.ssh/authorized_keys'

Una vez que hay confianza en la autenticación mediante llaves los comandos como: ssh, rsync y scp se pueden usar con o sin el archivo de identidad o llave privada.

SCP

scp ~/scp.txt user@example.com:~/scp.txt

scp ~/scp.txt user@example.com:~/scp.txt_`date +%F_%T | sed 's/[:-]/_/g'`

scp -o IdentityFile=/home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ~/scp.txt user@example.com:~/scp.txt

scp -o IdentityFile=/home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ~/scp.txt user@example.com:~/scp.txt_`date +%F_%T | sed 's/[:-]/_/g'`

ssh user@example.com 'ls -la ~/'

ssh -i /home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@example.com 'ls -la ~/'

RSYNC

Las opciones SSH son esenciales para correr Rsync en silencio:

rsync --timeout=30 -q -e "ssh -i /home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" ~/rsync.txt user@example.com:~/rsync.txt_`date +%F_%T | sed 's/[:-]/_/g'`

El fin

ssh user@example.com 'rm -rf ~/scp.txt*; rm -rf ~/rsync.txt*; ls -la ~/'