☰

¿Cómo organizar las claves SSH?

tag-icon • tag-icon ssh ssh-agent
¿Cómo organizar las claves SSH?

He estado creando múltiples claves SSH en Debian para diferentes cuentas (es decir, Digital Ocean, GitHub y Bitbucket), pero se está volviendo complicado muy rápidamente.

Al enumerar el contenido de mi carpeta .ssh, obtengo:

digOcn digOcn.pub github github.pub id_rsa id_rsa.pub

(Yo uso la id_rsaclave para Bitbucket).

Hago lo eval 'ssh-agent -s'que hago y luego "agrego" las claves así:

  • ssh-add ~/.ssh/github(y luego ingresando la frase de contraseña)

  • ssh-add ~/.ssh/id_rsa(y luego ingresando la frase de contraseña)

  • ssh-add ~/.ssh/digOcn(Cuando intento agregar digOcn, dice "Permiso denegado". No trato sudode evitar estropear algo y también porque las otras claves no lo requerían sudo).

Aquí está la parte confusa: actuar ssh-add -lme da esto:

2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/id_rsa (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 USER@COMPUTER_NAME (RSA)

Sí, agregué claves SSH en el pasado, pero no puedo volver sobre lo que hice. Probablemente por eso hay ambos./home/USER/.ssh/github y github.

¿Qué he hecho mal? ¿Cómo debería organizar mis claves SSH?

Respuesta1

En primer lugar, no hay nada de malo en utilizar claves diferentes para cuentas diferentes. Esto es bastante excesivo para los shells interactivos, pero existen razones legítimas para hacerlo cuando se trata de otros servicios no interactivos. Por ejemplo, hace unos años GitHub comenzó a permitir claves SSH más potentes, mientras que Bitbucket insistió en utilizar claves más débiles durante un tiempo más. La acción correcta en ese momento fue utilizar claves diferentes para acceder a GitHub y Bitbucket.

Otro ejemplo es rsync. Si está utilizando rsync, por ejemplo, implementar archivos en un servidor web, entonces probablemente desee claves SSH dedicadas para ello. Estos le permiten establecer permisos diferentes a los que normalmente usaría con su cuenta interactiva.

Volviendo a su pregunta sobre la administración de múltiples claves: SSH le permite configurar diferentes opciones para diferentes destinos. Para hacer eso necesitas editar un archivo ~/.ssh/configcomo este:

Host  bitbucket.org
    User                    hg
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/bitbucket

Host  github.com  gist.github.com
    User                    git
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/github

El archivo ~/.ssh/configdebe tener permisos 0600 (no recuerdo en este momento si SSH lo aplica o no, pero ciertamente no hace daño).

Por supuesto, también puedes usar el mismo mecanismo para shells interactivos, así que configura cosas como nombre de usuario remoto (si es diferente del local), puerto remoto, acorta el nombre de host, etc. Por ejemplo:

Host  sm
    Hostname                sphygmomanometer.example.com
    User                    human
    Port                    2222

Entonces puedes simplemente correr

ssh sm

en lugar de

ssh -p 2222 [email protected]

También se permiten comodines:

Host *
    ControlPath             ~/.ssh/ctl-%u-%r-%h-%p
    ControlMaster           auto
    ControlPersist          5m

Lea el manual para más detalles.

Por último, pero no menos importante:no"hacer la eval 'ssh-agent -s'cosa". Contrariamente a la creencia popular, esto tiene graves implicaciones para la seguridad. La forma correcta de hacerlo es así:

ssh-agent /bin/bash
ssh-add

(luego ingrese sus contraseñas clave cuando se le solicite). Eso es todo, no lo hagas llave por llave, ni de ninguna otra forma.

Esto ejecuta un nuevo shell en el que se cargan sus claves, y cuando desee revocar el acceso, solo utilice exiteste shell. Si "hace la eval 'ssh-agent -s'cosa", los agentes de autenticación permanecen ejecutándose mucho después de cerrar la sesión y pueden (y eventualmente se usarán) para acceso no autorizado.

Editar:Pruebe este pequeño experimento:

  1. eval $(ssh-agent -s)
  2. cerrar sesión o matar la terminal
  3. inicie sesión nuevamente o abra una nueva terminal
  4. pgrep ssh-agent

Nadie los elimina ssh-agent, permanecen ahí hasta el siguiente reboot, listos para ser utilizados por el malware más reciente.

información relacionada