SSH: differenze tra le versioni

Da UZ wiki.
(Aggiorno i programmi disponibili per Linux)
(Nomi dei server ssh: Coccoina è... resuscitata? Resuscitato? Boh)
 
(16 revisioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
{{Q|Come faccio a forwardare ''tutte'' le porte del server UZ sul mio computer?|[[User:Alex|Oscar Wilde]]}}
+
{{Q|Come faccio a forwardare ''tutte'' le porte del server UZ sul mio computer?|[[Oscar Wilde]]}}
  
 
Il protocollo '''ssh''' vi consente di trasferire file dal server [[UZ]] al vostro computer e viceversa (consultare [[SCP e SFTP]]), e anche di impartire comandi come se foste seduti di fronte al server. Tutte le connessioni sono cifrate.
 
Il protocollo '''ssh''' vi consente di trasferire file dal server [[UZ]] al vostro computer e viceversa (consultare [[SCP e SFTP]]), e anche di impartire comandi come se foste seduti di fronte al server. Tutte le connessioni sono cifrate.
Riga 5: Riga 5:
 
==Parametri generali di connessione==
 
==Parametri generali di connessione==
 
{| border="1" cellpadding="2"
 
{| border="1" cellpadding="2"
| ''server'' || ssh.uz.sns.it
+
| ''server'' || ssh*.uz.sns.it
 
|-
 
|-
 
| ''nome utente / password'' || quelli del vostro account di UZ
 
| ''nome utente / password'' || quelli del vostro account di UZ
Riga 17: Riga 17:
  
 
==Nomi dei server ssh==
 
==Nomi dei server ssh==
Abbiamo due server ssh, di solito collegandovi ad <code>ssh.uz.sns.it</code> andate sul sicuro, ma se volete scegliere voi a che server collegarvi esiste <code>ssh1.uz.sns.it</code> che si trova al Carducci e <code>ssh2.uz.sns.it</code> che si trova al Faedo. Comunque tutti e due questi server sono accessibili anche da internet e se non ne funziona uno potete usare l'altro.
+
Abbiamo tre server ssh, di solito collegandovi ad <code>ssh.uz.sns.it</code> (che è un alias per <code>ssh1.uz.sns.it</code>) andate sul sicuro, ma se volete scegliere voi a che server collegarvi esistono anche <code>ssh2.uz.sns.it</code> che si trova al Faedo e <code>ssh3.uz.sns.it</code> che si trova al Timpano. I server <code>ssh</code> e <code>ssh2</code> sono accessibili anche dall'esterno della rete SNS, mentre <code>ssh3</code> no.  
Inoltre è consigliabile usare il server del proprio collegio (se siete in camera), dovrebbe garantirvi una velocità maggiore e così intasate meno le reti della SNS.
+
In generale è preferibile usare <code>ssh</code>, ma in caso questo non funzioni è comunque possibile usarne un altro.
 
+
È possibile che qualcuno per motivi storici usi ancora <code>uz.sns.it</code>. Per ora funziona, ma potrebbe smettere in qualsiasi momento. Quindi convertitevi a <code>ssh.uz.sns.it</code>.
+
  
 
== Linux ==
 
== Linux ==
Riga 56: Riga 54:
  
 
== Mac ==
 
== Mac ==
Usate [http://rsug.itd.umich.edu/software/fugu/ Fugu], un client [[SCP e SFTP]] libero per Mac OS X.
+
Usate [https://cyberduck.io/ Cyberduck] oppure [https://filezilla-project.org/ FileZilla].
 +
 
 +
== Android ==
 +
Scaricate [https://play.google.com/store/apps/details?id=com.estrongs.android.pop&hl=it ES Gestore File]. Andate sulla scheda "Rete", premete "Nuovo" e poi "sftp". Compilate i campi in questo modo:
 +
{| border="1" cellpadding="2"
 +
| ''server'' || ssh.uz.sns.it/afs/uz.sns.it/user/il_vostro_username/
 +
|-
 +
| ''porta'' || 22 ''(quella predefinita)''
 +
|-
 +
| ''nome utente / password'' || quelli del vostro account di UZ
 +
|-
 +
| ''codifica'' || AUTO
 +
|}
  
 
== Chiavi ==
 
== Chiavi ==
 
Alla prima connessione i client ssh vi chiedono di verificare la ''fingerprint'' della chiave pubblica di UZ: ciò serve per verificare che il server a cui vi state connettendo sia veramente UZ e non un "server falso" creato da un malintenzionato allo scopo di rubare la vostra password (l'eventualità non è poi così impossibile, anzi, se non ci fosse questa verifica sarebbe tecnicamente possibile farlo).
 
Alla prima connessione i client ssh vi chiedono di verificare la ''fingerprint'' della chiave pubblica di UZ: ciò serve per verificare che il server a cui vi state connettendo sia veramente UZ e non un "server falso" creato da un malintenzionato allo scopo di rubare la vostra password (l'eventualità non è poi così impossibile, anzi, se non ci fosse questa verifica sarebbe tecnicamente possibile farlo).
  
La chiave RSA del server UZ ha come ''fingerprint'' <code>91:e3:fc:95:90:93:c5:b8:a5:ac:fc:5a:38:11:dd:ac</code>
+
{|border="1"
 
+
! !! ssh1.uz.sns.it !! ssh2.uz.sns.it !! ssh3.uz.sns.it
La chiave DSA del server UZ ha come ''fingerprint'' <code>af:97:29:aa:39:85:49:4b:65:46:77:b8:26:b4:3c:43</code>
+
|-
 +
| DSA || <code>af:97:29:aa:39:85:49:4b:65:46:77:b8:26:b4:3c:43</code> || <code>16:97:50:8a:97:bf:a3:4e:ef:8c:78:9b:4f:c4:73:58</code> || <code>b1:f0:df:5e:71:90:26:cf:37:ca:21:9f:95:b3:28:41</code>
 +
|-
 +
| RSA || <code>91:e3:fc:95:90:93:c5:b8:a5:ac:fc:5a:38:11:dd:ac</code> || <code>17:60:13:d9:c5:fd:4a:86:63:52:3e:63:60:01:5c:e8</code> || <code>51:01:0f:e9:cd:b8:2f:a3:c8:18:9f:e0:a7:d0:e9:8b</code>
 +
|-
 +
| ECDSA || <code>57:88:bd:03:eb:18:84:1d:4f:fd:7b:09:b2:a3:82:15</code> || <code>e7:b0:4f:cf:7d:82:9f:08:cb:e1:a1:9a:9b:0d:10:d0</code> || <code>db:29:13:f0:34:a6:1f:dd:aa:11:30:a5:37:0e:02:18</code>
 +
|}
  
 
Naturalmente non dovreste fidarvi troppo di questi valori perché sono pubblicati su un sito liberamente modificabile, e soprattutto perché sono pubblicati proprio su <code>uz.sns.it</code>: in pratica è il server stesso che sta certificando la propria sicurezza: vi fidereste di qualcuno che dice "io sono affidabile, e lo prova questo documento firmato da me stesso"?
 
Naturalmente non dovreste fidarvi troppo di questi valori perché sono pubblicati su un sito liberamente modificabile, e soprattutto perché sono pubblicati proprio su <code>uz.sns.it</code>: in pratica è il server stesso che sta certificando la propria sicurezza: vi fidereste di qualcuno che dice "io sono affidabile, e lo prova questo documento firmato da me stesso"?
Riga 71: Riga 87:
  
 
Se il vostro client ssh si lamenta perché la ''fingerprint'' del server è cambiata anche dopo la prima connessione, la causa probabilmente è una di queste tre:
 
Se il vostro client ssh si lamenta perché la ''fingerprint'' del server è cambiata anche dopo la prima connessione, la causa probabilmente è una di queste tre:
* avete inserito uno ''hostname'' diverso da <code>ssh.uz.sns.it</code>
+
* avete inserito uno ''hostname'' diverso da <code>ssh.uz.sns.it</code> (oppure <code>ssh1</code> o <code>ssh2</code>);
* gli amministratori hanno reinstallato ssh e cambiato la chiave (non dovrebbe succedere troppo spesso...)
+
* gli amministratori hanno reinstallato ssh e cambiato la chiave (non dovrebbe succedere troppo spesso...);
 
* qualcuno sta cercando di spacciarsi per il server UZ e fregarvi.
 
* qualcuno sta cercando di spacciarsi per il server UZ e fregarvi.
 
In tutti e tre i casi, sarebbe meglio controllare prima di inserire la password...
 
In tutti e tre i casi, sarebbe meglio controllare prima di inserire la password...
 +
 +
Alcune di queste chiavi sono anche ottenibili tramite il sistema [http://web.monkeysphere.info/ MonkeySphere]. Se non sapete di cosa si tratti, ignorate questa informazione.
  
 
== Caveat ==
 
== Caveat ==
Sul server è stato recentemente installato (forse) un programma che blocca le connessioni ssh per un breve lasso di tempo (10 minuti) dopo sette tentativi falliti di login. Si tratta di una misura di sicurezza per tutelarci da chi tenta centinaia di login successivi con password a caso. Speriamo che questa misura non vada a danneggiare eccessivamente gli utenti.
+
Sul server è stato installato un programma che blocca le connessioni ssh per un breve lasso di tempo dopo un certo numero di tentativi di login falliti. Si tratta di una misura di sicurezza per tutelarci da chi tenta centinaia di login successivi con password a caso. Speriamo che questa misura non vada a danneggiare eccessivamente gli utenti. Se ad un certo punto il server SSH inizia a rifiutare le connessioni senza neanche darvi una possibilità di scrivere la password, dovete aspettare qualche minuto. E la prossima volta evitate di sbagliare la password!
  
 
== Cose avanzate ==
 
== Cose avanzate ==
Riga 85: Riga 103:
 
=== Autenticazione a mezzo chiave pubblica ===
 
=== Autenticazione a mezzo chiave pubblica ===
 
Attualmente il metodo di autenticazione mediante chiave pubblica non è disponibile a causa dell'architettura del sistema di autenticazione.
 
Attualmente il metodo di autenticazione mediante chiave pubblica non è disponibile a causa dell'architettura del sistema di autenticazione.
Stiamo lavorando per permettere l'autenticazione tramite Kerberos.
+
È possibile, però, l'autenticazione mediante Kerberos.
 +
 
 +
=== Autenticazione a mezzo di ticket kerberos ===
 +
 
 +
Finalmente è disponibile l'autenticazione mediante kerberos! Ecco le istruzioni
 +
 
 +
==== Linux ====
 +
 
 +
Innanzitutto dovete avere installare un client<ref>o ''cliente'' se siete russi</ref> kerberos, questo dipende dalla distribuzione che state usando, ecco alcuni casi più comuni
 +
 
 +
* Debian: il pacchetto dovrebbe chiamarsi <code>krb5-client</code>, quindi vi basta un bel
 +
:<pre>apt-get install krb5-client</pre>
 +
:(sostituite pure ad aptitude il vostro apt preferito<ref>e.g. aptitude</ref>, ma ricordatevi di eseguirlo come root o almeno di usare sudo)
 +
 
 +
* Ubuntu: anche qui il pacchetto dovrebbe chiamarsi <code>krb5-client</code> e dovrebbe bastare
 +
:<pre>apt-get install krb5-client</pre>
 +
:(sostituite pure ad apt-get il vostro apt preferito, ma ricordatevi di eseguirlo come root o almeno di usare sudo)
 +
 
 +
* Fedora: questa volta il pacchetto si chiama krb5-workstation, per installarlo dovrebbe bastare
 +
:<pre>yum install krb5-workstation</pre>
 +
:(questa procedura non l'ho testata perché non ho voglia di avviare la VM con Fedora, se qualcuno lo facesse poi scriva qui il risultato)
 +
 
 +
* Gentoo: se siete riusciti a installare il SO non dovreste aver problemi, forse questa volta non dovrete nemmeno ricompilare il kernel!
 +
 
 +
* Derivate di debian (e quindi anche di ubuntu) come #!: vedete la sezione debian e ubuntu
 +
 
 +
 
 +
Ora che avete kerberos potete prendervi il vostro ticket quando volete con
 +
 
 +
<pre>kinit vostro_username@UZ.SNS.IT</pre>
 +
 
 +
Mettete la password e avete il ticket! (si possono fare cose più avanzate con keytab e rinnovi automatici, se lo volete fare cercate su google)
 +
 
 +
Ora dovete collegarvi al server, come nome potete usare uno qualunque di quelli disponibili, dovete passare due parametri a ssh: <code>GSSAPIAuthentication yes</code> e <code>GSSAPIDelegateCredentials yes</code>
 +
 
 +
Per farlo avete due metodi:
 +
 
 +
(metodo noioso) quando usate il comando ssh passategli quelle opzioni come argomenti nel seguente modo:
 +
<pre>ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes vostro_username@ssh1.uz.sns.it</pre>
 +
dovete farlo ogni volta che vi collegate
 +
 
 +
(metodo furbo) aggiungete le seguenti righe al vostro file <code>~/.ssh/config</code>
 +
<pre>
 +
Host shortcut
 +
User vostro_user
 +
Port 22
 +
Hostname ssh1.uz.sns.it
 +
GSSAPIAuthentication yes
 +
GSSAPIDelegateCredentials yes
 +
</pre>
 +
così ora quando scriverete <code>ssh shortcut</code> vi collegherete direttamente a <code>ssh1</code> col vostro utente passando anche le opzioni opportune, analogamente potete scrivere una configurazione simile per <code>ssh2</code> e <code>ssh3</code>.
 +
 
 +
Ricordatevi che dopo 10 ore i ticket di kerberos scadono (se non li rinnovate) e comunque li perdete quando spegnete il computer, quindi se non funziona l'autenticazione riprovate a fare <code>kinit</code>
 +
 
 +
In caso di problemi, segnalazioni o suggerimenti rivolgetevi a <code>admin@uz.sns.it</code>
 +
 
 +
==== Windows ====
 +
 
 +
Ma ci sono ancora in giro sfigati che usano windows? Windows? Oh My God!
 +
 
 +
E, nel caso, windows supporta kerberos? Boh!
 +
 
 +
(se qualcuno sa come si fa lo scriva)
 +
 
 +
==== Mac OS X ====
 +
 
 +
Non so se l'autenticazione mediante kerberos sia stata approvata da Steve, quindi non posso scrivere questa sezione (aka non ho davvero voglia di avviare mac os sul mio apple).
 +
 
 +
Comunque forse il metodo descritto per linux funziona, modulo installare kinit
  
 
=== Forwarding di porte ===
 
=== Forwarding di porte ===
 
Vi preghiamo di utilizzarlo solo se non c'è un altra opzione e per brevi periodi, in quanto va a pesare sul carico del server per tutto il tempo per cui resta attivo.
 
Vi preghiamo di utilizzarlo solo se non c'è un altra opzione e per brevi periodi, in quanto va a pesare sul carico del server per tutto il tempo per cui resta attivo.
  
Istruzioni per are un tunnel è piuttosto semplice: per accedere al computer <code>host2</code> porta <code>port2</code> passando dal computer <code>host1</code>, usando la porta locale porta <code>port1</code>:
+
Normalmente questa cosa viene utilizzata per accedere alle riviste scientifiche quando non siete in SNS. Maggiori dettagli su questa operazione sono descritti in un'[[Accedere alle riviste scientifiche fuori dal dipartimento|apposita pagina]].
 +
 
 +
Di seguito trovate le istruzioni per creare un tunnel per accedere al computer <code>host2</code> porta <code>port2</code> passando dal computer <code>host1</code>, usando la porta locale <code>port1</code>:
  
 
''nota: per aprire le porte locali da 0 a 1023 è necessario essere root. Gli utenti possono aprire solo le porte da 1024 a 65535.''
 
''nota: per aprire le porte locali da 0 a 1023 è necessario essere root. Gli utenti possono aprire solo le porte da 1024 a 65535.''
Riga 114: Riga 202:
 
** cliccate Ok->Ok
 
** cliccate Ok->Ok
 
** cliccate File->Connect
 
** cliccate File->Connect
 
=== Utilizzo del forwarding ===
 
Il forwarding delle porte si può utilizzare per accedere ai servizi di linuz ristretti alla rete locale. Ad esempio se ci fosse un sito su polaris sulla porta 4080, per vederlo anche da fuori è sufficiente aprire un tunnel con <code>host1=linuz.sns.it</code>, <code>port1=1234</code>, <code>host2=polaris.uz.sns.it</code>, <code>port2=4080</code>, ed infine collegarsi con un browser alla pagina <code>http://localhost:1234</code>.
 
 
Un altro uso molto comune del forwarding è per [[Accedere_alle_riviste_scientifiche_fuori_dal_dipartimento|accedere alle risorse scientifiche a cui è abbonata la Scuola Normale]]. Ad esempio per accedere al sito http://www.sciencemag.org/ da casa propria, fingendosi dentro la sns, di dovrà aprire un tunnel con <code>host1=linuz.sns.it</code>, <code>port1=1234</code>, <code>host2=www.sciencemag.org</code>, <code>port2=80</code> (nota: tutti i siti internet utilizzano la porta 80, se non diversamente specificato), ed infine collegarsi con un browser alla pagina <code>http://localhost:1234</code>.
 

Versione attuale delle 17:44, 20 set 2019

“Come faccio a forwardare tutte le porte del server UZ sul mio computer?”Oscar Wilde

Il protocollo ssh vi consente di trasferire file dal server UZ al vostro computer e viceversa (consultare SCP e SFTP), e anche di impartire comandi come se foste seduti di fronte al server. Tutte le connessioni sono cifrate.

Parametri generali di connessione

server ssh*.uz.sns.it
nome utente / password quelli del vostro account di UZ
protocollo SSH v2 (quello predefinito, di solito non occorre cambiare nulla)
porta 22 (quella predefinita)
cartella /home/il_vostro_username

Nomi dei server ssh

Abbiamo tre server ssh, di solito collegandovi ad ssh.uz.sns.it (che è un alias per ssh1.uz.sns.it) andate sul sicuro, ma se volete scegliere voi a che server collegarvi esistono anche ssh2.uz.sns.it che si trova al Faedo e ssh3.uz.sns.it che si trova al Timpano. I server ssh e ssh2 sono accessibili anche dall'esterno della rete SNS, mentre ssh3 no. In generale è preferibile usare ssh, ma in caso questo non funzioni è comunque possibile usarne un altro.

Linux

Client ssh testuali (ad esempio openssh)

Digitate
ssh nomeutente@ssh.uz.sns.it
per lanciare una shell su Linuz.

Trasferire file con scp

Digitate
scp nomeutente@ssh.uz.sns.it:/percorso/file/remoto /percorso/file/locale
per copiare un file dal server UZ sul vostro pc. Invertite gli argomenti per copiare un file dal pc locale sul server UZ. Usate lo switch -r per copiare ricorsivamente un'intera cartella.

Trasferire file con Nautilus

Si possono trasferire file utilizzando Nautilus, il file manager grafico integrato in GNOME. Usate File -> Connetti al server e poi gli stessi parametri detti sopra. Potete navigare i file remoti come quelli locali e copiare avanti e indietro in grande allegria.

Trasferire file con Dolphin o Konqueror

Se invece di GNOME usate KDE, allora potete usare Dolphin (il file manager di KDE) opppure Konqueror (il browser di KDE).

Nel caso di Dolphin dovete andate sul pannello della rete (selezionabile a sinistra) e poi "Aggiungi una risorsa di rete" e di nuovo mettete gli stessi parametri di sopra.

Se volete usare Konqueror, aprite una finestra e digitate fish://ssh.uz.sns.it oppure sftp://ssh.uz.sns.it e inserite nome utente e password quando vi viene chiesto. Per qualche motivo strano, fino alla versione 3.3 di KDE (e forse anche con le versioni più recenti) la velocità di trasferimento di Konqueror era più bassa rispetto a quella di scp). Però se usate ancora una versione di KDE minore o uguale di 3.3 non vi meritate proprio niente...

Windows

Riassunto per utenti impazienti

Scaricate WinSCP, installatelo, aprite il programma e collegatevi a ssh.uz.sns.it inserendo il vostro nome utente e password di Linux.

WinSCP

WinSCP, che è software libero, è un ottimo client grafico che vi permette di scambiare file con Linuz via ssh (protocolli SCP e SFTP). Non è in grado di aprire una shell SSH. La configurazione è semplice, badate solo di selezionare il protocollo ssh (porta 22).

Putty

Putty, anch'esso software libero, nonostante il nome discutibile, è un buon client ssh che vi consente di aprire una shell SSH su Linuz e digitare comandi. Non consente di trasferire files. Fanno parte del progetto Putty anche i programmi PSCP, PSFTP e PUTTYgen.

  • Putty: il vero e proprio client ssh. Interfaccia grafica.
  • PSCP: un client di trasferimento files scp. Funziona da riga di comando in DOS, in modo simile a scp in linux.
  • PSFTP: un client di trasferimento files sftp. Funziona da riga di comando in DOS, in modo simile a sftp in linux.
  • PuTTYgen: un arnese utile a maneggiare chiavi rsa e convertirle in formato standard e in formato putty (che è lo stesso di WinSCP)

SSH Secure Shell

SSH Secure Shell, non gratuito, non a sorgente aperto (quindi è il male), è un buon client ssh grafico utile per eseguire comandi, dal costo compreso tra 100 e 200 euro. E' simile a Putty. Una versione vecchia del client è scaricabile gratuitamente dal loro server.

Fa parte del pacchetto anche il programma SSH Secure File Transfer, buon client grafico per scambiare files. E' simile a WinSCP.

Mac

Usate Cyberduck oppure FileZilla.

Android

Scaricate ES Gestore File. Andate sulla scheda "Rete", premete "Nuovo" e poi "sftp". Compilate i campi in questo modo:

server ssh.uz.sns.it/afs/uz.sns.it/user/il_vostro_username/
porta 22 (quella predefinita)
nome utente / password quelli del vostro account di UZ
codifica AUTO

Chiavi

Alla prima connessione i client ssh vi chiedono di verificare la fingerprint della chiave pubblica di UZ: ciò serve per verificare che il server a cui vi state connettendo sia veramente UZ e non un "server falso" creato da un malintenzionato allo scopo di rubare la vostra password (l'eventualità non è poi così impossibile, anzi, se non ci fosse questa verifica sarebbe tecnicamente possibile farlo).

ssh1.uz.sns.it ssh2.uz.sns.it ssh3.uz.sns.it
DSA af:97:29:aa:39:85:49:4b:65:46:77:b8:26:b4:3c:43 16:97:50:8a:97:bf:a3:4e:ef:8c:78:9b:4f:c4:73:58 b1:f0:df:5e:71:90:26:cf:37:ca:21:9f:95:b3:28:41
RSA 91:e3:fc:95:90:93:c5:b8:a5:ac:fc:5a:38:11:dd:ac 17:60:13:d9:c5:fd:4a:86:63:52:3e:63:60:01:5c:e8 51:01:0f:e9:cd:b8:2f:a3:c8:18:9f:e0:a7:d0:e9:8b
ECDSA 57:88:bd:03:eb:18:84:1d:4f:fd:7b:09:b2:a3:82:15 e7:b0:4f:cf:7d:82:9f:08:cb:e1:a1:9a:9b:0d:10:d0 db:29:13:f0:34:a6:1f:dd:aa:11:30:a5:37:0e:02:18

Naturalmente non dovreste fidarvi troppo di questi valori perché sono pubblicati su un sito liberamente modificabile, e soprattutto perché sono pubblicati proprio su uz.sns.it: in pratica è il server stesso che sta certificando la propria sicurezza: vi fidereste di qualcuno che dice "io sono affidabile, e lo prova questo documento firmato da me stesso"? Oltre a questo motivo, forse le chiavi potrebbero cambiare (la configurazione non è ancora stabile).

Se siete particolarmente paranoici o avete motivo di sospettare manomissioni, potete venire a controllare questi valori direttamente nell'aula pc o chiedere conferma a qualcuno di affidabile.

Se il vostro client ssh si lamenta perché la fingerprint del server è cambiata anche dopo la prima connessione, la causa probabilmente è una di queste tre:

  • avete inserito uno hostname diverso da ssh.uz.sns.it (oppure ssh1 o ssh2);
  • gli amministratori hanno reinstallato ssh e cambiato la chiave (non dovrebbe succedere troppo spesso...);
  • qualcuno sta cercando di spacciarsi per il server UZ e fregarvi.

In tutti e tre i casi, sarebbe meglio controllare prima di inserire la password...

Alcune di queste chiavi sono anche ottenibili tramite il sistema MonkeySphere. Se non sapete di cosa si tratti, ignorate questa informazione.

Caveat

Sul server è stato installato un programma che blocca le connessioni ssh per un breve lasso di tempo dopo un certo numero di tentativi di login falliti. Si tratta di una misura di sicurezza per tutelarci da chi tenta centinaia di login successivi con password a caso. Speriamo che questa misura non vada a danneggiare eccessivamente gli utenti. Se ad un certo punto il server SSH inizia a rifiutare le connessioni senza neanche darvi una possibilità di scrivere la password, dovete aspettare qualche minuto. E la prossima volta evitate di sbagliare la password!

Cose avanzate

Forwarding di X

(Linux only) Se avviate ssh con l'opzione da linea di comando -X (occhio che la X è maiuscola), potete lanciare comandi che aprono finestre, come per esempio firefox o konqueror. La finestra verrà aperta sul vostro pc, ma è come se il programma girasse su Linuz. Questo può tornarvi comodo per gestire meglio i file che avete sulla home, o per accedere a siti che consentono l'accesso solo dall'interno della SNS (es. siti di riviste scientifiche a cui la SNS è abbonata).

Autenticazione a mezzo chiave pubblica

Attualmente il metodo di autenticazione mediante chiave pubblica non è disponibile a causa dell'architettura del sistema di autenticazione. È possibile, però, l'autenticazione mediante Kerberos.

Autenticazione a mezzo di ticket kerberos

Finalmente è disponibile l'autenticazione mediante kerberos! Ecco le istruzioni

Linux

Innanzitutto dovete avere installare un client<ref>o cliente se siete russi</ref> kerberos, questo dipende dalla distribuzione che state usando, ecco alcuni casi più comuni

  • Debian: il pacchetto dovrebbe chiamarsi krb5-client, quindi vi basta un bel
apt-get install krb5-client
(sostituite pure ad aptitude il vostro apt preferito<ref>e.g. aptitude</ref>, ma ricordatevi di eseguirlo come root o almeno di usare sudo)
  • Ubuntu: anche qui il pacchetto dovrebbe chiamarsi krb5-client e dovrebbe bastare
apt-get install krb5-client
(sostituite pure ad apt-get il vostro apt preferito, ma ricordatevi di eseguirlo come root o almeno di usare sudo)
  • Fedora: questa volta il pacchetto si chiama krb5-workstation, per installarlo dovrebbe bastare
yum install krb5-workstation
(questa procedura non l'ho testata perché non ho voglia di avviare la VM con Fedora, se qualcuno lo facesse poi scriva qui il risultato)
  • Gentoo: se siete riusciti a installare il SO non dovreste aver problemi, forse questa volta non dovrete nemmeno ricompilare il kernel!
  • Derivate di debian (e quindi anche di ubuntu) come #!: vedete la sezione debian e ubuntu


Ora che avete kerberos potete prendervi il vostro ticket quando volete con

kinit vostro_username@UZ.SNS.IT

Mettete la password e avete il ticket! (si possono fare cose più avanzate con keytab e rinnovi automatici, se lo volete fare cercate su google)

Ora dovete collegarvi al server, come nome potete usare uno qualunque di quelli disponibili, dovete passare due parametri a ssh: GSSAPIAuthentication yes e GSSAPIDelegateCredentials yes

Per farlo avete due metodi:

(metodo noioso) quando usate il comando ssh passategli quelle opzioni come argomenti nel seguente modo:

ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes vostro_username@ssh1.uz.sns.it

dovete farlo ogni volta che vi collegate

(metodo furbo) aggiungete le seguenti righe al vostro file ~/.ssh/config

Host shortcut
User vostro_user
Port 22
Hostname ssh1.uz.sns.it
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

così ora quando scriverete ssh shortcut vi collegherete direttamente a ssh1 col vostro utente passando anche le opzioni opportune, analogamente potete scrivere una configurazione simile per ssh2 e ssh3.

Ricordatevi che dopo 10 ore i ticket di kerberos scadono (se non li rinnovate) e comunque li perdete quando spegnete il computer, quindi se non funziona l'autenticazione riprovate a fare kinit

In caso di problemi, segnalazioni o suggerimenti rivolgetevi a admin@uz.sns.it

Windows

Ma ci sono ancora in giro sfigati che usano windows? Windows? Oh My God!

E, nel caso, windows supporta kerberos? Boh!

(se qualcuno sa come si fa lo scriva)

Mac OS X

Non so se l'autenticazione mediante kerberos sia stata approvata da Steve, quindi non posso scrivere questa sezione (aka non ho davvero voglia di avviare mac os sul mio apple).

Comunque forse il metodo descritto per linux funziona, modulo installare kinit

Forwarding di porte

Vi preghiamo di utilizzarlo solo se non c'è un altra opzione e per brevi periodi, in quanto va a pesare sul carico del server per tutto il tempo per cui resta attivo.

Normalmente questa cosa viene utilizzata per accedere alle riviste scientifiche quando non siete in SNS. Maggiori dettagli su questa operazione sono descritti in un'apposita pagina.

Di seguito trovate le istruzioni per creare un tunnel per accedere al computer host2 porta port2 passando dal computer host1, usando la porta locale port1:

nota: per aprire le porte locali da 0 a 1023 è necessario essere root. Gli utenti possono aprire solo le porte da 1024 a 65535.

da Linux:

  • ssh -L port1:host2:port2 host1
  • per mettere ssh in background, aggiungere -N -f

da Windows:

Serve qualche programmino, il più facile da usare è putty.

  • putty:
    • scaricate putty da questo sito
    • aprite putty e mettete Hostname: host1, Port: 22, Protocol SSH
    • entrate nella scheda Tunnel esempio
    • inserite Sourceport: porta1, Destination: host2:port2, type: Local, e poi click su Add
    • click su Open, inserite username e password linux, e il tunnel è fatto
  • SSH Secure Shell
    • trovate il programma da qualche parte
    • andate su Edit->Settings->Profile Settings->Tunneling
    • selezionate la scheda "Outgoing" e cliccate su "Add..."
    • Display Name: quello che vi pare, Type: TCP, Listen port: port1, Allow local connections only: yes, Destination host: host2, Destination port: port2
    • cliccate Ok->Ok
    • cliccate File->Connect