Connessione SSH senza Password
SSH senza password su Linux...
E che SSH sarebbe senza password?!?
SSH, acronimo di Secure Shell, altro non è che un protocollo di comunicazione che consente un collegamento sicuro tra due computer permettendo all'operatore di impartire comandi di gestione, o trasferire file, lontano da occhi indiscreti, dato che si tratta di un collegamento cifrato. Ricorda il vetusto ed insicuro Telnet, protocollo ormai completamente dimenticato ed assolutamente non più in uso nel nuovo millennio.
A parte questo, SSH consente tante altre belle cose, tra cui lanciare applicazioni anche visuali, esportando su canale sicuro il «display» del proprio X System... o lanciare un backup con Rsync... o creare una connessione proxy sicura... ma c'è un solo, grande, problema: non c'è modo di «automatizzare» la password... nel senso che non puoi risparmiarti di digitarla!
O forse, anche, no...
Creiamo una connessione senza password
La cosa più fastidiosa è scrivere la password. Specie se devi fare il backup di diverse directory di un server: ogni directory, una password...
Ma esiste un modo per risparmiarsi questa operazione: certificare il PC da cui ci stiamo collegando!
Vale a dire scambiamo due chiavi, una pubblica ed una privata, tra il PC dove lavoro ed il server dove mi devo collegare: la chiave pubblica sarà salvata sul server, quella privata resterà in una directory della mia home sul PC da cui lavoro. Semplice, vero?
Vediamo come si fa
SSH permette due utili comandi:
1) ssh-keygen, che si occupa di generare la coppia di chiavi.
2) ssh-copy-id, che si occupa di copiare, nel punto giusto sul server, la chiave pubblica generata.
La prima cosa da fare è lanciare proprio ssh-keygen che provvederà a creare la coppia di chiavi ed a salvarle nella dir «nascosta» della home directory utente «~/.ssh/id_rsa.pub»:
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): <battere invio> Enter same passphrase again: <battere invio> Your identification has been saved in /home/user/.ssh/id_rsa Your public key has been saved in /home/user/.ssh/id_rsa.pub The key fingerprint is: SHA256:j0o6nH8xBN8iO5WyeD2lBfjkMNyX46QcncJMPF1/JQJ user@lytor The key's randomart image is: +---[RSA 3072]----+ | ..++o.=o | | *o+=E . | | oB*O+o . | | ..B**+ . . | | . *oSo . | | = - + | | . o . | | . . . | | . | +----[SHA256]-----+
Il comando non ha fatto altro che salvare nel file «id_rsa» la chiave privata e conservare la chiave pubblica in un file «da scambiare» con i sistemi remoti dal nome «id_rsa.pub».
Mai invertire le due chiavi! Ma con il comando che segue si fa tutto in modo preciso.
Salviamo la chiave pubblica sul server
A questo punto entra in gioco il secondo comando: «ssh-copy-id» che, come dice il suo nome, si occuperà di salvare, al posto giusto e in modo corretto, la chiave pubblica. Lanciandolo, avremo la richiesta della password del server remoto ed alcuni messaggi:
$ ssh-copy-id -i ~/.ssh/id_rsa.pub <ip_del_server> /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Password: password_utente_server Number of key(s) added: 1 Now try logging into the machine, with: "ssh <ip_del_server>" and check to make sure that only the key(s) you wanted were added.
Adesso, se proviamo a collegarci sul server non ci sarà più richiesta la password... a patto, chiaramente, che la connessione parta dal PC che abbiamo «certificato» con lo scambio di chiavi.
Se usiamo un PC diverso, inesorabilmente, SSH ci chiederà ancora la password...
Alcune «bizzarrie» di SSH...
Può capitare che, in una connessione ad un server piuttosto vecchiotto, si possa avere questo errore che, comunque, blocca la connessione:
$ ssh user@vecchioserverssh.net Unable to negotiate with vecchioserverssh.net port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
Significa che lo schema di crittazione proposto dal server non coincide con quelli proposti dal client che si sta usando... Ecco come risolvere il problema.
Semplicemente, basta «istruire» il client SSh ad usare anche lo schema di crittazione proposto dal server; per farlo, si può usare la riga di comando, aggiungendo il parametro che include l'algoritmo proposto dal server:
$ ssh -oHostKeyAlgorithms=+ssh-dss user@vecchioserverssh.net
Certamente, non è comodo scrivere un comando così lungo per una connessione SSH: ecco che, quello stesso parametro si può salvare nel file di configurazione del client SSH, un file che sarà letto ogni volta che si avvia una connessione SSH ad un server remoto. Il file in questione è «/etc/ssh/ssh_config» e basta aggiungere un rigo alla fine:
# vi /etc/ssh/ssh_config
...
...
...
HostKeyAlgorithms=+ssh-dss
In questo modo il problema è risolto per sempre 
SSH si scollega in caso di inattività
Altro guaio di SSH è la sconnessione che arriva dopo un certo tempo di inattività: cosa buona e giusta, in realtà che impedisce di star collegati senza impartire alcun comando ma spesso scomoda se si deve lavorare su un server mentre si lavora anche su altro... come fare per evitare la sconnessione automatica per timeout di SSH?
Anche in questo caso basta modificare il solito file di configurazione del client SSH, aggiungento un parametro che, ad intervalli prefissati, invia un carattere sulla connessione, impedendo che il server vada in «timeout»
Pertanto, basta modificare il solito «/etc/ssh/ssh_config» e basta aggiungere un altro rigo alla fine:
# vi /etc/ssh/ssh_config
...
...
...
ServerAliveInterval 60
In questo modo, ogni 60 secondi, si avrà l'invio di un carattere «NULL» sulla connessione con il server ed il problema è risolto 
Come scollegare un utente SSH da un sistema Linux
A volte, può succedere, che un utente connesso in SSH non sia «gradito» e si desideri buttarlo fuori dal sistema; per fare questo, basta identificare il «PID» (Process ID) del processo relativo alla connessione e «Killarlo». Vediamo, nel dettaglio, come fare:
Con il comando che segue, troviamo il PID (la seconda colonna del risultato esposto):
# ps faux |grep sshd root 1002 0.0 0.0 28700 1444 ? Ss 2021 0:03 /usr/sbin/sshd root 14845 0.0 0.1 28700 4752 ? Ss 07:52 0:00 \_ sshd: ciccio [priv] ciccio 14847 0.0 0.1 28700 3320 ? S 07:52 0:00 | \_ sshd: ciccio@pts/0
Volendo proprio «Killare» la connessione dell'utente «ciccio», basta dare il comando che segue con il PID preso dalla seconda colonna del risultato ottenuto dal comando precedente:
# kill -9 14847
Un pesce per SSH...
Il logo di OpenSSH è un pesce palla: un pesce palla con occhiali da sole e sguardo indifferente per i segreti che nasconde.
Nulla si strano se, una delle implementazioni di SSH è effettuata tramite un protocollo che si chiama FISH.
Fish permette di accedere ai file di un computer remoto usando il protocollo SSH; il computer remoto, infatti, deve avere attivo questo servizio che permetta la connessione.
La funzione è stata implementata in KDE e permette di accedere ad un computer mediante una URL di questo tipo: «fish://nomehost» oppure «fish://nomeutente@nomehost». Fish dovrebbe funzionare con ogni sistema remoto LINUX approssimativamente compatibile con POSIX. Usa alcuni i comandi di shell e, se è installato Perl, questo verrà preferito. Sull'altro computer deve esserci una shell Bourne (o compatibile, come bash).