Comando ssh-copy-id in Linux: registrare una chiave pubblica SSH
ssh-copy-id aggiunge la chiave pubblica SSH locale alle chiavi autorizzate dell’account remoto, preparando l’accesso con autenticazione a chiave pubblica. Il file privato rimane sul client: non va copiato sul server.
SSH significa Secure Shell. Per la prima registrazione devi già poter accedere all’account di destinazione con una password o un altro metodo autorizzato. Questo comando non aggira l’autenticazione né abilita da solo un account bloccato. Se manca un accesso iniziale, chiedi all’amministratore la procedura prevista.
Sintassi e preparazione
ssh-copy-id [options] [user@]hostControlla disponibilità e opzioni con man ssh-copy-id o ssh-copy-id -h: possono variare tra distribuzioni e implementazioni. L’assenza del comando non indica che SSH non supporti le chiavi; verifica il pacchetto previsto dalla tua distribuzione.
Servono una coppia di chiavi utilizzabile, l’account remoto corretto, il nome del server e la sua porta SSH. Se devi creare la coppia, segui la procedura di generazione e verifica con ssh-keygen. Negli esempi sostituisci alice, user e i domini dimostrativi con i tuoi dati; sono due varianti dello stesso procedimento, non due registrazioni obbligatorie.
Prima di autenticarti, verifica la chiave host del server tramite una fonte indipendente e affidabile. Non accettare automaticamente una chiave nuova o cambiata. La chiave host identifica il server; la chiave pubblica che stai registrando autorizza invece l’utente.
Controllare, visualizzare e registrare la pubblica
Controlla il file e l’impronta. Il suffisso .pub è una convenzione, non una garanzia sul contenuto: verifica di aver scelto davvero la pubblica corretta. Leggi l’impronta completa e confrontala con quella della chiave che intendi autorizzare.
ssh-keygen -lf ~/.ssh/id_ed25519_work.pubVisualizza le chiavi prima di installarle. Nelle implementazioni che supportano -n, questa modalità mostra le chiavi che verrebbero aggiunte senza installarle sul sistema remoto. Può comunque tentare connessioni e richiedere autenticazione: non è una simulazione completamente offline e non prova che la futura scrittura riuscirà.
ssh-copy-id -n -i ~/.ssh/id_ed25519_work.pub alice@server.example.comEsegui la registrazione. Dopo avere controllato destinazione, chiave e anteprima, esegui il comando senza -n:
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub alice@server.example.com-i seleziona esplicitamente il file pubblico; senza questa scelta possono essere usate altre identità disponibili. Normalmente lo script prova le chiavi per individuare quelle già utilizzabili e aggiunge quelle mancanti al file remoto ~/.ssh/authorized_keys. Una richiesta della passphrase locale può servire a sbloccare il privato durante la verifica: non equivale alla password dell’account sul server.
Conserva l’accesso amministrativo già disponibile mentre esegui questi passaggi. Non usare sudo sul client soltanto per superare un errore di lettura: potresti selezionare le chiavi o la configurazione di un altro utente.
Verificare l’accesso dopo la registrazione
Questa variante usa l’account dimostrativo user. La destinazione deve essere la stessa che userai nella successiva prova di accesso:
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@server.example.testUn possibile messaggio di aggiunta riuscita è il seguente; il numero dipende dalle chiavi effettivamente installate:
Number of key(s) added: 1Apri un nuovo terminale e prova ssh -i ~/.ssh/id_ed25519_work user@server.example.test, usando il file privato corrispondente. Se hai impostato una porta diversa, mantienila coerente nella registrazione con ssh-copy-id -p e nella prova con ssh -p. La guida al comando ssh spiega destinazione e verifica dell’host.
Un login riuscito, da solo, non dimostra che sia stata accettata proprio quella chiave: SSH può usare altre identità o ripiegare su un altro metodo. Per una verifica mirata puoi limitare le identità con -o IdentitiesOnly=yes e i metodi con -o PreferredAuthentications=publickey, quindi controllare la diagnostica di ssh -v. Eventuali requisiti di autenticazione aggiuntiva del server vanno rispettati; un errore non prova automaticamente che la chiave manchi. Non condividere log completi senza controllare nomi, percorsi e indirizzi che contengono.
Il messaggio di aggiunta non autorizza a disabilitare subito l’accesso tramite password. Prima verifica una sessione nuova, gli altri account amministrativi e un canale di recupero indipendente; mantieni aperta la sessione funzionante durante i controlli.
Opzioni principali
| Opzione | Funzione e limite |
|---|---|
-i file_pubblico |
Seleziona la pubblica da installare. Controlla file e impronta prima dell’uso. |
-n |
Mostra le chiavi che verrebbero installate senza aggiungerle. Può comunque richiedere una connessione. |
-p porta |
Indica la porta SSH del server, da usare anche nella successiva prova di login. |
-s |
Usa SFTP (SSH File Transfer Protocol): scarica il file authorized_keys, lo modifica localmente e lo ricarica. Richiede un servizio SFTP e i permessi adatti. |
-f |
Salta il controllo delle chiavi già presenti. Può installare duplicati; non usarlo come rimedio generico agli errori. |
Permessi, errori e rimozione di una chiave
Se la connessione fallisce, distingui prima nome del server e porta raggiungibile dagli errori di autenticazione. Se la chiave viene aggiunta ma non consente l’accesso, controlla account di destinazione, corrispondenza pubblico/privato, proprietà e permessi del percorso remoto e criteri del servizio SSH.
Il percorso abituale è ~/.ssh/authorized_keys dell’utente remoto, ma l’amministratore può configurare un altro file o un’altra fonte di autorizzazione. Con i controlli rigorosi del server, file o directory scrivibili da altri utenti possono impedire l’uso delle chiavi. Non risolvere rendendo i permessi più permissivi: verifica la configurazione effettiva con l’amministratore. Le modalità ammesse possono dipendere anche dal filesystem e dai criteri del sistema.
Per revocare una pubblica, conserva una copia del file remoto e rimuovi soltanto la riga della chiave corretta, lasciando intatte le altre chiavi e le eventuali opzioni di restrizione. Confronta il materiale della chiave, non soltanto il commento. Verifica poi l’effetto da una nuova sessione: un accesso già aperto non viene necessariamente terminato dalla rimozione e altre fonti di autorizzazione possono ancora consentire l’accesso.
Domande frequenti
Perché viene ancora richiesta una password?
Durante la prima registrazione può servire la password dell’account remoto. Una richiesta della passphrase protegge invece la chiave privata locale. Se il nuovo login chiede ancora la password del server, verifica chiave selezionata, account, permessi e configurazione del servizio; alcuni server richiedono intenzionalmente più fattori.
Devo copiare anche il file senza .pub?
No. Il privato resta sul client e serve a dimostrare il possesso della chiave. La registrazione sul server riguarda la pubblica: controlla il contenuto del file anziché fidarti solo del nome.
Documentazione di riferimento
Consulta il manuale di ssh-copy-id nel progetto OpenSSH Portable per le opzioni e le differenze di implementazione. I manuali OpenSSH di ssh e sshd descrivono autenticazione e file delle chiavi autorizzate. Per il sistema in uso verifica anche le pagine man installate.
