Corso Linux / Accesso remoto SSH e trasferimenti di file con scp e sftp
Secure Shell (SSH) permette di accedere a un server remoto ed eseguire comandi tramite una connessione cifrata; gli strumenti OpenSSH scp e sftp consentono anche di trasferire file. Al primo collegamento verifica l’impronta della chiave host del server e conserva il metodo di accesso esistente finché non hai provato l’autenticazione con la nuova chiave.
Controlla i modi dei file delle chiavi nella lezione sui permessi dei file e gli errori di timeout o risoluzione dei nomi nella diagnostica delle connessioni di rete. Su Ubuntu esamina sia il servizio sia l’eventuale attivazione tramite socket con systemctl status ssh.service ssh.socket: non significa che entrambe le unità debbano essere sempre attive.
L’ambiente di riferimento è una macchina virtuale con un’installazione ordinaria di Ubuntu 26.04 LTS o Rocky Linux 9. Container, Windows Subsystem for Linux (WSL) e altri rilasci possono differire per servizi e pacchetti. Prepara una console di recupero e annota le versioni seguendo la lezione sull’ambiente di prova in macchina virtuale (in inglese).
Distinguere client e server prima dell’installazione
Il computer su cui digiti i comandi è il client; la macchina Linux alla quale accedi è il server. Il server deve avere un indirizzo raggiungibile, un account utente esistente, il demone SSH sshd disponibile e regole di rete che consentano la porta effettiva. Sul client servono gli strumenti OpenSSH; su Ubuntu il pacchetto è openssh-client, su Rocky Linux openssh-clients. Controlla con ssh -V la versione installata.
I due blocchi seguenti riguardano il server: esegui soltanto quello della tua distribuzione. Su Ubuntu:
sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh
Su Rocky Linux:
sudo dnf install openssh-server
sudo systemctl enable --now sshd
apt update aggiorna gli indici dei pacchetti; l’installazione e enable --now modificano il sistema e avviano il servizio. Ubuntu usa comunemente il nome ssh, Rocky Linux sshd, ma controlla le unità effettivamente installate. Firewall dell’host, regole di sicurezza cloud e inoltro delle porte NAT (traduzione degli indirizzi di rete) sono controlli separati. Prima di cambiare porta o limitare l’autenticazione, mantieni aperta una sessione funzionante e prepara l’accesso alla console.
Verificare l’identità del server al primo accesso
Ottieni l’impronta della chiave pubblica host tramite un canale già affidabile, come la console del server. Esegui il primo comando qui sotto sul server e il secondo sul client; sostituisci user e server.example con l’account e l’indirizzo reali. Se il server non dispone di una chiave host Ed25519, oppure la politica crittografica non la consente, chiedi all’amministratore di identificare la chiave host effettivamente usata.
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh user@server.example
Confronta l’impronta SHA256, un identificatore derivato dalla chiave, mostrata dal client con quella ottenuta dal canale affidabile prima di accettare. La chiave host identifica il server; è distinta dalla coppia di chiavi dell’utente usata per autenticarsi. Dopo l’autenticazione compare la shell remota: usa exit per tornare al client.
Un avviso di chiave host cambiata richiede un’indagine: può dipendere da una reinstallazione legittima oppure da un’intercettazione. Non cancellare l’intero file known_hosts e non disabilitare la verifica per eliminare l’avviso. Gestisci soltanto la voce interessata dopo aver confermato la sostituzione, come previsto dal manuale ufficiale di ssh.
Creare una coppia di chiavi e registrare soltanto quella pubblica
Esegui questi comandi sul client. Prima verifica che ~/.ssh esista e appartenga al tuo account; se manca, creala con mkdir -p ~/.ssh e imposta chmod 700 ~/.ssh su Linux. Non sovrascrivere una chiave già presente.
ssh-keygen -t ed25519 -f ~/.ssh/linux-course-key
ssh-copy-id -i ~/.ssh/linux-course-key.pub user@server.example
ssh -i ~/.ssh/linux-course-key user@server.example
Se ssh-keygen chiede di sovrascrivere un file, interrompi e scegli un nome diverso. Imposta una passphrase per proteggere la chiave privata e conservala sul client; sul server registra soltanto il file pubblico .pub. ssh-copy-id richiede un accesso già autorizzato all’account remoto. Se lo strumento non è disponibile, aggiungi la riga della chiave pubblica a ~/.ssh/authorized_keys dell’account corretto tramite una procedura approvata, senza sostituire le chiavi esistenti.
Su Linux i modi abituali sono 700 per la directory .ssh, 600 per authorized_keys sul server e 600 per la chiave privata sul client; verifica anche proprietario e permessi delle directory superiori. Le autorizzazioni di Windows seguono regole diverse: il solo numero mostrato da Git Bash non verifica gli stessi permessi Linux.
Prova l’accesso da un nuovo terminale prima di eliminare altri metodi di autenticazione. Specificare -i non prova da solo quale chiave sia stata usata: possono intervenire chiavi dell’agente o il ripiego sulla password. Per indagare, usa il comando completo ssh -v -o IdentitiesOnly=yes -i ~/.ssh/linux-course-key user@server.example e controlla il metodo di autenticazione riuscito. IdentitiesOnly=yes limita le identità offerte dall’agente alle identità configurate, ma non disabilita da solo l’autenticazione tramite password. Negli ambienti soggetti a FIPS (Federal Information Processing Standards) o ad altre politiche crittografiche, scegli un formato di chiave supportato e autorizzato.
Inviare e recuperare un piccolo file con scp
Esegui l’esempio sul client, usando un account di laboratorio. Controlla prima che i nomi di destinazione locali e remoti siano liberi: la redirezione >, scp e il successivo download possono sovrascrivere file esistenti.
printf "SSH transfer test\n" > transfer-test.txt
scp -i ~/.ssh/linux-course-key transfer-test.txt user@server.example:~/transfer-test.txt
scp -i ~/.ssh/linux-course-key user@server.example:~/transfer-test.txt ./transfer-returned.txt
cmp transfer-test.txt transfer-returned.txt
Il primo scp invia il file nella home remota; il secondo lo scarica con un nome diverso sul client. Se cmp non stampa nulla e termina con stato 0, i contenuti coincidono. Leggi subito lo stato con printf 'exit=%s\n' "$?"; 1 indica contenuti diversi e un valore maggiore segnala un errore di confronto. Il successo del confronto verifica i contenuti restituiti, non tutti i metadati dei file.
Le versioni recenti di OpenSSH scp usano il protocollo SFTP per impostazione predefinita. Controlla la compatibilità di client e server più vecchi, invece di presumere il comportamento del protocollo SCP storico. La cifratura del trasferimento non impedisce di scrivere nella destinazione sbagliata: controlla sempre il percorso.
Usare sftp interattivo e una porta personalizzata
Avvia sftp dal client nella directory che contiene transfer-test.txt:
sftp -i ~/.ssh/linux-course-key user@server.example
Nel prompt di sftp inserisci i comandi seguenti. pwd e ls riguardano la directory remota; lpwd e lls quella locale. Verifica entrambe prima di caricare o scaricare, perché l’upload usa la directory remota corrente e il download quella locale. Anche questi trasferimenti possono sovrascrivere file con lo stesso nome.
pwd
lpwd
ls
put transfer-test.txt
get transfer-test.txt transfer-sftp.txt
bye
put carica il file e get lo scarica come transfer-sftp.txt; bye chiude sftp. Tornato alla shell locale, confronta anche questo file con cmp transfer-test.txt transfer-sftp.txt e controlla subito lo stato d’uscita.
Se il server ascolta sulla porta 2222, ssh usa -p 2222, mentre scp e sftp usano -P 2222. Aggiungi l’opzione corretta ai comandi; per la registrazione della chiave, ssh-copy-id usa -p 2222. La porta deve corrispondere alla configurazione reale del servizio e alle regole di rete: cambiarla sul client non modifica il server.
Per una connessione rifiutata controlla indirizzo, porta, servizio e politica di rete; per un errore di autenticazione controlla nome utente, chiave, permessi e messaggio preciso. ssh -v può rivelare indirizzi, account e percorsi: oscura questi dati prima di condividere i log. Al termine elimina soltanto i file di laboratorio e la registrazione della chiave pubblica non più necessaria, preservando gli altri accessi.




