LINUX GNU BLOG

Software libre y tecnología
Oct252014

Gestionar múltiples identidades ssh

El manejo de repositorios Git ha sido una asignatura que paulatinamente he ido superando y que ha pasado a ser parte integral de mi trabajo. Si alguna vez han trabajado con repositorios de software, de las primeras cosas que se suelen hacer en la configuración del mismo es la gestión de las claves ssh.

Tanto bitbucket, como github, como otros hostings de repositorios de software permiten autenticarse principalmente por https o por ssh. El 99% de las veces se elige ssh (https cuando estamos capados tras un cortafuegos) como método de autenticación pues, entre muchas razones, permite el uso de claves basadas en criptosistemas de clave pública. La principal ventaja de estos sistemas frente a las tradicionales contraseñas es que nos permiten acceder a distintos servicios y máquinas de forma transparente.

Poniéndonos en contexto, hace un par de meses tuve la necesidad de crearme otra cuenta en bitbucket para un proyecto especial. Si algún lector que se haya enfrentado a lo mismo  utiliza claves ssh para el acceso a sus repositorios,  habrá visto que es imposible utilizar la misma clave ssh en dos cuentas distintas de un mismo servicio. Esto es lógico pues dos cuentas (que a priori se supone representan dos “entidades distintas”) no pueden compartir una misma clave.
Es por esto que hoy vamos a ver como gestionar varias claves ssh; usando como ejemplo la cuenta en el repositorio git de bitbucket.


Creando Clave SSH

Por si no lo han hecho nunca o por si no se acuerdan de como iba la historia, el comando ssh-keygen nos permite generar las identidades ssh de una forma sencilla. El siguiente es un ejemplo usando las opciones por defecto:

ssh-keygen -t rsa -b 2048 -C "Nueva identidad" -N "" -f /home/usuario/.ssh/miclave

-t rsa: Algoritmo de cifrado usado en la generación de la clave; en este caso rsa.

-b 2048: Número de bits de la clave a crear.

-C “Nueva identidad”: Simple comentario que sirve para identificar la clave entre todas las que tengamos almacenadas.

-N “”: De esta forma indicamos al comando que no queremos poner una contraseña a la llave.

-f /home/usuario/.ssh/miclave: Este parámetro, como se puede deducir es para indicar al comando el directorio de salida.

Al ejecutar el anterior comando, tendremos en el directorio que le hemos indicado dos nuevos ficheros, miclave  y miclave.pub que corresponden con la clave y clave respectivamente.

Siguiendo el hilo de la historia con la segunda cuenta en bitbucket, nos tocaría subir la clave pública a esta cuenta para poder operar con los repositorios que creásemos en ella. Una vez hecho,  si intentamos, por ejemplo, clonar un repositorio de esta 2ª cuenta, veremos muy probablemente que git nos suelta un permiso denegado parecido al siguiente:

git clone git@bitbucket.org:usuario/repo_chorra.git
Cloning into 'repo_chorra'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

En principio lo que deducimos de la anterior salida es que nos han denegado el acceso al repositorio por problemas relacionados con la clave pública. Fuah! Aunque nos apunta hacia el origen del problema, la cosa no queda muy clara.

Para averiguar realmente que pasa con la clave pública vamos a ejecutar un comando que sirve precisamente para diagnosticar posibles problemas  de comunicación entre nosotros y el servidor del repositorio.

ssh -T -vv git@bitbucket.org

Esto nos va a soltar una burrada de líneas, pero lo importante es que nos fijemos  de entre todo, en aquellas líneas iguales a las siguientes:

...
debug2: key: /home/usuario/.ssh/id_dsa ((nil)),
debug2: key: /home/usuario/.ssh/id_ecdsa ((nil)),
debug2: key: /homeusuario/.ssh/id_ed25519 ((nil)),
...
Permission denied (publickey).

Por defecto, ssh busca en /etc/ssh o en el directorio .ssh de nuestro home las claves privadas con los nombre que aparecen en el fragmento de salido que acabamos de ver. Si nos fijamos vemos que las tres líneas  terminan con un nil; esto quiere decir que ssh no ha encontrado ninguno de los candidatos de clave privada por defecto salvo seguramente ‘id_rsa’ que será la clave privada que teníamos de nuestra primera cuenta en bitbucket. Lo que desde luego no aparece por ningún lado es la clave que generamos al principio, miclave, que es la que necesitamos ahora mismo.

Para que ssh sea capaz de ver la luz y encontrar la clave privada que case con la clave pública que hemos subido a bitbucket tenemos que crear o editar el archivo config en el directorio .ssh de nuestro home.

Añadiendo identidades al fichero de configuración

Probablemente el fichero config no exista, así que lo creamos e insertamos la siguiente línea:

IdentityFile /home/usuario/.ssh/miclave

Si probamos a ejecutar el comando de diagnóstico, comprobaremos que ahora ssh es mágicamente capaz de encontrar la clave.

Digamos que esta es la forma sencilla de añadir las identidades al fichero de configuración. Siempre y cuando tengamos añadidas pocas claves, todo irá bien. Pero si resultase que somos developers de nivel 80 con eñecientas claves en el fichero podremos vernos en un aprieto; sencillamente porque ssh, por defecto, tiene un número de intentos permitidos de acceso. Teniendo más claves que máximo de intentos permitidos, podemos vernos sin poder acceder a nuestro servidor o repositorio.

A continuación vamos a ver como solucionar esto.

Añadiendo identidades al fichero de configuración (versión mejorada)

El problema que teníamos con la versión anterior es que ssh podía excederse en el número máximo de intentos de acceso. Esto se debe a que ssh prueba secuencialmente las identidades añadidas en el fichero de configuración.

Para solventar esto vamos a encapsular la línea anterior de la siguiente forma:

Host miclave.bitbucket.org
HostName bitbucket.org
PreferredAuthentications publickey
IdentityFile /home/usuario/.ssh/miclave

Al haber añadido estas tres líneas, hemos modificado un poco el mecanismo para acceder al repositorio.

Usando nuevamente el comando de diagnóstico, vamos a modificarlo un poco para que se ajuste a la nueva información del archivo de configuración:

ssh -T git@miclave.bitbucket.org #Sí quito el parámetro -vv porque no necesitamos la verborrea para ver que funciona

Si observamos vemos que la clave del asunto está en cambiar el hostname, es decir, bitbucket.org por la línea de host del fichero de configuración.

Con este último paso ya tenemos funcionando el mecanismo de control de múltiples identidades ssh.

Podría extenderme mucho más pero prefiero que los comentarios me guíen para dar explicaciones, editar el post o crear uno nuevo si se tercia.

Saludos y ¡a comentar!


Interesante artículo sobre Criptografía de clave pública con ssh

Artículo de Wikipedia sobre Criptografía asimétrica

Política de comentarios

Dada la importancia de los comentarios como espacio de participación, te pedimos por favor que leas detenidamente y cumplas con las siguientes normas de participación.

4 respuestas para “Gestionar múltiples identidades ssh

Gestionar múltiples identidades ssh | lugclon.org

[…] Fuente: http://linuxgnublog.org/gestionar-multiples-identidades-ssh […]


Ymir Camilo Acosta Rodríguez

Excelente, no sabia como utilizar más de una llave para servidores diferentes! Gracias.


Hector Zapata

No sé qué sucede, hice el procedimiento tal cual lo muestra el contenido, pero me sigue apareciendo el mensaje de “Permission denied (Public key ……)”. A qué se debe???

Ayuda por favor….


Hugo J. H.

Puedes copiar y pegar la salida del comando “ssh -T -vv git@bitbucket.org” en un pastebin y copiar el enlace aquí.
Si nunca has usado pastebin es muy fácil de usar:
1.- Accedes a http://pastebin.com/
2.- Copias y pegas el log del comando en el recuadro que pone ‘New Paste’
3.- Le das a ‘Create new paste’ y eso te dará un enlace que es el que tienes que copiar aquí.

Saludos,
Hugo


Deja un comentario

Tu dirección de correo electrónico no será publicada.