WardtermClient SSH
IT
Scarica

Come condividere l'accesso SSH senza condividere la chiave privata

Chiedi a ogni persona la sua chiave pubblica e aggiungila al server: nel suo account, oppure come riga separata nel ~/.ssh/authorized_keys dell'account condiviso. La tua chiave privata non lascia mai il tuo dispositivo, i log mostrano quale chiave è stata usata e togliere una persona vuol dire cancellare una riga. Per un accesso temporaneo, aggiungi expiry-time= alla riga o firma un certificato SSH a breve durata.

Aggiornata il . Provato con OpenSSH 10.0 su Debian 13 in un container usa e getta: account per persona con install, un account condiviso con una riga per persona ed expiry-time (una riga scaduta è stata rifiutata), un certificato utente firmato con -V +8h e accettato tramite TrustedUserCAKeys, rimozione di una riga, usermod --expiredate e pkill.

Perché non condividere la chiave

Mandare a un collega la tua chiave privata, o la copia di una chiave di deploy che usano tutti, funziona il primo giorno e crea problemi dopo:

  • Il server vede una sola chiave, quindi i log non possono dire chi ha fatto cosa.
  • Quando una persona se ne va, l'unico modo per toglierla è una chiave nuova per tutti.
  • Ogni copia in un portatile, in una chat o in un backup è un posto in più da cui può uscire.

SSH è pensato per il contrario: ogni persona ha la sua coppia di chiavi, tiene la parte privata e distribuisce solo quella pubblica. Un server può fidarsi di quante chiavi pubbliche vuoi.

Un account per persona

La configurazione più pulita dà a ogni persona il suo account Linux. Chiedi la sua chiave pubblica, poi sul server:

sudo adduser --disabled-password --gecos "" bob
sudo install -d -m 700 -o bob -g bob /home/bob/.ssh
sudo install -m 600 -o bob -g bob bob.pub /home/bob/.ssh/authorized_keys

Su RHEL e sistemi simili usa sudo useradd -m bob per la prima riga. Aggiungi l'account al gruppo sudo o wheel solo se gli serve root, come spiegato in creare un utente con accesso SSH e sudo. Ogni comando è così legato a un nome, e i file mantengono il loro proprietario.

Più persone sullo stesso account condiviso

A volte tutti devono entrare con lo stesso utente, come deploy o l'utente predefinito di un'immagine cloud. In quel caso dai a ogni persona la sua riga nell'authorized_keys di quell'account, con un commento che la nomina:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGk3... alice@laptop
expiry-time="20261231" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJq8... bob@laptop

L'opzione expiry-time fa smettere di funzionare la riga di Bob dopo quella data, senza doversene ricordare. Altre opzioni limitano una chiave ad alcuni indirizzi o a un solo comando, vedi limitare una chiave SSH. Siccome ogni persona ha una chiave diversa, il log del server le distingue ancora tramite il fingerprint:

Accepted publickey for deploy from 203.0.113.25 port 51234 ssh2: ED25519 SHA256:vsze5ORPbYF/MMM4TTtuyy6yiEAYV1CcI4FOF0dV9wI

Elenca i fingerprint del file per sapere di chi è quella chiave:

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Accesso a breve durata con i certificati

Con molti server e cambi frequenti, modificare authorized_keys dappertutto stanca. Un'autorità di certificazione SSH risolve il problema: i server si fidano una volta della CA, e tu firmi la chiave pubblica di ogni persona per un tempo stabilito.

ssh-keygen -t ed25519 -f user_ca -C "team user CA"
ssh-keygen -s user_ca -I bob@example.com -n deploy -V +8h bob.pub

Così crei bob-cert.pub, valido otto ore come utente deploy. Su ogni server copia user_ca.pub in /etc/ssh/user_ca.pub e aggiungi una riga a sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Bob tiene bob-cert.pub accanto alla sua chiave privata ed entra come sempre. Quando scade, l'accesso finisce senza toccare nessun server. Tieni la chiave della CA offline o in un sistema dedicato, perché può firmare l'accesso a tutto. La configurazione completa è in i certificati SSH spiegati.

Togliere l'accesso

Per una riga di chiave, cancellala. Cancellare in base al commento è veloce; per una pulizia completa cerca per fingerprint, come mostrato in revocare una chiave SSH quando qualcuno se ne va:

sudo sed -i.bak '/ bob@laptop$/d' /home/deploy/.ssh/authorized_keys

Per un account personale, bloccalo in modo che non funzionino né chiave né password, poi chiudi tutto quello che è ancora in esecuzione:

sudo usermod --expiredate 1 bob
sudo pkill -KILL -u bob

Togliere una chiave non chiude le sessioni già aperte, quindi non saltare il secondo comando. Poi cambia ogni password, token o chiave condivisa che la persona conosceva.

Far vedere il tuo terminale dal vivo

A volte non serve un accesso ma un aiuto: qualcuno deve guardarti lavorare, o scrivere per un minuto. Su un server dove avete entrambi un account, tmux può condividere una sessione. Crea un gruppo apposta e avvia tmux su un socket che quel gruppo può raggiungere:

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob
tmux -S /tmp/pair new -s pair

Da un'altra finestra, apri il socket al gruppo e fai entrare Bob. tmux 3.3 e successivi rifiutano gli altri utenti finché non lo fai:

chgrp pair /tmp/pair
chmod 770 /tmp/pair
tmux -S /tmp/pair server-access -a bob
tmux -S /tmp/pair server-access -r bob

L'ultima riga mette Bob in sola lettura; toglila se vuoi che possa scrivere. Lui entra con tmux -S /tmp/pair attach -t pair. Quando avete finito, tmux -S /tmp/pair server-access -d bob lo toglie. Servono un account sul server per entrambi, e tutto quello che Bob scrive viene eseguito come te.

Password condivise e altri segreti

Alcune cose non si possono dividere per persona: un apparato di rete con una sola password di amministratore, la password root di un database, una chiave di deploy di un repository. Tienile in un gestore di password o in un vault condiviso dal team, non in chat o in una pagina wiki, così sai chi può leggerle. Quando qualcuno se ne va, cambia ogni segreto che poteva vedere, perché togliergli l'accesso al vault non cancella quello che ha già copiato.

Domande

Due persone possono usare la stessa chiave privata SSH?

Tecnicamente sì, ma il server non riesce più a distinguerle, e togliere l'accesso a una vuol dire cambiare la chiave a tutti. Dai a ogni persona la sua chiave.

È sicuro mandare una chiave pubblica per email o in chat?

Sì. Una chiave pubblica è fatta per essere condivisa. Solo la chiave privata, il file senza .pub, deve restare sul dispositivo del suo proprietario.

Come do accesso a qualcuno solo per qualche giorno?

Metti expiry-time="20261231" davanti alla sua chiave in authorized_keys, oppure firma la sua chiave come certificato con ssh-keygen -s e una validità come -V +3d. In entrambi i casi smette di funzionare da sola.

Posso far vedere il mio terminale a qualcuno senza dargli accesso?

Sì. Con tmux, un socket condiviso e server-access -r può guardare in sola lettura. Gli serve comunque un account sullo stesso server per collegarsi.

Fonti

Altro in Mettere in sicurezza un server

Tutte le guide