Introducción

Cando traballamos con sistemas remotos, nalgún punto ímonos atopar con conexións SSH ou con sistemas que nos leven a usar pares de claves. Ca súa parte pública e a privada. O recomendable nestes casos é usar unha clave por dispositivo, pero isto non sempre se cumpre. Podemos ter varias claves, por exemplo para separar o espazo laboral do privado. Pero neste caso, cómo facemos para xestionar varias claves no mesmo equipo?
Neste artigo pretendo dar unhas pautas de cómo podemos xestionar estas claves, cómo podemos escoller con cal conectar, etc.

Traballando cas claves SSH

Para este primer exemplo imos comezar tendo unha clave co seu par público-privado, ~/.ssh/id_rsa.pub e ~/.ssh/id_rsa. Neste caso é doado, xa sexa que queiramos facer unha conexión SSH ssh usuario@raspberry.local, coma que queiramos descargar algo de git git clone git@codeberg.org:codigomorrazo/repo.git, esta será a clave que se escollerá por defecto. Sen ter que facer nada especial no cliente.
Claro, aquí estamos asumindo que xa vinculamos a clave pública no servidor SSH ou no repositorio, isto último está explicado na segunda parte deste artigo Firmando commits con Gpg e integración con Codeberg.

Para amosar cómo copiar unha clave a un servidor remoto, precisamos acceso a ese servidor, mesmo con contrasinal. E nunha terminal executaríamos ssh-copy-id usuario@host -i ~/.ssh/id_clave. Con isto dicimoslle que queremos copiar a clave id_clave para usuario no host.
Se só temos a típica clave id_rsa, podemos omitir -i ~./ssh/id_clave, xa que a collerá por defecto. Hai outros xeitos, pero este é o máis sinxelo.

Unha vez comprobado que funciona, podemos desactivar o acceso por contrasinal. Para isto no ficheiro remoto /etc/ssh/sshd_config engadimos a liña PasswordAuthentication no. Tedes outras formas de copiar a clave no servidor na URL de referencia de DigitalOcean.

Pero que ocorre cando temos dúas ou máis claves no directorio .ssh ou se as nosas claves non teñen nomes habituais. Por exemplo, se a nosa clave fose ~/.ssh/id_persoal.pub e ~/.ssh/id_persoal. Deste xeito, se agora executásemos calquera dos comandos anteriores, teríamos un erro de permiso denegado.

Así que o primeiro será agregalo ao noso axente de autenticación. Para isto executamos ssh-add ~/.ssh/id_persoal. Podemos verificar a sua dición con ssh-add -l, que amosará un listado cas claves que agregadas.

Nota: En ocasións pode que nos dé o seguinte erro Could not open a connection to your authentication agent. Isto parece ser porque o sistema non identifica o id do axente. Isto soluciónase ao correr o comando eval "$(ssh-agent)"

Agora se tentamos volver clonar o repo, xa recoñecería a nosa clave.

Persistindo a configuración

O problema do xeito anterior é que en canto reiniciemos o equipo, teremos que volver engadir a nosa clave, volver a por o contrasinal, etc. Precisamos por tanto algo máis duradeiro.
Recurriremos por tanto a configurar SSH. Supoñamos por tanto que temos dous repos. O noso repo privado en Codeberg e a conta do traballo, xeralmente en GitHub.
Para utilizar distintas claves, primeiro borramos as que teñamos na sesión do noso axente de autenticación con ssh-add -D. Unha vez feito isto crearíamos o ficheiro ~/.ssh/config co seguinte contido:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_traballo
  IdentitiesOnly yes
 
Host codeberg.org
  HostName codeberg.org
  User git
  IdentityFile ~/.ssh/id_persoal
  IdentitiesOnly yes

Agora se fixésemos algunha operación contra estes servizos, cada un utilizaría a clave que lle estamos a indicar. Algún preguntarase agora que ocorre se a miña conta persoal e a do traballo, van contra GitHub. Nese caso podemos facer a configuración do xeito seguinte:

Host github-traballo
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_traballo
  IdentitiesOnly yes
 
Host github-persoal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_persoal
  IdentitiesOnly yes

Agora cando quixésemos clonar algo do repo que toque chamaríamos ao comando indicando o nome do host, deste xeito git clone git@github-traballo:empresa/repo.git ou git clone git@github-persoal:codigomorrazo/repo.git.

Nota: se tivésemos o repo nun server propio, que non utilice o porto por defecto, podemos engadir a entrada Port na configuración, co número de porto a usar.

Host meu-gitea
  HostName gitea.local
  Port 2222
  User git
  IdentityFile ~/.ssh/id_traballo
  IdentitiesOnly yes

Tamén temos a opción de facer configuración para un repositorio específico. Simplemente entrando na carpeta do proxecto e configurandoo con este comando git config core.sshCommand 'ssh -i ~/.ssh/id_persoal'.
Aquí o que lle estamos a indicar a git é que queremos que na configuración nos engada a entrada core.sshCommand co valor entre as comillas. O fragmento ssh -i é o comando ssh co parámetro para indicar, que clave ten que usar, que é a que hai a continuación.

Con isto xa teríamos distintas formas de que un cliente poida xestionar distintas claves.

Servidor

Todo isto está moi ben, pero e cando ocorre o caso contrario. Cando é o servidor o que ten que aceptar distintas claves para un mesmo usuario. Digamos que temos un servidor co usuario CodigoMorrazo configurado. Pero non queremos ter a nosa clave desperdigada por distintos equipos e tampouco queremos ter habilitado o acceso con contrasinal. O ideal sería que puidésemos configurar varias destas claves. Así no caso de que algunha fose comprometida, poderíamos anulala e seguir accedendo co resto mentres rexistramos unha nova clave.

Pois isto é posible e ademais doado de facer. O único que temos que facer é sacar o contido da clave pública que queiramos, por exemplo con cat.
cat ~/.ssh/id_rsa.pub.
E engadilo no ficheiro ~/.ssh/authorized_keys, na liña seguinte, no servidor. As claves que estean presentes nese arquivo, serán aceptadas polo usuario ao conectarse. Así por exemplo se tivésemos un móbil, un portátil e un sobremesa, cada un ca sua clave; só precisaríamos engadir as tres claves a /home/codigomorrazo/.ssh/authorized_keys. A partir dese momento teremos acceso.

No meu caso cando o fixen tiña activo o acceso con contrasinal, para non ter que andar a mover as claves doutro xeito. Unha vez copiadas todas desactivei este acceso por contrasinal.

Conclusión

O uso das claves SSH para configurar accesos está moi extendido e é un xeito de acceso moi cómodo. Polo que non é raro que nos atopemos en ambos escenarios, clientes con varias claves ou servidores que teñen que admitir distintas claves de acceso.
Con este mini artigo quedan cubertas as bases para o acceso.

Referencias

Freecodecamp: https://www.freecodecamp.org/news/how-to-manage-multiple-ssh-keys/
DigitalOcean: https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
RedHat: https://www.redhat.com/sysadmin/manage-multiple-ssh-key-pairs