OpenSSH: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

OpenSSH (visualizza wikitesto)

Versione delle 07:51, 9 ott 2017

1 732 byte rimossi ,  9 ott 2017
nessun oggetto della modifica
Nessun oggetto della modifica
Nessun oggetto della modifica
(31 versioni intermedie di 4 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili | Lenny | Squeeze | Wheezy}}
{{SSH
 
|successivo=SFTP: SSH File Transfer Protocol
}}{{Versioni compatibili | Lenny | Squeeze | Wheezy | Jessie | Stretch}}{{OpenSSH}}
== Installazione ==
== Installazione ==


È bene premettere che se lo scopo di chi legge è solo collegarsi ad altri computer, ma non permettere la connessione a quello in uso, allora è sufficiente l'installazione del solo client (normalmente già effettuata durante l'installazione di debian), viceversa è sufficiente l'installazione del solo server.
È bene premettere che se lo scopo di chi legge è solo collegarsi ad altri computer, ma non permettere la connessione a quello in uso, allora è sufficiente l'installazione del solo client (normalmente già effettuata durante l'installazione di debian), viceversa è sufficiente l'installazione del solo server.
Premesso questo, per installare sia client che server digitare da terminale:
Premesso questo, per installare sia client che server digitare da terminale con [[privilegi di amministrazione]]:


<pre># aptitude install ssh</pre>
<pre># apt-get install ssh</pre>


Per installare il solo client:
Per installare il solo client:


<pre># aptitude install openssh-client</pre>
<pre># apt-get install openssh-client</pre>


Per installare il solo server:
Per installare il solo server:


<pre># aptitude install openssh-server</pre>
<pre># apt-get install openssh-server</pre>


Opzionalmente è possibile installare anche il pacchetto <code>openssh-blacklist</code>
Opzionalmente è possibile installare anche il pacchetto <code>openssh-blacklist</code>


<pre># aptitude install openssh-blacklist</pre>
<pre># apt-get install openssh-blacklist</pre>


== Utilizzo base ==
== Utilizzo base ==
Riga 28: Riga 29:
<pre>$ ssh username_remoto@host_remoto</pre>
<pre>$ ssh username_remoto@host_remoto</pre>
per iniziare il collegamento.<br/>
per iniziare il collegamento.<br/>
Si noti che ''host_remoto'' può essere un nome host, un FQDN o un indirizzo IP. Nei primi due casi il computer su cui è installato il client deve essere in grado di risolvere i nomi del computer remoto, o tramite server DNS oppure tramite file <code>/etc/hosts</code>.<br/>
Si noti che ''host_remoto'' può essere un nome host, un FQDN o un indirizzo IP. Nei primi due casi il computer su cui è installato il client deve essere in grado di risolvere i nomi del computer remoto, o tramite server DNS oppure tramite file <code>/etc/hosts</code>.
 
Quando ci si collega per la prima volta ad una nuova macchina remota verrà chiesto all'utente se intende effettivamente proseguire con la procedura di autenticazione e contestualmente aggiungere la chiave pubblica della macchina remota al proprio file locale <code>~.ssh/known_hosts</code>.<br>
Quando ci si collega per la prima volta ad una nuova macchina remota verrà chiesto all'utente se intende effettivamente proseguire con la procedura di autenticazione e contestualmente aggiungere la chiave pubblica della macchina remota al proprio file locale <code>~.ssh/known_hosts</code>.<br>
Il messaggio che viene stampato a video contiene "l'impronta digitale" della chiave pubblica che si andrà ad accettare, così che l'utente possa confrontarla con quella eventualmente già in suo possesso e quindi capire se la macchina remota è effettivamente quella cui l'utente vuole connettersi e NON una macchina diversa operata da qualche malintenzionato. Naturalmente l'utente non è obbligato ad effettuare un simile controllo e quindi può limitarsi ad accettare "andando sulla fiducia". Sebbene potenzialmente rischioso come comportamento, il buon senso aiuta sempre in queste situazioni, quindi se l'utente si collega ad un computer della propria LAN oppure alla macchina di un noto provider, è evidente che il rischio di collegarsi ad una macchina "maligna" sarà nullo o ragionevolmente trascurabile.<br/>
Il messaggio che viene stampato a video contiene "l'impronta digitale" della chiave pubblica che si andrà ad accettare, così che l'utente possa confrontarla con quella eventualmente già in suo possesso e quindi capire se la macchina remota è effettivamente quella cui l'utente vuole connettersi e NON una macchina diversa operata da qualche malintenzionato.
Una volta accettata la chiave pubblica remota viene richiesta la password dell'account remoto cui si sta tentando di accedere. Una volta inseritala comprarirà il prompt dei comandi della macchina remota e l'utente potrà operare come se stesse usando una normalissima istanza del terminale del suo computer.<br/>
 
<pre>
utente@localhost:~# ssh server@xxxx.xxxx.xxxxxx
The authenticity of host 'xxxx.xxxxx.xxxxx (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?
</pre>
 
Naturalmente l'utente non è obbligato ad effettuare un simile controllo e quindi può limitarsi ad accettare "andando sulla fiducia". Sebbene potenzialmente rischioso come comportamento, il buon senso aiuta sempre in queste situazioni, quindi se l'utente si collega ad un computer della propria LAN oppure alla macchina di un noto provider, è evidente che il rischio di collegarsi ad una macchina "maligna" sarà nullo o ragionevolmente trascurabile. Una volta accettato comparirà il seguente messaggio:
 
<pre>Warning: Permanently added 'xxxx.xxxxx.xxxxx' (ECDSA) to the list of known hosts.</pre>
 
A questo punto sarà richiesta la password dell'account remoto cui si sta tentando di accedere. Una volta inseritala comparirà il prompt dei comandi della macchina remota e l'utente potrà operare come se stesse usando una normalissima istanza del terminale del suo computer.<br/>
Per terminare una connessione è sufficiente digitare:
Per terminare una connessione è sufficiente digitare:
<pre>$ Exit</pre>
<pre>$ exit</pre>
eventualmente più volte se nel frattempo si è assunta l'identità di root col comando <code>su</code> (o di qualche altro utente).<br/>
eventualmente più volte se nel frattempo si è assunta l'identità di root col comando <code>su</code> (o di qualche altro utente).<br/>


Riga 49: Riga 63:
* L'autenticazione tramite chiavi pubblica/privata permette, volendo, di stabilire connessioni senza dover digitare alcuna password o codice di sblocco.
* L'autenticazione tramite chiavi pubblica/privata permette, volendo, di stabilire connessioni senza dover digitare alcuna password o codice di sblocco.


== Utilizzo avanzato ==


{{Warningbox|Ogni qualvolta si apportano modifiche ai file di configurazione ''/etc/ssh/ssh_config'' e ''/etc/ssh/sshd_config'' è necessario riavviare il demone ssh per renderle operative.}}
{{Warningbox|Ogni qualvolta si apportano modifiche ai file di configurazione ''/etc/ssh/ssh_config'' e ''/etc/ssh/sshd_config'' è necessario riavviare il demone ssh per renderle operative.}}


=== Cambio del numero di porta ===
Una delle personalizzazioni più semplici che si può adottare è la modifica della porta predefinita, ovvero l'indicazione di un numero di porta differente dalla 22. Tale scelta può essere una necessità pratica, dovuta ad esempio alla necessità di collegarsi a più macchine tutte poste dietro uno stesso router/NAT, oppure un piccolo artificio per rendere un po' più difficili gli attacchi al proprio server SSH da parte di malintenzionati.
{{Box|Nota|Se si decide di cambiare numero di porta è bene ricordare che i numeri fino a 1024 sono riservati al sistema, pertanto '''l'utente dovrà scegliere sempre dei valori maggiori di 1024'''.}}
==== Client ====
Ci sono due strade per utilizzare un numero di porta differente:
# passare il numero direttamente da riga di comando usando l'opzione <code>-p</code>;
# modificare il file di configurazione <code>/etc/ssh/ssh_config</code>
Un esempio della prima opzione è il seguente:
<pre>$ ssh utente_remoto@host_remoto -p 13462</pre>
La riga da modificare nel file di configurazione è invece quella dove compare la voce <code>'''#  Port 22'''</code>:
<pre>
[...]
#  IdentityFile ~/.ssh/id_dsa
#  Port 22
#  Protocol 2,1
[...]
</pre>
È quindi sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:
<pre>
[...]
#  IdentityFile ~/.ssh/id_dsa
    Port 13462
#  Protocol 2,1
[...]
</pre>
{{Box|Note|
* Tutto quanto qui scritto presuppone che l'utente abbia già configurato il server SSH della macchina remota per comunicare su una porta diversa dalla 22.
* Se l'utente modifica il file <code>/etc/ssh/ssh_config</code> indicando la stessa porta contenuta nel file <code>/etc/ssh/sshd_config</code> presente sulla macchina remota chiaramente non è necessario usare l'opzione ''-p'' da riga di comando.}}
==== Server ====
Se si opta per l'utilizzo di una porta differente da quella standard è necessario specificare tale valore non solo nella configurazione del client, ma anche in quello del server operante sulla macchina remota.<br>
Si tratta cioè di editare il file <code>/etc/ssh/sshd_config</code> e modificare la voce <code>'''Port 22'''</code>:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
[...]
</pre>
per esempio in:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 13462
[...]
</pre>


=== Metodi di autenticazione ===
== Autenticazione con chiavi ==


Come già scritto il metodo di autenticazione utilizzabile fin da subito, cioè l'inserimento della password relativa all'account remoto, non è il più sicuro poiché suscettibili di attacchi a forza bruta o in ogni caso di rivelare la stessa nel caso di collegamento a server fittizi gestiti da malintenzionati.<br/>
Come già scritto il metodo di autenticazione utilizzabile fin da subito, cioè l'inserimento della password relativa all'account remoto, non è il più sicuro poiché suscettibili di attacchi a forza bruta o in ogni caso di rivelare la stessa nel caso di collegamento a server fittizi gestiti da malintenzionati.<br/>
OpenSSH supporta attualmente cinque tipi di autenticazione:
OpenSSH supporta attualmente cinque tipi di autenticazione:
# kerberos (gssapi-with-mic)
# kerberos (gssapi-with-mic), basata su un'API generica implementata su vari sistemi operativi, utilizza un protocollo che normalmente è Kerberos 5, per trasferire i dati per l'autenticazione;
# chiave client ('''hostbased''')
# chiave client ('''hostbased'''), concettualmente simile al metodo della chiave pubblica, ma con la differenza che il server remoto verifica l'identità della macchina client e non degli utenti;
# chiave pubblica ('''publickey''')
# chiave pubblica ('''publickey'''), in sintesi la macchina remota invia all'utente una stringa cifrata con una chiave pubblica precedentemente indicata dall'utente stesso, se il client dell'utente possiede la chiave privata corretta procede a decodificare tale stringa e quindi prova la sua identità al computer remoto che gli garantisce l'accesso;
# keyboard-interactive
# keyboard-interactive (''ChallengeResponseAuthentication''), utilizza una serie di autenticazioni caratterizzate da richieste, fatte dal server SSH, che devono essere confermate dalle risposte mandate dal client SSH. Se le risposte coincidono con quelle memorizzate sul Server, l'utente è autorizzato ad accedere da remoto alla macchina Linux altrimenti questi non può accedere alla macchina Linux. Di default avviene tramite [[PAM]], e corrisponde alla richiesta di password dell'account remoto a cui si intende accedere;
# '''password'''
# '''password''' (''PasswordAuthentication''), si richiede la password dell'utenza indicata in fase di login per verificare se l'utente è autorizzato ad accedere a tale utenza sulla macchina remota Linux, a prescindere dalla procedura prevista per l'autenticazione sulla macchina remota.


Ai fini di questa guida saranno trattate, in aggiunta all'ultimo tipo già descritto, anche le modalità ''hostbased'' e ''publickey'', tuttavia prima di procedere a descriverle nel dettaglio è bene precisare che i due metodi sono simili tra loro poiché entrambi sfruttano l'accoppiata chiave pubblica e privata per suggellare l'autenticazione dell'utente.
Ai fini di questa guida saranno trattate, in aggiunta all'ultimo tipo già descritto, anche le modalità ''hostbased'' e ''publickey'', tuttavia prima di procedere a descriverle nel dettaglio è bene precisare che i due metodi sono simili tra loro poiché entrambi sfruttano l'accoppiata chiave pubblica e privata per suggellare l'autenticazione dell'utente.


{{Box|Nota|Dei due metodi ''hostbased'' e ''publickey'', solo il secondo può dirsi sicuramente più sicuro di quello basato su password.}}
{{Box|Nota|Dei due metodi ''hostbased'' e ''publickey'', solo il secondo può dirsi sicuramente più sicuro di quello basato su password.
 
Ed entrambi aggiungeranno una nuova possibilità di autenticazione, senza rimuovere quella tramite password, attiva di default. Se si intende rendere possibile l'autenticazione unicamente via chiave pubblica dell'utente oppure del client, è necessario disabilitare l'autenticazione via password ("<code>PasswordAuthentication no</code>" e, se abilitato, "<code>ChallengeResponseAuthentication no</code>") modificando il [[OpenSSH: file di configurazione | file di configurazione]].}}


==== hostbased ====
=== hostbased ===


Usando questa modalità non vengono autenticati i singoli utenti, ma la macchina stessa. In pratica la macchina remota controlla solo che la macchina client sia veramente chi dice di essere, ma non esegue alcun controllo sugli utenti. Superata tale verifica gli account della macchina client hanno immediatamente accesso all'account omonimo presente sulla macchina remota.
Usando questa modalità non vengono autenticati i singoli utenti, ma la macchina stessa. In pratica la macchina remota controlla solo che la macchina client sia veramente chi dice di essere, ma non esegue alcun controllo sugli utenti. Superata tale verifica gli account della macchina client hanno immediatamente accesso all'account omonimo presente sulla macchina remota.
Riga 133: Riga 93:
{{Box|Alternative|Il server SSH in modalità autenticazione ''hostbased'' può essere anche configurato per permettere ad un singolo utente della macchina client di accedere ad utenze multiple, o perfino tutte, della macchina remota. In questa guida ci si limiterà al caso ''utente client --> utente remoto omonimo''. Se il lettore fosse interessato alle altre possibilità veda il manuale relativamente ai file <code>/etc/hosts.equiv</code> e <code>~/shosts</code>}}
{{Box|Alternative|Il server SSH in modalità autenticazione ''hostbased'' può essere anche configurato per permettere ad un singolo utente della macchina client di accedere ad utenze multiple, o perfino tutte, della macchina remota. In questa guida ci si limiterà al caso ''utente client --> utente remoto omonimo''. Se il lettore fosse interessato alle altre possibilità veda il manuale relativamente ai file <code>/etc/hosts.equiv</code> e <code>~/shosts</code>}}


===== Generazione chiavi =====
==== Generazione chiavi ====


Normalmente in fase di installazione vengono già generate automaticamente una coppia di chiavi pubblica/privata per ogni tipo di algoritmo di cifratura. Tali chiavi sono conservate in <code>/etc/ssh/</code>, insieme ai file di configurazione, e condividono tutte la parte iniziale del loro nome, ovvero ''ssh_host_''.<br/>
Normalmente in fase di installazione vengono già generate automaticamente una coppia di chiavi pubblica/privata per ogni tipo di algoritmo di cifratura. Tali chiavi sono conservate in <code>/etc/ssh/</code>, insieme ai file di configurazione, e condividono tutte la parte iniziale del loro nome, ovvero ''ssh_host_''.<br/>
Riga 167: Riga 127:
{{Box|Nota|Per usare un numero di bit maggiore, ammesso che ciò sia possibile (rsa sì, ed25519 no), è necessario creare le chiavi manualmente, rinominarle correttamente e copiarle in <code>/etc/ssh/</code>. Per i dettagli si rimanda alla sezione dedicata alla modalità ''publickey'', avendo cura però di creare le chiavi usando l'utenza di ''root'' e di non specificare alcun codice di sblocco.}}
{{Box|Nota|Per usare un numero di bit maggiore, ammesso che ciò sia possibile (rsa sì, ed25519 no), è necessario creare le chiavi manualmente, rinominarle correttamente e copiarle in <code>/etc/ssh/</code>. Per i dettagli si rimanda alla sezione dedicata alla modalità ''publickey'', avendo cura però di creare le chiavi usando l'utenza di ''root'' e di non specificare alcun codice di sblocco.}}


===== Client =====
==== Client ====


È necessario modificare il file <code>/etc/ssh/ssh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad aggiungere <code>EnableSSHKeysign yes</code>:
È necessario modificare il file <code>/etc/ssh/ssh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad aggiungere <code>EnableSSHKeysign yes</code>:
Riga 181: Riga 141:
</pre>
</pre>


===== Server =====
==== Server ====


È necessario modificare il file <code>/etc/ssh/ssdh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad assicurarsi che lo siano anche i parametri <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code>:
È necessario modificare il file <code>/etc/ssh/ssdh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad assicurarsi che lo siano anche i parametri <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code>:
Riga 213: Riga 173:
* Controllare sempre di aver scritto correttamente il FQDN della macchina client.}}
* Controllare sempre di aver scritto correttamente il FQDN della macchina client.}}


==== publickey ====
=== publickey ===


Questa modalità si basa sull'autenticazione dell'utente esattamente come per la modalità ''password'', ma per l'appunto sfruttando l'accoppiata chiave pubblica/privata.
Questa modalità si basa sull'autenticazione dell'utente esattamente come per la modalità ''password'', ma per l'appunto sfruttando l'accoppiata chiave pubblica/privata.


===== Generazione chiavi =====
==== Generazione chiavi ====


Il primo passo è creare le chiavi col solito <code>ssh-keygen</code>, tuttavia la procedura è leggermente diversa da quella descritta per il caso ''hostbased''. In questo caso l'utente avrà infatti facoltà di scegliere l'algoritmo di cifratura (''rsa'' è quello predefinito), il numero di bit quando permesso dall'algoritmo scelto, la directory dove salvare la coppia di chiavi (la destinazione predefinita è <code>~/.ssh/</code>) e se inserire o meno un codice di sblocco della chiave.
Il primo passo è creare le chiavi col solito <code>ssh-keygen</code>, tuttavia la procedura è leggermente diversa da quella descritta per il caso ''hostbased''. In questo caso l'utente avrà infatti facoltà di scegliere l'algoritmo di cifratura (''rsa'' è quello predefinito), il numero di bit quando permesso dall'algoritmo scelto, la directory dove salvare la coppia di chiavi (la destinazione predefinita è <code>~/.ssh/</code>) e se inserire o meno un codice di sblocco della chiave.
Riga 238: Riga 198:
Si noti che i permessi della chiave privata sono impostati a 600, cioè solo l'utente proprietario del file può accedervi.
Si noti che i permessi della chiave privata sono impostati a 600, cioè solo l'utente proprietario del file può accedervi.


===== Client =====
==== Client ====


Nessuna modifica da apportare al file <code>/etc/ssh/ssh_config</code> poiché i valori predefiniti delle variabili <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code> risultano già essere impostati a ''yes''.
Nessuna modifica da apportare al file <code>/etc/ssh/ssh_config</code> poiché i valori predefiniti delle variabili <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code> risultano già essere impostati a ''yes''.


===== Server =====
==== Server ====


Nessuna modifica da apportare al file <code>/etc/ssh/sshd_config</code> poiché i valori predefiniti delle variabili <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code> risultano già essere impostati a ''yes''.
Nessuna modifica da apportare al file <code>/etc/ssh/sshd_config</code> poiché i valori predefiniti delle variabili <code>RSAAuthentication</code> e <code>PubkeyAuthentication</code> risultano già essere impostati a ''yes''.
Riga 253: Riga 213:


{{Box|Nota|Se si trasferisce manualmente la chiave pubblica facendo copia ed incolla tra due editor di testo si presti ATTENZIONE a non spezzare la chiave su più righe. È infatti obbligatoria l'indicazione di '''una sola chiave per riga'''.}}
{{Box|Nota|Se si trasferisce manualmente la chiave pubblica facendo copia ed incolla tra due editor di testo si presti ATTENZIONE a non spezzare la chiave su più righe. È infatti obbligatoria l'indicazione di '''una sola chiave per riga'''.}}
<br/>
{{Warningbox|Se non si riuscisse a collegarsi ricevendo invece il messaggio ''Permission denied (publickey)'' verificare che:
* la chiave privata usata in fase di autenticazione sia quella corretta;
* la chiave pubblica necessaria sia stata effettivamente (e correttamente) aggiunta al file <code>authorized_keys</code>;
* il file <code>~/.ssh/authorized_keys</code> sia accessibile solo e soltanto al proprietario (600);
* la home dell'utenza che si vuole usare sia scrivibile solo da essa (755, 750 o 700)}};
<br/>


=== Strumenti complementari opzionali ===
== Analisi dei file di configurazione ==
 
==== Fail2ban ====
 
[[Fail2ban | Fail2ban]] serve per limitare gli accessi indesiderati, bandendo per x secondi un IP che ha superato un numero di accessi impostato.
 
Attenzione perché il ban riguarda solo la porta interessata.
 
Installare fail2ban è semplice :
<pre># aptitude install fail2ban</pre>
 
Per maggiori info visitate la documentazione ufficiale, mentre per utilizzarlo come nel nostro caso interverremo operando alcune modifiche al file <code>''/etc/fail2ban/jail.conf''</code>.
<pre>#tempo di ban espresso in secondi es: 3600 = 1 ora
#un tempo corto ferma ugualmente i robot e facilità il vostro ingresso in tempi brevi in caso di errore
bantime = 14400
#Numero di tentativi massimo , prima dell'azione di ban
maxretry = 3
 
[ssh]
 
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3</pre>
 
L'opzione <code>maxretry</code> risulta doppia dato che è possibile diversificare l'uso a seconda dei servizi utilizzati: la prima opzione è generale, la seconda sottostante al servizio indicato personalizza la singola applicazione.<br/>
Per ciò che riguarda la riga:
<pre>
port    = ssh
</pre>
"ssh" va sostituito con la porta scelta in precedenza (vedi il paragrafo [[#Porta|Porta]]). Nel caso si lasci "ssh", il ban avverrà sulla porta di default di SSH (porta 22).<br/>
Per cui, continuando a seguire la configurazione descritta in questa guida, la riga va modificata con:
<pre>
port  = 2974
</pre>
 
Per fare una prova e verificare subito se tutto funziona, generiamo alcuni accessi con user sbagliato sul nostro server SSH e con il comando sotto riportato saremo subito in grado di verificare la presenza di errori.
<pre># fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf</pre>
 
Se avete abilitato il servizio di avviso a mezzo mail, questa sotto è una parte del messaggio che vi arriverà:
 
<pre>Hi,
 
The IP 78.xx.xx.113 has just been banned by Fail2Ban after
3 attempts against ssh.
 
whois ..............
Lines containing IP:78.xx.xx.113 in /var/log/auth.log
 
Oct 17 19:10:38 kserver sshd[23844]: Invalid user admin from 78.xx.xx.113
Oct 17 19:11:26 kserver sshd[23851]: Invalid user admin from 78.xx.xx.113
Oct 17 19:11:28 kserver sshd[23853]: Invalid user admin from 78.xx.xx.113</pre>
 
{{Box|Nota|Dalla configurazione eseguita, l'accesso deve essere fatto con il nome user corretto altrimenti fail2ban interviene bannando l'IP.}}
 
==== Blockcontrol ====
 
L'uso di <code>blockcontrol</code> è spiegato [http://e-zine.debianizzati.org/web-zine/numero_4/?page=82 nell'e-zine n°4], detto ciò mi limiterò ad alcune considerazioni.
 
L'unica eccezione che si aggiunge alla guida sull'e-zine riguarda l'apertura delle porte per la connessione all'interno del file di configurazione <code>''/etc/blockcontrol/blockcontrol.conf''</code>, dove inseriremo in TCP-in e TCP-out la porta impostata per SSH.
 
<pre># Do a "blockcontrol restart" (sometimes even "reload" is enough) when you have
# edited this file.
 
WHITE_TCP_OUT="2974"
WHITE_TCP_IN="2974"</pre>


Grazie all'aggiunta di filtri, possiamo chiudere l'accesso a diversi range di IP. Per un server consiglio il filtro proxy per ovviare al cambio IP se uno viene bannato.
Si veda [[OpenSSH: file di configurazione | la guida dedicata]].


Poi considero validi anche i filtri nazioni in cui non andrò mai e dalle quali non aspetto connessioni, come Cina, Taiwan, Korea e Russia dalle quali è più probabile ricevere connessioni malevole.
Per maggiori informazioni sulle liste disponibili, visitare: http://www.iblocklist.com/lists.php


== Altri client OpenSSH compatibili ==
== Altri client OpenSSH compatibili ==
Riga 340: Riga 238:
Al prompt inserire <code>nome_user@indirizzo_server:porta</code>, et voilà, dopo aver inserito la password si sarà dentro.
Al prompt inserire <code>nome_user@indirizzo_server:porta</code>, et voilà, dopo aver inserito la password si sarà dentro.


=== Windows ===
== Esempi ==


Consiglio putty che ho provato e uso ancora in ufficio dove sono costretto all'uso di WinXP, forse perché in una vita precedente sono stato cattivo.
=== Cambio del numero di porta ===


Prestiamo attenzione oltre alla generazione delle chiavi a come viene esportata la chiave in modo che sia compatibile con openssh.
Una delle personalizzazioni più semplici che si può adottare è la modifica della porta predefinita, ovvero l'indicazione di un numero di porta differente dalla 22. Tale scelta può essere una necessità pratica, dovuta ad esempio alla necessità di collegarsi a più macchine tutte poste dietro uno stesso router/NAT, oppure un piccolo artificio per rendere un po' più difficili gli attacchi al proprio server SSH da parte di malintenzionati.


Finché avete aperta la finestra del generatore di chiave vi sarà possibile copiarla, altrimenti se la salvate dovrete eliminare le prime 2 righe e inserire ssh-rsa per rsa oppure ssh-dss per dsa, lasciate uno spazio vuoto e inserite in un'unica riga il testo della chiave.
{{Box|Nota|Se si decide di cambiare numero di porta è bene ricordare che i numeri fino a 1023 sono riservati al sistema, pertanto '''l'utente dovrà scegliere sempre dei valori maggiori o uguali a 1024'''.}}


[[Immagine:MmteamPutty001.JPG |320px | center]]
==== Client ====


Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.
Ci sono due strade per utilizzare un numero di porta differente:
# passare il numero direttamente da riga di comando usando l'opzione <code>-p</code>;
# modificare il file di configurazione <code>/etc/ssh/ssh_config</code>
Un esempio della prima opzione è il seguente:
<pre>$ ssh utente_remoto@host_remoto -p 13462</pre>
La riga da modificare nel file di configurazione è invece quella dove compare la voce <code>'''#  Port 22'''</code>:
<pre>
[...]
#  IdentityFile ~/.ssh/id_dsa
#  Port 22
#  Protocol 2,1
[...]
</pre>
È quindi sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:
<pre>
[...]
#  IdentityFile ~/.ssh/id_dsa
    Port 13462
#  Protocol 2,1
[...]
</pre>


Salvate ora la chiave privata in un luogo sicuro.
{{Box|Note|
* Tutto quanto qui scritto presuppone che l'utente abbia già configurato il server SSH della macchina remota per comunicare su una porta diversa dalla 22.
* Se l'utente modifica il file <code>/etc/ssh/ssh_config</code> indicando la stessa porta contenuta nel file <code>/etc/ssh/sshd_config</code> presente sulla macchina remota chiaramente non è necessario usare l'opzione ''-p'' da riga di comando.}}


Per la connessione indicate a putty dove risiede la vostra chiave privata .
==== Server ====


[[Immagine:Mmteamputty2.JPG |320px | center]]
Se si opta per l'utilizzo di una porta differente da quella standard è necessario specificare tale valore non solo nella configurazione del client, ma anche in quello del server operante sulla macchina remota.<br>
Si tratta cioè di editare il file <code>/etc/ssh/sshd_config</code> e modificare la voce <code>'''Port 22'''</code>:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details


e nella schermata principale inserite i dati per la connessione.
# What ports, IPs and protocols we listen for
 
Port 22
[[Immagine:MmteamPutty003.JPG |320px | center]]
[...]
 
</pre>
Al login dovrete inserire la password impostata nella chiave.
per esempio in:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details


# What ports, IPs and protocols we listen for
Port 13462
[...]
</pre>


== Approfondimenti ==
== Approfondimenti ==
Riga 378: Riga 309:
* [http://users.telenet.be/mydotcom/howto/linux/sshpasswordless.htm SSH passwordless]
* [http://users.telenet.be/mydotcom/howto/linux/sshpasswordless.htm SSH passwordless]
* [https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication Host based authentication]
* [https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication Host based authentication]
* [https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process SSH encryption and connection process], pagina che spiega le basi di chiavi pubblica/privata e di come funziona il processo autenticativo di SSH.


{{Autori
{{Autori
|Autore = [[Utente:Mm-barabba|Mm-barabba]] 00:55, 20 nov 2010 (CET)
|Autore = [[Utente:Mm-barabba|Mm-barabba]] 00:55, 20 nov 2010 (CET)
|Estesa_da =
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
|Verificata_da=
|Verificata_da=
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
|Numero_revisori=1
:[[Utente:HAL 9000|HAL 9000]] 13:56, 26 set 2015 (CEST)
|Estesa_da =
:[[Utente:Ferdybassi|Ferdybassi]] 15:42, 12 mar 2016 (CET)
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
|Numero_revisori=3
}}
}}


[[Categoria:SSH_server_e_amministrazione_remota]]
[[Categoria:SSH_server_e_amministrazione_remota]]
Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/39572...42119"

Menu di navigazione