Recordemos como se establece una autentificación por clave pública-privada. La generación de una pareja de claves pública-privada se realiza ejecutando en el cliente ssh-keygen:
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx user@machine
En esta ocasión no indicamos passphrase.
Las claves generadas por ssh-keygen
se almacenan por defecto en ~/.ssh/
,
quedando el directorio así:
$ ls -l total 12 -rw------- 1 user user 883 2005-08-13 14:16 id_rsa -rw-r--r-- 1 user user 223 2005-08-13 14:16 id_rsa.pub -rw-r--r-- 1 user user 1344 2005-08-04 02:14 known_hosts
Los ficheros id_rsa
e id_rsa.pub
contienen respectivamente
las claves privada y pública. El
fichero known_hosts
contiene
la lista de las claves públicas de las máquinas
reconocidas.
Estas son alguas de las opciones que admite ssh-keygen
:
-b 2048
establece el número de bits en la clave a 2048. Por defecto es 1024.
-f mykey
establece el nombre del fichero de clave: mykey
y mykey.pub
.
Si se omite, pregunta
-N passphrase
la passphrase a utilizar. Si se omite, pregunta
-C comentario
el comentario a añadir en la correspondiente
línea de la clave pública. Si se omite es username@host
:
ssh-dss AAAAB3N... pepe@machinon
-p
puede ser usada para cambiar la passphrase de una determinada identidad:
pp2@europa:~/.ssh$ ssh-keygen -p -f id_dsa Key has comment 'id_dsa' Enter new passphrase (empty for no passphrase):o bien:
ssh-keygen -p -f mykeyfile -P mysecretpassword -N mynewsecretpassword
-c
:
ssh-keygen -c -f mykeyfile -P mysecretpassword -C 'my new comment'
Es posible generar el fingerprint de una clave pública usando la opción -l
:
$ ssh-keygen -l -f mykeyfile.pub
Ya vimos que cuando nos conectabamos a un host por primera vez via ssh obteníamos un mensaje como:
teide:~$ ssh teide The authenticity of host 'teide (134.2.14.48)' can't be established. RSA key fingerprint is 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35. Are you sure you want to continue connecting (yes/no)?
Normalmente respondemos yes
y entramos nuestra clave.
¿Cómo podemos comprobar que el fingerprint es auténtico?
¿Donde están los ficheros de claves del servidor?
Normalmente en el directorio /etc/ssh/
.
teide:~$ ls /etc/ssh/*key* /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_key.pub /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_key /etc/ssh/ssh_host_rsa_key.pub
Este servidor tiene tres claves.
Sólo el root puede leer las privadas,
pero las públicas tienen permisos de lectura.
En el mensaje anterior, el cliente ssh
muestra el fingerprint esperado.
Podemos obtenerlo con:
teide:~$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 2048 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35 /etc/ssh/ssh_host_rsa_key.pub
El primer número (2048) es la longitud en
bits de la clave. El segundo 9e:1a:...:fd:35
es la huella, el último /etc/ssh/ssh_host_rsa_key.pub
es el nombre del fichero con la clave pública.
El método seguro es contactar al administrador para obtener la huella (se supone que el administrador la guardó en lugar seguro) en vez de utilizar un canal que pueda estar comprometido.
Ahora se debe copiar la clave pública al servidor,
al fichero ~/.ssh/authorized_keys
.
El fichero authorized_keys
es el fichero que contiene las claves públicas utilizadas durante el proceso
de autentificación pública.
Para la copia se utiliza el comando ssh-copy-id:
$ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine1 $ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine2
ssh-copy-id es un script que se conecta a la máquina
y copia el archivo (indicado por la opción -i
) en
~/.ssh/authorized_keys
, y ajusta los permisos de forma adecuada:
~/.ssh
~/.ssh/authorized_keys
StrictModes
(que suele ser la opción por
defecto):
root@server:/etc/ssh# grep -i strictmode * sshd_config:StrictModes yes
Si se desea publicar la clave en un cierto número de máquinas que comparten la misma clave es posible (pero no recomendable) hacerlo usando el programa sshpass con un comando como este:
$ for i in host1 host2 ... hostN; do sshpass -pmipassword ssh-copy-id -i .ssh/identity $i; done
Si no se dispone del programa ssh-copy-id
se puede realizar una
copia manual a la máquina remota del fichero conteniendo la clave
pública (por ejemplo usando scp
o sftp)
y añadir su contenido al fichero ~/.ssh/authorized_keys
.
En la máquina servidor añadimos una línea en el fichero
~/.ssh/authorized_keys
que contiene exactamente la única
línea que estaba en el fichero en el que se guardó la clave pública
(id_rsa.pub
o filename.pub
o como se llamara).
Después de eso el fichero .ssh/authorized_keys
tendría
una línea parecida a esta:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK 5WgLMqmu38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX /COwHs+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bE wNf7heZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2O TKfY94c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0 LwFI+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== Este comentario describe la clave
excepto que he descompuesto la línea en varias líneas para hacerla mas legible.
La forma usual de completar el proceso
requeriría de dos autentificaciones:
una para la copia con scp
y otra para añadir la identidad
en el fichero .ssh/authorized_keys
y asegurarse de
los permisos.
Una forma de realizar el proceso con una sola autentificación es la siguiente:
europa:~/.ssh$ cat prueba.pub | \ ssh nereida "umask u=rwx,g=,o=; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"
La máscara por defecto umask u=rwx,g=,o=
se ha establecido de manera que los ficheros
creados tengan permisos rw-------
y los
nuevos directorios tengan permisos rwx-----
(véase la entrada de umask
en la Wikipedia).
Ahora la conexión debería funcionar sin necesidad de introducir la clave.
ssh -i ~/.ssh/filename remotehosto bien:
slogin -i ~/.ssh/filename remotehostUna vez que se ha establecido un esquema de autentificación automática es trivial ejecutar un comando en la máquina remota:
pp2@nereida:/tmp$ ssh remotename@machine uname -a Linux machine 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux
Si no funciona es posible que sea un problema de permisos en los ficheros. Los permisos correctos deben ser similares a estos:
$ chmod go-w $HOME $HOME/.ssh $ chmod 600 $HOME/.ssh/authorized_keys
Inténtelo de nuevo usando la opción -v
de ssh
:
pp2@nereida:/tmp$ ssh -v -v remotename@machine uname -a
u1
en m1
a otra cuenta u2
en la máquina m1
.
Intente ahora conectarse siendo el usuario u2
de m1
a la máquina rm
en la que situó la clave pública como usuario ru
:
u2@m1:~/$ ssh ru@rm
¿Sigue funcionando la autentificación automática?
u1
en m1
a otra cuenta w1
en una máquina distinta mw
.
Conéctese desde mw
a rm
en la que situó la clave pública como usuario ru
:
mw@w1:~/$ ssh ru@rm¿Funciona? ¿Como afectan los resultados a su percepción de la seguridad de las comunicaciones con
ssh
?
HOME
de usuario esta en un sistema de archivos
compartido. Genere (si no la ha echo ya) su pareja de claves privada y pública.
Publique la clave usando $ssh-copy-id
o bien - si $ssh-copy-id
no está
disponible - copiando la clave pública en
el fichero authorized_keys
. ¿Se obtiene autorización automática entre
dos máquinas cualesquiera de la red?