Llaves RSA con OpenSSH
Introducción:
¿Qué son las llaves RSA?
El sistema criptográfico con clave pública RSA es un algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye (en forma autenticada preferentemente), y otra privada, la cual es guardada en secreto por su propietario.
Una clave es un número de gran tamaño, que una persona puede conceptualizar como un archivo binario o como una cadena de bits.
La seguridad de este algoritmo radica en que no hay maneras rápidas conocidas de factorizar un número grande en sus factores primos utilizando computadoras tradicionales.
Extraído de Wikipedia (http://es.wikipedia.org/wiki/Claves_RSA)
Requisitos:
Pasos previos:
Se supone que ya tenemos instalado el servidor OpenSSH según éste tutorial, con usuario y contraseña.
- Programas que vamos a necesitar:
- Cliente SSH para windows: PuTTY
- Generador de llaves para windows: PuTTY Key Generator
- Manejador de archivos para windows: WinSCP
Procedimiento:
Nos conectamos mediante PuTTY al servidor e iniciamos una sesión SSH. Para eso abrimos el PuTTY:
Una vez conectados vamos a poner estos dos comandos:
< ssh-keygen -t rsa -b 2048
Eso nos generará una llave RSA de 2048 bits de longitud.
< cp ~/.ssh/id_rsa ~/
Esto nos copiará la llave pública a la carpeta home para facilitar el acceso a ésta más tarde y se le asigna permisos por que sino no podemos copiarla con el WinSCP.
Luego nos conectamos mediante WinSCP al servidor y nos copiamos la llave a alguna ubicación, por ejemplo, el escritorio.
Una vez logueados en el servidor, arrastramos la llave hasta alguna ubicación conveniente y de fácil acceso.
Luego abrimos el puttygen.exe; vamos a "file" -> "load" y seleccionamos la llave que acabamos de copiar (en la ventana que aparece, cambiar tipo "ppk" por "todos los archivos *.*") y nos va a pedir el passphrase que introducimos en el paso anterior.
Luego en key comment ponemos nuestra direccion de mail (esto es opcional) y presionamos sobre el boton "save private key". ahi la guardamos como un archivo .ppk.
Luego copiamos el contenido del text box que dice "public key for pasting into OpenSSH autorized_keys file" y vamos a la sesión de SSH y escribimos:
< nano ~/.ssh/autorized_keys
Con eso editamos el archivo "autorized_keys" (claves autorizadas) para el OpenSSH. Ahora se abrirá un archivo vacío y para pegar simplemente presionamos click derecho. Una vez pegado, comprobamos rápidamente que todo lo pegado se encuentre en una sola línea y no contenga "enters". Guardamos (ctrl + o) y salimos (ctrl + x).
Para agregar seguridad a la llave, vamos a cambiar los permisos del archivo y de la carpeta contenedora.
< chmod 600 ~/.ssh/authorized_keys < chmod 700 ~/.ssh
Luego debemos editar el archivo sshd_config:
< sudo nano /etc/ssh/sshd_config
y dejar como aparecen aquí las líneas resaltadas en negrita.
# Package generated configuration file # See the sshd(8) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 30 PermitRootLogin no StrictModes yes RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords PasswordAuthentication no
# Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM no
- Las directivas "RSAAuthentication", "PubkeyAuthentication" y "AuthorizedKeysFile" son para habilitar la autenticación mediante encriptación RSA, e indicar qué archivo posee las llaves autorizadas.
- La directiva "PasswordAuthentication" hay que deshabilitarla, pues ésta es la que permite el login utilizando usuario y contraseña, y si no la desactivamos, todo lo hecho carece de sentido
- Para que se hagan efectivos todos los cambios, reiniciamos el servidor OpenSSH utilizando:
< /etc/init.d/ssh restart
y luego salimos de todas las sesiones que tengamos abiertas.
- Ahora vamos al putty y a la izquierda, en la sección "SSH", subsección "auth" nos aparece para indicar el archivo llave:
Allí seleccionamos el archivo .ppk que guardamos cuando importamos la llave. Luego el procedimiento normal sólo que cuando escribamos la contraseña, ésta debe ser el passphrase de la llave y no la contraseña del usuario que estabamos ingresando hasta ahora.
FAQ:
P) El servidor muestra un mensaje que dice "server refused our key", ¿que hago?
R) Muy probablemente fallaste en la parte de copiar la llave en el autorized_keys, la copiaste mal, no la copiaste completa o algo ocurrió. No olvides modificar y reiniciar el servicio de OpenSSH luego de hacerlo.
P) ¿Cómo hago para saber mi key fingerprint?
R) Con el comando:
< ssh-keygen -l -f ~/.ssh/id_rsa.pub
P) Cuando trabajo con el scp desde un cliente GNU/Linux, me pide el passphrase cada vez que quiero hacer una operación, ¿cómo soluciono esta molestia?
R) Debemos utilizar los comandos ssh-agent y ssh-add. Sólo tienes que añadir esto a tu ~/.bash_profile (SIEMPRE DEL LADO DEL CLIENTE):
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi
Y se arrancará ssh-agent con el primer login.
Si algunas veces quedan procesos ssh-agent colgados, no tenés más que agregar esto al ~/.bash_logout :
if [ ${SSH_AGENT_PID+1} == 1 ]; then ssh-add -D
ssh-agent -k > /dev/null 2>&1
unset SSH_AGENT_PID
unset SSH_AUTH_SOCK
fi
Una vez que tenemos al ssh-agent ejecutándose en segundo plano, debemos agregar nuestra clave pública en su base de datos con el comando "ssh-add". El programa nos pedirá el passphrase una vez más:
$ ssh-add ~/.ssh/id_rsa Need passphrase for /home/faktorqm/.ssh/id_dsa Enter passphrase: $
P) ¿Cómo hago para restringir el acceso al SSH?
R) Una parte extremadamente importante, independiente de la configuración SSH, es permitir el acceso SSH solamente a redes o ip's conocidas. Para ello, utilizaremos los siguientes archivos:
/etc/hosts.deny /etc/hosts.allow
Lo más recomendable es prohibir el acceso SSH a cualquier ip o rango a través del archivo hosts.deny, y posteriormente permitir acceso a determinadas ip's o rangos en el archivo hosts.allow:
Hosts.Deny (Denegamos acceso total a SSH):
< cat /etc/hosts.deny > > # hosts.deny This file describes the names of the hosts which are > # *not* allowed to use the local INET services, as decided > # by the '/usr/sbin/tcpd' server. > # > # The portmap line is redundant, but it is left to remind you that > # the new secure portmap uses hosts.deny and hosts.allow. In particular > # you should know that NFS uses portmap! > > sshd: all
Hosts.Allow (Permitimos acceso a determinadas ip's):
< cat /etc/hosts.allow > > # hosts.allow This file describes the names of the hosts which are > # allowed to use the local INET services, as decided > # by the '/usr/sbin/tcpd' server. > # > sshd: 157.92.136.24
NOTA: Ésta última es dirección ip del administrador, pero también se puede poner una subred escribiendo, por ejemplo, 157.92.136.0/24
Navegación del libro
Más Vistas
| Views today | |
|---|---|
| UbuCon 2010 Día 1 | 7 |
| Ubucon 2010 Día 2 | 6 |
| Configurar Placa de Red | 6 |
| Actualizar de Grub a Grub2 | 4 |
| DHCP3-SERVER | 3 |






