HexDEF6
13-04-2005, 11:51
ATTENZIONE
Questo mini-howto non ha nessuna pretesa di essere la soluzione a tutti i problemi di sicurezza di una macchina gestita in remoto, ma sono solo "pensieri" che mi sono saltati in mente dopo aver visto bucare alcune macchine dove lavoro.. quindi se avete suggerimenti sono benvenuti!
ATTENZIONE2
Io tengo conto che sulla macchina remota giri solamente il server ssh, non anche un server di telnet o un apache o altro, quindi e' inutile prendere precauzioni paranoiche per il server ssh e poi lasciate l'accesso da root remoto con telnet! inoltre si presume che ci sia un firewall che permetta l'accesso alla sola porta 22 e che tutto il software sia aggiornato (se usate ssh del 1912 di sicuro questo mini howto non vi sara' di aiuto!) quindi non prendero in considerazione altro.
PARTE SERVER
Configurazione1
Normalmente ssh permette l'accesso diretto da root
infatti se guardiamo in /etc/ssh/sshd_config troviamo:
PermitRootLogin yes
e se e' commentato (o non presente) verra' usato il parametro di default (che e' yes).
Questo e' molto comodo, ma nasconde alcune insidie:
alzino la mani quanti di voi controllano giornalmente i log!
diciamo che lo fanno solo quelli che lo fanno per lavoro e ben pochi altri.. magari provate a dare un'occhiata, molte volte si trovane dei tentativi di accesso remoto non autorizzati, questi dovuti ad alcuni tool automatici che tentano di trovare password deboli... regalare il proprio account da root solo perche' non si ha voglia di inserire 2 password non e' bello!
quindi se volete un minimo di sicurezza in piu' dovete:
- usare una password decente (niente cose che si trovano su vocabolari o hanno a che fare con il vostro lavoro, o con voi, e usate almeno 8 caratteri per la password, magari comprendendo qualche numero e simbolo)
- disabilitare il login diretto da root:
PermitRootLogin no
questa configurazione vi da un minimo di sicurezza in piu'
Configurazione2
Se quello che gestite da remoto non e' il vostro desktop personale, ma qualcosa di piu' sostanzioso (da leggersi: se vi craccano siete nella mer*a) il passo successivo e':
- restringere l'accesso a ssh da predeterminati ip riconfigurando iptables (non sempre possibile, se magari volete accedere remotamente ala vostra macchina e vi attaccate ad internet da posti diversi)
- restringere l'uso di ssh solo agli utenti che hanno veramente bisogno di accedere da remoto:
questo viene fatto con la direttiva:
AllowUsers utente1 utente2
in questo modo anche se sulla macchina ci sono 87 account solo utente1 e utente2 potranno loggarsi via ssh (se impostate AllowUsers, anche se lasciate PermitRootLogin su yes, questo non potra' loggarsi),
inoltre con questa direttiva si puo' specificare da dove puo' essere fatto il login:
AllowUsers utente1@* [email protected].*
cosi utente1 puo' loggarsi da tutte le parti del mondo, invece utente2 solo dalla sottorete privata 192.168.0.*
A volte puo' essere comodo usare la direttiva DenyUsers, in questo modo tutti gli utenti della macchina possono loggarsi tranne quelli esplicitamente proibiti da DenyUsers
DenyUsers localuser
in questo modo l'utente localuser puo' loggarsi solamente in locale, la direttiva e' molto comoda per creare degli account di "guest" con password note a tutti, ma impedirne l'utilizzo remoto.
Configurazione3A
Andando nel paranoico, possiamo usare la direttiva AllowUsers per mettere un ulteriore passaggio per avere accesso da root... infatti se usiamo:
AllowUsers utente1@* [email protected] utente2@localhost
e facciamo in modo che utente1 non faccia parte del gruppo wheel (e quindi non possa lanciare il comando su per poter aumentare i propri privilegi)
per poter avere accesso da root dobbiamo fare:
- ssh utente1@server
una volta loggati dovremo fare:
- ssh [email protected]
ed infine
- su
quindi se abbiamo fatto tutto per bene ci sono 3 password prima di poter accedere da root!
Configurazione3B
Siccome il 99% dei casi ci troviamo degli attacchi alla porta 22 portati con tool automatici che fanno un lavoro del tipo:
la porta 22 e' aperta?==> proviamo un po di combinazioni di utenti e password.
una cosa comoda per evitare questi tentativi e' cambiare la porta di default di ssh usando la direttiva:
Port
io consiglio di usare una porta > 2000 visto che alcuni tool fanno automaticamente lo scan delle prime 1024 porte (quelle privilegiate)
Port 2865
ovviamente quando ci si deve collegare bisogna anche specificare la porta:
ssh -p 2865 user@server
Port Knocking
Se il livello di paranoia della configurazione3 non e' sufficente il passo successivo e' quello di usare http://www.zeroflux.org/knock/
cos'e'?
e' un piccolo demone che gira sul vostro server (nel pacchetto e' compreso pure il client knock)
a cosa serve?
serve per aprire la porta 22 (quella dell'ssh) all'indirizzo ip da cui riceve la "bussata"
come funziona?
il demone ascolta sull'interfaccia di rete aspettando di ricevere una particolare "bussata" (la bussata si traduce in pacchetti tcp o udp su alcune porte da voi decise), quando questo succede apre la porta 22 (in verita' lancia uno script che puo' fare qualunque cosa, ma di default lancia iptables in modo che apra la porta 22) al solo indirizzo che ha bussato
cosa comporta?
ad uno scan del vostro server la porta 22 risulta chiusa, e quindi il 99% dei programmini automatici per tentare di trovare le password passera' a rompere le p@lle ad un altro ip lasciandovi in pace!, inoltre aggiunge un altro livello di sicurezza:
anche se qualcuno sapesse che bisogna bussare per aprire la porta 22 dovrebbe conoscere su quante e quali porte bussare, questo si traduce in:
porte usabili per la bussata circa 64000 (in realta' le porte che si possono usare sono 65536, ma togliamo le prime 1024 che sono riservate, e per fare il conto tondo usiamo 64000), quindi se impostiamo 3 porte per la bussata, il "malvivente" che tentera' di trovare queste 3 porte bussando a caso avra' da testare (in media) 64000*64000*64000 / 2 combinazioni, praticamente come avere una password in piu' prima di arrivare al sistema!
controindicazioni?
Le controindicazioni sono nella configurazione del firewall.. dovete stare attenti che inserire una regola in fondo al vostro script non dia problemi... diciamo che non sono di sicuro problemi insormontabili e a volte non ci sono proprio!
L'installazione e' semplicissima (con gentoo basta un emerge knock) e la configurazione altrettanto semplice, basta modificare il file /etc/knockd.conf (non lasciate le 3 porte di default!) e lanciare /etc/init.d/knock start (ovviamente dovete riconfigurare il firewall in modo che di default droppi la porta 22!)
Semplificazioni ok... finalmente qualcosa di utile!
Ok... cosi' vi ho complicato la vita in modo esagerato, quindi eccovi alcune "semplificazioni"
siccome nel 90% dei casi (almeno per me) gestisco le macchine remote dal mio pc personale e' comodo poter usare (in combinazione con una delle configurazioni precedenti) la possibilita' delle chiavi condivise (e quindi niente digitazione di password!):
sul nostro pc (che sara' il client) generiamo le chiavi:
ssh-keygen -t rsa
vi chiedera' dove salvare la chiave privata e pubblica (di solito in ~/.ssh/id_rsa)
vi chiedera' una passphrase, di questa potreste farne anche a meno (ma lo sconsiglio!) e' praticamente una password per poter accedere alla propria chiave privata.
una volta generate le chiavi, copiate la chiave pubblica (che finisce con .pub !!!!) sul server remoto:
scp ~/.ssh/id_rsa.pub utente_ser@server:
una volta copiata, accedete al server remoto:
ssh utente_ser@server:
e copiate la chiave pubblica nel file ~/.ssh/authorized_keys2 (in qualche versione di ssh il file potrebbe essere ~/.ssh/authorized_keys)
cat id_rsa.pub >> .ssh/authorized_keys2
una volta fatto questo potrete loggarvi al server remoto senza digitare alcuna password remota, ma solo la passphrase (se l'avete messa, altrimenti senza digitare niente)..
se avete usato la passphrase puo' venire comodo lanciare ssh-agent e quindi "aggiungere" la vostra passphrase con ssh-add in modo tale che questa vi venga chiesta solamente la prima volta, e non ad ogni tentativo di connessione!
ssh-agent
ssh-add
dovete solamente digitare la vostra passphrase (come detto prima, se avete generato la vostra chiave senza passphrase, questa procedura non serve!)
Infine si puo' fare una semplificazione finale, cioe' poter entrare direttamente da root sulla macchina remota senza usare password:
sul server modificate in questa maniera /etc/ssh/sshd_config:
PermitRootLogin without-password
AllowUsers utente1@* [email protected] utente2@localhost root@ip_del_vostro_pc
io consiglio di fare un collegamento root ==> root e non utente ==> root, quindi sul vostro pc alzate i vostri privilegi e loggatevi da root, quindi generate le chiavi (come sopra descritto... e per favore usate una passphrase!) e poi copiate la chiave pubblica sul server remoto (come descritto sopra)...
In questa maniera potrete loggarvi direttamente da root sulla macchina remota senza usare password!
Il sistema non e' insicuro come si potrebbe pensare perche':
- root puo' loggarsi direttamente con le chiavi, ma NON con la password
- lo puo' fare solamente dal vostro pc (quindi cercate di non farvi craccare il vostro pc, altrimenti avra' il controllo di tutte le macchine!)
ricordatevi che:
-potete "dare in giro" la parte pubblica della vostra chiave senza nessun problema di sicurezza (l'importante e' che la privata rimanga tale!)
-dopo ogni modifica al file sshd_config dovete riavviare il server ssh
-se state riavviando un server ssh remoto pensateci ben 15 volte perche' non sarebbe bello essere esclusi dal proprio sistema (controllate 86 volte sshd_config e poi fatelo controllare anche a qualcun'altro!) comunque vada la connessione attuale non verra' chiusa, quindi prima di uscire provate se tutto funziona perfettamente
-potrei aver scritto qualche cazzata, quindi prima di fare tutto leggetevi le man pages
-non prendetevela con me se dopo tutte le modifiche non funziona niente!!
PARTE CLIENT
Tunnel con ssh
oltre al normale uso per amministrare una macchina remota, ssh puo' essere comodo per fare tunnelling.
ESEMPIO: voglio collegarmi al server vnc sulla macchina 1 (che si trova sulla porta 5903 visto che lo abbiamo lanciato con vncserver -geometry 800x600 :3 ) ma l'unica porta aperta del server e' la 22... abbiamo 2 o 3 opzioni:
- apriamo la porta 5903 del firewall (dobbiamo avere accesso da root alla macchina, e aprire una porta in piu' all'esterno non e' mai un bene!)
- usiamo una vpn (ma anche n questo caso dobbiamo aprire una porta in piu' oltre a dover configurare la vpn e altri problemi)
- facciamo un tunnel ssh
per poter fare un tunnel basta lanciare:
ssh -L 5903:127.0.0.1:5903 user@server
poi da un altro xterm (sempre sul client) lanciamo:
vncviewer 127.0.0.1:3
intanto ricordo che per determinare su che porta sia in ascolto il vnc basta fare 5900 + numero di display usato, analizziamo la riga di comando del client ssh:
-L e' il parametro fondamentale (andate a leggere le man pages!)
nel nostro caso: -L 5903:127.0.0.1:5903 che sta' ad indicare:
ridirigi sulla porta locale 5903 (del client) quello che vedi remotamente (quindi dal punto di vista del server) su 127.0.0.1 alla porta 5903
quindi con ssh possiamo andare ad usare un vnc su una macchina interna ad una LAN, basta avere accesso (via ssh) ad una macchina perimetrale (che abbia un'interfaccia su internet e un'altra sulla LAN)
esempio:
client (IP pubblico 193.205.x.x)===>server ssh(ip pubblico 212.122.x.x)===>macchina con vncserver(ip privato 192.168.0.1)
questo con:
ssh -L 5903:192.168.0.1:5903 [email protected]
ATTENZIONE: normalmente i tunnel ssh vengono usati al posto del collegamento diretto anche perche' in questa maniera il tutto viene passato attraverso ssh e quindi criptato, ma in casi come questo appena visto, il traffico e' criptato fra 193.205.x.x e 212.122.x.x, ma NON tra 212.122.x.x e 192.168.0.1... nel 99% dei casi questo e' poco importante (ci fidiamo di chi sta nella nostra LAN... ma bisogna tenerne conto nell'altro 1% dei casi!)
esempio2:
Se abbiamo un pc (una gentoo!) e dobbiamo fare un emerge sync da un pc che puo' uscire solamente via proxy, ma possiamo appoggiarci ad una macchina periferica (che esce direttamente su internet) possiamo fare:
ssh -L 873:ip_server_rsync:873 user@macchina_periferica
ricordatevi che questo funziona solo da root visto che state ridirigendo una porta privilegiata
poi basta modificare make.conf e dire di usare come server rsync 127.0.0.1
SYNC="rsync://127.0.0.1/gentoo-portage"
alcune note sui tunnel
normalmente se fate un tunnel con ssh, questo sara' disponibile solo per la macchina locale (verificate con un netstat -pl) se invece volete rendere il tunnel disponibile anche ad altre macchine dovete usare l'opzione -g. Quindi se lanciate:
ssh -g -L 5903:192.168.0.1:5903 [email protected]
chiunque (ovviamente se il vostro firewall lo permette!) puo' collegarsi al vncserver remoto usando:
vncviewer 193.205.x.x:3
questa opzione puo' venire comoda, cosi' non serve che tutti aprano un tunnel con ssh, ma si possono appoggiare a quello creato dalla vostra macchina.
Altra utile opzione del client ssh e' -R, per mette di ridirigere una porta di una macchina vista dal client su una porta sul server:
ssh -R 3000:127.0.0.1:22 user@server
in questo modo quando mi collego al server ridirigo la porta ssh del client sulla 3000 del server. Questo puo' venire molto utile per chi ha un ip privato e vuole essere raggiunto dall'esterno (tipo chi ha una connessione con fastweb), ovviamente si ha bisogno di un computer esterno su cui appoggiarsi (tipo un computer di facolta'!)
esempio:
pc1: 192.168.10.20 (rete fastweb o rete aziendale o comunque per qualche motivo avete un ip privato)
pc2: 193.200.X.X
dal pc1 lanciate:
ssh -R 4000:127.0.0.1:22 [email protected]
dopo esservi loggati bisogna ricordarsi che ssh fa cadere la connessione se non passano pacchetti per un po di tempo.. quindi magari potreste lanciare qualcosa del genere:
while [ 1 ]; do echo "Ciao"; sleep 15; done
adesso avete un tunnel stabile (finche' non vi si sconnette internet!)
una volta arrivati al vostro server, potete raggiungere il vostro pc con:
ssh -p 4000 [email protected]
e vi collegate al pc di casa direttamente anche se si trova dietro firewall e con ip privato!
ssh come socks server
sempre nel caso in cui la vostra macchina sia dietro proxy e disponete di un account su una macchina perimetrale che ha pieno accesso ad internet, potete usare ssh come socks server.
Per poter utilizzare questa funzionalita' oltre a ssh dovete avere installato sul vostro computer anche un socks client (gli esempi che faccio tengono conto che venga usato tsocks)
ssh -D 5000 user@macchina_perimetrale
poi configurate tsocks.conf in questa maniera:
#inserite tutte le reti locali
local = 192.168.0.0/255.255.0.0
local = 10.1.0.0/255.255.0.0
#inserite l'ip del server
server = 127.0.0.1
#e la porta
server_port = 5000
poi basta lanciare una qualsiasi applicazione con tsocks esempio:
tsocks mozilla
e navighera senza configurare nessun proxy.
o potete fare un ssh all'esterno:
tsocks ssh user@server_esterno
ssh come vpn
dalla versione 4.3 ssh comprende il supporto per TUN/TAP, in questa maniera si possono andare a creare delle vpn usando il solo ssh! (occhio che e' differente dal port forwarding!)
per poter creare un tunnel bisogna avere la possibilita' di accedere al device /dev/tun0 (da entrambi i capi della vpn)... normalmente questo succede solo per l'utente root, quindi occhio ai permessi! (lanciate ssh con i parametri -vvv per avere un po di info su quello che succede)
per prima cosa bisogna abilitare una voce nell'sshd_config:
PermitTunnel yes
una volta fatto questo (ricordatevi di far ripartire il server ssh) basta lanciare dal client:
ssh -w 0:0 host-remoto
in questa maniera si crea un tunnel tra i due tun0 (sul client e sul server)
adesso bisogna dare un ip alle 2 nuove interfacce di rete:
sul server:
ifconfig tun0 192.168.99.1 netmask 255.255.255.252
sul client
ifconfig tun0 192.168.99.2 netmask 255.255.255.252
in questa maniera si dovrebbero pingare tra di loro...
ma per raggiungere la sottorete interna (lato server) bisogna fare (sul client):
route add -net SOTTORETE_PARTE_SERVER/NETMASK_RELATIVA dev tun0
Ciao
P.S. come detto all'inizio queste sono mie considerazioni, quindi se avete idee, suggerimeti, notate errori ecc. fatemelo sapere!
edit: corrette alcuni errori di scrittura
edit2: inserita la configurazione 3B (la 3A comporta un utente in piu' e in molti casi si considera piu' sicura una macchina con MENO utenti)
edit3: aggiunta l'opzione -g per i tunnel ssh
edit4: aggiunta la possibilita' di creare vpn
todo:
bugfix vari
Questo mini-howto non ha nessuna pretesa di essere la soluzione a tutti i problemi di sicurezza di una macchina gestita in remoto, ma sono solo "pensieri" che mi sono saltati in mente dopo aver visto bucare alcune macchine dove lavoro.. quindi se avete suggerimenti sono benvenuti!
ATTENZIONE2
Io tengo conto che sulla macchina remota giri solamente il server ssh, non anche un server di telnet o un apache o altro, quindi e' inutile prendere precauzioni paranoiche per il server ssh e poi lasciate l'accesso da root remoto con telnet! inoltre si presume che ci sia un firewall che permetta l'accesso alla sola porta 22 e che tutto il software sia aggiornato (se usate ssh del 1912 di sicuro questo mini howto non vi sara' di aiuto!) quindi non prendero in considerazione altro.
PARTE SERVER
Configurazione1
Normalmente ssh permette l'accesso diretto da root
infatti se guardiamo in /etc/ssh/sshd_config troviamo:
PermitRootLogin yes
e se e' commentato (o non presente) verra' usato il parametro di default (che e' yes).
Questo e' molto comodo, ma nasconde alcune insidie:
alzino la mani quanti di voi controllano giornalmente i log!
diciamo che lo fanno solo quelli che lo fanno per lavoro e ben pochi altri.. magari provate a dare un'occhiata, molte volte si trovane dei tentativi di accesso remoto non autorizzati, questi dovuti ad alcuni tool automatici che tentano di trovare password deboli... regalare il proprio account da root solo perche' non si ha voglia di inserire 2 password non e' bello!
quindi se volete un minimo di sicurezza in piu' dovete:
- usare una password decente (niente cose che si trovano su vocabolari o hanno a che fare con il vostro lavoro, o con voi, e usate almeno 8 caratteri per la password, magari comprendendo qualche numero e simbolo)
- disabilitare il login diretto da root:
PermitRootLogin no
questa configurazione vi da un minimo di sicurezza in piu'
Configurazione2
Se quello che gestite da remoto non e' il vostro desktop personale, ma qualcosa di piu' sostanzioso (da leggersi: se vi craccano siete nella mer*a) il passo successivo e':
- restringere l'accesso a ssh da predeterminati ip riconfigurando iptables (non sempre possibile, se magari volete accedere remotamente ala vostra macchina e vi attaccate ad internet da posti diversi)
- restringere l'uso di ssh solo agli utenti che hanno veramente bisogno di accedere da remoto:
questo viene fatto con la direttiva:
AllowUsers utente1 utente2
in questo modo anche se sulla macchina ci sono 87 account solo utente1 e utente2 potranno loggarsi via ssh (se impostate AllowUsers, anche se lasciate PermitRootLogin su yes, questo non potra' loggarsi),
inoltre con questa direttiva si puo' specificare da dove puo' essere fatto il login:
AllowUsers utente1@* [email protected].*
cosi utente1 puo' loggarsi da tutte le parti del mondo, invece utente2 solo dalla sottorete privata 192.168.0.*
A volte puo' essere comodo usare la direttiva DenyUsers, in questo modo tutti gli utenti della macchina possono loggarsi tranne quelli esplicitamente proibiti da DenyUsers
DenyUsers localuser
in questo modo l'utente localuser puo' loggarsi solamente in locale, la direttiva e' molto comoda per creare degli account di "guest" con password note a tutti, ma impedirne l'utilizzo remoto.
Configurazione3A
Andando nel paranoico, possiamo usare la direttiva AllowUsers per mettere un ulteriore passaggio per avere accesso da root... infatti se usiamo:
AllowUsers utente1@* [email protected] utente2@localhost
e facciamo in modo che utente1 non faccia parte del gruppo wheel (e quindi non possa lanciare il comando su per poter aumentare i propri privilegi)
per poter avere accesso da root dobbiamo fare:
- ssh utente1@server
una volta loggati dovremo fare:
- ssh [email protected]
ed infine
- su
quindi se abbiamo fatto tutto per bene ci sono 3 password prima di poter accedere da root!
Configurazione3B
Siccome il 99% dei casi ci troviamo degli attacchi alla porta 22 portati con tool automatici che fanno un lavoro del tipo:
la porta 22 e' aperta?==> proviamo un po di combinazioni di utenti e password.
una cosa comoda per evitare questi tentativi e' cambiare la porta di default di ssh usando la direttiva:
Port
io consiglio di usare una porta > 2000 visto che alcuni tool fanno automaticamente lo scan delle prime 1024 porte (quelle privilegiate)
Port 2865
ovviamente quando ci si deve collegare bisogna anche specificare la porta:
ssh -p 2865 user@server
Port Knocking
Se il livello di paranoia della configurazione3 non e' sufficente il passo successivo e' quello di usare http://www.zeroflux.org/knock/
cos'e'?
e' un piccolo demone che gira sul vostro server (nel pacchetto e' compreso pure il client knock)
a cosa serve?
serve per aprire la porta 22 (quella dell'ssh) all'indirizzo ip da cui riceve la "bussata"
come funziona?
il demone ascolta sull'interfaccia di rete aspettando di ricevere una particolare "bussata" (la bussata si traduce in pacchetti tcp o udp su alcune porte da voi decise), quando questo succede apre la porta 22 (in verita' lancia uno script che puo' fare qualunque cosa, ma di default lancia iptables in modo che apra la porta 22) al solo indirizzo che ha bussato
cosa comporta?
ad uno scan del vostro server la porta 22 risulta chiusa, e quindi il 99% dei programmini automatici per tentare di trovare le password passera' a rompere le p@lle ad un altro ip lasciandovi in pace!, inoltre aggiunge un altro livello di sicurezza:
anche se qualcuno sapesse che bisogna bussare per aprire la porta 22 dovrebbe conoscere su quante e quali porte bussare, questo si traduce in:
porte usabili per la bussata circa 64000 (in realta' le porte che si possono usare sono 65536, ma togliamo le prime 1024 che sono riservate, e per fare il conto tondo usiamo 64000), quindi se impostiamo 3 porte per la bussata, il "malvivente" che tentera' di trovare queste 3 porte bussando a caso avra' da testare (in media) 64000*64000*64000 / 2 combinazioni, praticamente come avere una password in piu' prima di arrivare al sistema!
controindicazioni?
Le controindicazioni sono nella configurazione del firewall.. dovete stare attenti che inserire una regola in fondo al vostro script non dia problemi... diciamo che non sono di sicuro problemi insormontabili e a volte non ci sono proprio!
L'installazione e' semplicissima (con gentoo basta un emerge knock) e la configurazione altrettanto semplice, basta modificare il file /etc/knockd.conf (non lasciate le 3 porte di default!) e lanciare /etc/init.d/knock start (ovviamente dovete riconfigurare il firewall in modo che di default droppi la porta 22!)
Semplificazioni ok... finalmente qualcosa di utile!
Ok... cosi' vi ho complicato la vita in modo esagerato, quindi eccovi alcune "semplificazioni"
siccome nel 90% dei casi (almeno per me) gestisco le macchine remote dal mio pc personale e' comodo poter usare (in combinazione con una delle configurazioni precedenti) la possibilita' delle chiavi condivise (e quindi niente digitazione di password!):
sul nostro pc (che sara' il client) generiamo le chiavi:
ssh-keygen -t rsa
vi chiedera' dove salvare la chiave privata e pubblica (di solito in ~/.ssh/id_rsa)
vi chiedera' una passphrase, di questa potreste farne anche a meno (ma lo sconsiglio!) e' praticamente una password per poter accedere alla propria chiave privata.
una volta generate le chiavi, copiate la chiave pubblica (che finisce con .pub !!!!) sul server remoto:
scp ~/.ssh/id_rsa.pub utente_ser@server:
una volta copiata, accedete al server remoto:
ssh utente_ser@server:
e copiate la chiave pubblica nel file ~/.ssh/authorized_keys2 (in qualche versione di ssh il file potrebbe essere ~/.ssh/authorized_keys)
cat id_rsa.pub >> .ssh/authorized_keys2
una volta fatto questo potrete loggarvi al server remoto senza digitare alcuna password remota, ma solo la passphrase (se l'avete messa, altrimenti senza digitare niente)..
se avete usato la passphrase puo' venire comodo lanciare ssh-agent e quindi "aggiungere" la vostra passphrase con ssh-add in modo tale che questa vi venga chiesta solamente la prima volta, e non ad ogni tentativo di connessione!
ssh-agent
ssh-add
dovete solamente digitare la vostra passphrase (come detto prima, se avete generato la vostra chiave senza passphrase, questa procedura non serve!)
Infine si puo' fare una semplificazione finale, cioe' poter entrare direttamente da root sulla macchina remota senza usare password:
sul server modificate in questa maniera /etc/ssh/sshd_config:
PermitRootLogin without-password
AllowUsers utente1@* [email protected] utente2@localhost root@ip_del_vostro_pc
io consiglio di fare un collegamento root ==> root e non utente ==> root, quindi sul vostro pc alzate i vostri privilegi e loggatevi da root, quindi generate le chiavi (come sopra descritto... e per favore usate una passphrase!) e poi copiate la chiave pubblica sul server remoto (come descritto sopra)...
In questa maniera potrete loggarvi direttamente da root sulla macchina remota senza usare password!
Il sistema non e' insicuro come si potrebbe pensare perche':
- root puo' loggarsi direttamente con le chiavi, ma NON con la password
- lo puo' fare solamente dal vostro pc (quindi cercate di non farvi craccare il vostro pc, altrimenti avra' il controllo di tutte le macchine!)
ricordatevi che:
-potete "dare in giro" la parte pubblica della vostra chiave senza nessun problema di sicurezza (l'importante e' che la privata rimanga tale!)
-dopo ogni modifica al file sshd_config dovete riavviare il server ssh
-se state riavviando un server ssh remoto pensateci ben 15 volte perche' non sarebbe bello essere esclusi dal proprio sistema (controllate 86 volte sshd_config e poi fatelo controllare anche a qualcun'altro!) comunque vada la connessione attuale non verra' chiusa, quindi prima di uscire provate se tutto funziona perfettamente
-potrei aver scritto qualche cazzata, quindi prima di fare tutto leggetevi le man pages
-non prendetevela con me se dopo tutte le modifiche non funziona niente!!
PARTE CLIENT
Tunnel con ssh
oltre al normale uso per amministrare una macchina remota, ssh puo' essere comodo per fare tunnelling.
ESEMPIO: voglio collegarmi al server vnc sulla macchina 1 (che si trova sulla porta 5903 visto che lo abbiamo lanciato con vncserver -geometry 800x600 :3 ) ma l'unica porta aperta del server e' la 22... abbiamo 2 o 3 opzioni:
- apriamo la porta 5903 del firewall (dobbiamo avere accesso da root alla macchina, e aprire una porta in piu' all'esterno non e' mai un bene!)
- usiamo una vpn (ma anche n questo caso dobbiamo aprire una porta in piu' oltre a dover configurare la vpn e altri problemi)
- facciamo un tunnel ssh
per poter fare un tunnel basta lanciare:
ssh -L 5903:127.0.0.1:5903 user@server
poi da un altro xterm (sempre sul client) lanciamo:
vncviewer 127.0.0.1:3
intanto ricordo che per determinare su che porta sia in ascolto il vnc basta fare 5900 + numero di display usato, analizziamo la riga di comando del client ssh:
-L e' il parametro fondamentale (andate a leggere le man pages!)
nel nostro caso: -L 5903:127.0.0.1:5903 che sta' ad indicare:
ridirigi sulla porta locale 5903 (del client) quello che vedi remotamente (quindi dal punto di vista del server) su 127.0.0.1 alla porta 5903
quindi con ssh possiamo andare ad usare un vnc su una macchina interna ad una LAN, basta avere accesso (via ssh) ad una macchina perimetrale (che abbia un'interfaccia su internet e un'altra sulla LAN)
esempio:
client (IP pubblico 193.205.x.x)===>server ssh(ip pubblico 212.122.x.x)===>macchina con vncserver(ip privato 192.168.0.1)
questo con:
ssh -L 5903:192.168.0.1:5903 [email protected]
ATTENZIONE: normalmente i tunnel ssh vengono usati al posto del collegamento diretto anche perche' in questa maniera il tutto viene passato attraverso ssh e quindi criptato, ma in casi come questo appena visto, il traffico e' criptato fra 193.205.x.x e 212.122.x.x, ma NON tra 212.122.x.x e 192.168.0.1... nel 99% dei casi questo e' poco importante (ci fidiamo di chi sta nella nostra LAN... ma bisogna tenerne conto nell'altro 1% dei casi!)
esempio2:
Se abbiamo un pc (una gentoo!) e dobbiamo fare un emerge sync da un pc che puo' uscire solamente via proxy, ma possiamo appoggiarci ad una macchina periferica (che esce direttamente su internet) possiamo fare:
ssh -L 873:ip_server_rsync:873 user@macchina_periferica
ricordatevi che questo funziona solo da root visto che state ridirigendo una porta privilegiata
poi basta modificare make.conf e dire di usare come server rsync 127.0.0.1
SYNC="rsync://127.0.0.1/gentoo-portage"
alcune note sui tunnel
normalmente se fate un tunnel con ssh, questo sara' disponibile solo per la macchina locale (verificate con un netstat -pl) se invece volete rendere il tunnel disponibile anche ad altre macchine dovete usare l'opzione -g. Quindi se lanciate:
ssh -g -L 5903:192.168.0.1:5903 [email protected]
chiunque (ovviamente se il vostro firewall lo permette!) puo' collegarsi al vncserver remoto usando:
vncviewer 193.205.x.x:3
questa opzione puo' venire comoda, cosi' non serve che tutti aprano un tunnel con ssh, ma si possono appoggiare a quello creato dalla vostra macchina.
Altra utile opzione del client ssh e' -R, per mette di ridirigere una porta di una macchina vista dal client su una porta sul server:
ssh -R 3000:127.0.0.1:22 user@server
in questo modo quando mi collego al server ridirigo la porta ssh del client sulla 3000 del server. Questo puo' venire molto utile per chi ha un ip privato e vuole essere raggiunto dall'esterno (tipo chi ha una connessione con fastweb), ovviamente si ha bisogno di un computer esterno su cui appoggiarsi (tipo un computer di facolta'!)
esempio:
pc1: 192.168.10.20 (rete fastweb o rete aziendale o comunque per qualche motivo avete un ip privato)
pc2: 193.200.X.X
dal pc1 lanciate:
ssh -R 4000:127.0.0.1:22 [email protected]
dopo esservi loggati bisogna ricordarsi che ssh fa cadere la connessione se non passano pacchetti per un po di tempo.. quindi magari potreste lanciare qualcosa del genere:
while [ 1 ]; do echo "Ciao"; sleep 15; done
adesso avete un tunnel stabile (finche' non vi si sconnette internet!)
una volta arrivati al vostro server, potete raggiungere il vostro pc con:
ssh -p 4000 [email protected]
e vi collegate al pc di casa direttamente anche se si trova dietro firewall e con ip privato!
ssh come socks server
sempre nel caso in cui la vostra macchina sia dietro proxy e disponete di un account su una macchina perimetrale che ha pieno accesso ad internet, potete usare ssh come socks server.
Per poter utilizzare questa funzionalita' oltre a ssh dovete avere installato sul vostro computer anche un socks client (gli esempi che faccio tengono conto che venga usato tsocks)
ssh -D 5000 user@macchina_perimetrale
poi configurate tsocks.conf in questa maniera:
#inserite tutte le reti locali
local = 192.168.0.0/255.255.0.0
local = 10.1.0.0/255.255.0.0
#inserite l'ip del server
server = 127.0.0.1
#e la porta
server_port = 5000
poi basta lanciare una qualsiasi applicazione con tsocks esempio:
tsocks mozilla
e navighera senza configurare nessun proxy.
o potete fare un ssh all'esterno:
tsocks ssh user@server_esterno
ssh come vpn
dalla versione 4.3 ssh comprende il supporto per TUN/TAP, in questa maniera si possono andare a creare delle vpn usando il solo ssh! (occhio che e' differente dal port forwarding!)
per poter creare un tunnel bisogna avere la possibilita' di accedere al device /dev/tun0 (da entrambi i capi della vpn)... normalmente questo succede solo per l'utente root, quindi occhio ai permessi! (lanciate ssh con i parametri -vvv per avere un po di info su quello che succede)
per prima cosa bisogna abilitare una voce nell'sshd_config:
PermitTunnel yes
una volta fatto questo (ricordatevi di far ripartire il server ssh) basta lanciare dal client:
ssh -w 0:0 host-remoto
in questa maniera si crea un tunnel tra i due tun0 (sul client e sul server)
adesso bisogna dare un ip alle 2 nuove interfacce di rete:
sul server:
ifconfig tun0 192.168.99.1 netmask 255.255.255.252
sul client
ifconfig tun0 192.168.99.2 netmask 255.255.255.252
in questa maniera si dovrebbero pingare tra di loro...
ma per raggiungere la sottorete interna (lato server) bisogna fare (sul client):
route add -net SOTTORETE_PARTE_SERVER/NETMASK_RELATIVA dev tun0
Ciao
P.S. come detto all'inizio queste sono mie considerazioni, quindi se avete idee, suggerimeti, notate errori ecc. fatemelo sapere!
edit: corrette alcuni errori di scrittura
edit2: inserita la configurazione 3B (la 3A comporta un utente in piu' e in molti casi si considera piu' sicura una macchina con MENO utenti)
edit3: aggiunta l'opzione -g per i tunnel ssh
edit4: aggiunta la possibilita' di creare vpn
todo:
bugfix vari