Com crear i fer servir claus SSH per autenticació segura
Configurar claus SSH pot semblar fàcil quan només necessites entrar en un servidor una vegada. Però en entorns amb diversos servidors, diferents màquines, contenidors, pipelines o scripts automatitzats, hi ha decisions importants que s’han de tenir en compte.
1. Clau RSA, ECDSA o ed25519?
Fa anys, RSA del 2048 bits era l’estàndard. Avui, ed25519 és l’elecció recomanada en la majoria de situacions:
- Genera claus més curtes per a missatgeria (el fingerprint continua sent llegible).
- És més ràpida per signar i verificar.
- Té resistència criptogràfica moderna.
A més, OpenSSH la suporta des de la versió 6.5. El format minimalista evita complicacions com el salt de línia incorrecte o errors de truncat. RSA continua sent útil si necessites interoperabilitat amb sistemes antics: algunes biblioteques de Java més velles no suporten ed25519. En aquest cas, generar una RSA de 3072 bits ofereix un punt mitjà raonable.
Recomanació pràctica:Si tots els sistemes parlen OpenSSH modern, crea claus ed25519. Fes servir RSA 3072 només si tens servidors o eines que no ho entenen.
2. Generant i protegint la clau
Per a generar una clau amb comentari útil:
ssh-keygen -t ed25519 -C "cognom@la-teva-màquina.local" -f ~/.ssh/id_ed25519- -C col·loca un comentari que després apareix a authorized_keys, el que serveix per a identificar on es va generar aquesta clau.
- No facis servir noms com id_rsa; si gestiones diverses claus per a diferents propòsits (producció, scripts, Git), fes servir noms descriptius com id_prod_ed25519, id_gitlab_ed25519.
Protecció: sempre afegeix una frase de pas. Si la teva clau usada per un pipeline sense push manual no pot fer servir passphrase, aquesta clau ha de tenir restriccions (Strong IAM rols, whitelists IP). Una clau sense passphrase no pot anar al teu portàtil, i menys en el teu home sense xifrat del disc.
Un exemple de configuració per a una clau sense passphrase només operativa en un host controlat:
ssh-keygen -t ed25519 -C "deploy-key" -f ~/.ssh/id_deploy_ed25519 -N ""Després es fixa chmod 600 ~/.ssh/id_deploy_ed25519, i s’emmagatzema al host de desplegament on no pot ser llegida per usuaris no autoritzats.
3. Configuracions ~/.ssh/config a tenir en compte
Sense un arxiu config, cada connexió SSH esdevé una línia llarga. Un exemple útil:
Host bastion-prod
HostName bastion.prod.example.com
User admin
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
ForwardAgent yes
Host *.app.example.com
User deploy
IdentityFile ~/.ssh/id_deploy_ed25519
IdentitiesOnly yes
ProxyJump bastion-prodAlguns punts clau:
- IdentitiesOnly yes impedeix que SSH intenti fer servir altres claus: evita errors quan l’agent té moltes identitats.
- ForwardAgent yes només on calgui, no per defecte. Si no necessites que la teva clau local faci servir ssh-agent al destí, millor deixar aquesta opció fora.
- ProxyJump (o ProxyCommand) evita crides amb nc manual.
Aquestes configuracions milloren la claredat i redueixen el risc d’ errors en scripts CI que depenen de SSH.
4. Distribució de claus: ssh-copy-id i alternatives
Per a clonar la clau pública al servidor:
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@hostper darrere fa dues coses: verifica permisos i afegeix la clau a ~/.ssh/authorized_keys. Evita copiar i enganxar, prevén errors de format o permisos.
Permisos correctes al servidor:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysSi no tens ssh-copy-id, pots fer servir:
cat id_ed25519.pub | ssh admin@host 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'Aquesta línia crea el directori si cal, ajusta permisos i afegeix la clau en un sol pas.
5. Restriccions a authorized_keys
Afegir restriccions preveu abús si algú obté la clau pública. Per exemple, per a una clau de desplegament que només hauria de pujar arxius i no executar shells:
command="scp -t /var/www/",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA...== deploy-keyAmb això:
- command= restringeix el comandament permès (scp en aquest cas).
- no-pty evita que s’obri sessió interactiva.
- no-agent-forwarding, no-X11-forwarding limiten vectors d’atac.
- L’usuari fitxat només pot fer el que fixem.
Aquest tipus de restricció és clau quan diverses persones generen claus: el servidor imposa com es fan servir.
6. SSH Agent i Forwarding
SSH Agent estalvia temps en no demanar passphrase a cada connexió. Però establir ForwardAgent i en molts llocs pot permetre el rebot de credencials.
Una bona pràctica: només permet forwarding des del teu equip a màquines de trànsit (com bastions). Al fitxer config:
Host bastion-prod
ForwardAgent yes
Host *.app.example.com
ForwardAgent noAixí evites que el teu agent es propagui a entorns on no és necessari.
7. Afegir una capa amb ssh-agent bloquejable
Mantenir una clau desbloquejada tot el temps incrementa riscos. Lo pràctic: fer servir ssh-agent amb bloqueig temporal:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
# treballes durant el dia...
ssh-add -D
kill $SSH_AGENT_PIDO fer servir utilitats com keychain, que permet mantenir múltiples ssh-agent per sessió amb desbloqueig per terminal i conservació després de reinici.
8. Integració de claus SSH en pipelines CI/CD
En integració contínua, se solen fer servir claus sense passphrase. S’ ha de generar una clau específica, restringida només a l’ ús que es necessita. Després es guarda:
- com a GitLab CI/CD variable protegida,
- o com a secret a GitHub Actions.
Scripts de pipeline poden muntar la clau a ~/.ssh/id_deploy amb chmod 600 i definir en el repo:
before_script:
- mkdir -p ~/.ssh
- echo "$SSH_DEPLOY_KEY" > ~/.ssh/id_deploy
- chmod 600 ~/.ssh/id_deploy
- ssh-keyscan host >> ~/.ssh/known_hosts
deploy:
script:
- ssh -i ~/.ssh/id_deploy deploy@host 'deploy-script.sh'Important:
- Afegir l’ empremta del servidor a known_hosts per a evitar prompts interactius.
- Fer servir StrictHostKeyChecking =yes a scripts més controlats.
- Guardar la clau com a secret, no com a variable visible a pipelines públics.
9. Rotació i revocació
Quan una clau es deixa de fer servir, amb esborrar-la del servidor no n’hi ha prou. Per seguretat cal:
- Eliminar la clau de authorized_keys.
- Treure-la del ssh-agent o del keychain local.
- Revocar (si aplica) permisos als repositoris.
En entorns més controlats, convé registrar cada clau amb el seu propòsit, data de creació, usuari, i cicles de rotació (ex.: cada 180 dies). Un script automàtic pot revisar els comentaris a les claus públiques (# user@host date) per a generar un report.
10. SSH Config i múltiples identitats per a Git
Quan treballes amb diversos projectes Git que requereixen diferents claus SSH (GitHub, GitLab, servidors interns), cal configurar config amb cura:
Host github.com-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_github_personal
Host github.com-work
HostName github.com
User git
IdentityFile ~/.ssh/id_github_work
Host gitlab.internal
HostName gitlab.internal
User git
IdentityFile ~/.ssh/id_gitlabDesprés a cada repo, s’ajusta la URL remota:
git remote set-url origin git@github.com-work:org/repo.gitSi oblides això, ssh farà servir la teva clau personal per defecte i fallarà o demanarà passphrase.
11. Fer servir certificats SSH amb CA interna
A infraestructures amb molts servidors es pot fer servir una autoritat de certificació per a SSH. Se signa la clau d’ usuari i es verifica en el servidor sense emmagatzemar la clau pública en authorized_keys. Configurar això pot estalviar manteniment en estructures grans.
Procés general:
- Es genera clau CA (ca_key, ca_pub).
- Els user keys se signen:
ssh-keygen -s ca_key -I user@domain -n username -V +52w user.pub- Al servidor, a sshd_config:
TrustedUserCAKeys /etc/ssh/ca_pub
AuthorizedPrincipalsFile /etc/ssh/principals/%u- I a /etc/ssh/principals/alice s’escriu alice.
Això permet revocar claus revocant la seva entrada a CA o expirant el certificat. Ideal en entorns corporatius o amb alta rotació.
12. Resoldre errors comuns
- Bad owner or /home/user/.ssh/authorized_keys: ocorre quan el directori o l’arxiu té permisos particulars (chmod 700 ~/.ssh i chmod 600 ~/.ssh/authorized_keys ho solucionen).
- Too many authentication failures for user: el teu ssh-agent ha ofert diverses claus. Afegir IdentitiesOnly yes al Host redueix el problema.
- Host key verification failed: si el host ha canviat d’IP o es s’ha reinstal·lat, known_hosts el rebutja. Solució: eliminar l’ entrada antiga.
- No supported authentication methods available: succeeix si actives només PubkeyAuthentication al servidor, però la clau no està ben instal·lada o la config local no la selecciona. Revisa ssh -vvv.
13. Checklist del procés
Si necessites recordar-ho o automatitzar-lo, aquest resum pot servir:
- Generar clau: ssh-keygen -t ed25519 -C “user@host” i triar passphrase.
- Configurar ~/.ssh/config amb Host, IdentityFile i IdentitiesOnly.
- Copiar clau al servidor: ssh-copy-id -i ….
- Aplicar permisos correctes en servidor.
- Provar connexió i depurar amb -vvv.
- Si és clau sense passphrase (deploy), restringir a authorized_keys.
- Bloquejar l’ accés a l’ agent amb límits de forwarding.
- Configurar rotació: data, propòsit i eliminació revisada.
- Automatitzar pipeline: afegir la clau a CI com a secret, afegir host a known_hosts.
- Resoldre errors típics.
- Opcional: integrar CA SSH per a certificats signats.
Crear, fer servir i mantenir claus SSH ben configurades evita problemes d’accés, redueix superfície d’atac i permet automatitzar tasques sense esforç manual. Les correccions de permisos, la configuració adequada d’ identitat múltiple i la protecció de claus de desplegament marquen la diferència entre un entorn sanament dissenyat i un ple de sorpreses.
