slide presentazione openssh
This commit is contained in:
parent
e09f253f0b
commit
b020238da7
34
README.md
34
README.md
|
|
@ -1,3 +1,35 @@
|
|||
# presentazione-openssh
|
||||
|
||||
presentazione ssh for punkish
|
||||
Presentazione corso base openssh: *ssh for punkish*
|
||||
|
||||
* [punkish-slide](punkish-slide.md)
|
||||
|
||||
il Corso, anche denominato: Log and destroy è parte degli: **Elementi base di
|
||||
remotica**, per le connessioni sicure telematiche, ed è avvenuto un giovedì 16
|
||||
di luglio 2020 in situazione di lontananza, con connessione remota crittata,
|
||||
in contesto pandemico, con la giusta distanza (mai-te) e il morale alto.
|
||||
|
||||
Unit hacklab è entità suscettibile e riconosciuta, quando senza mascherina,
|
||||
dall'ente di promozione isolamento & B.S.D.A.P. le Belle Serate Davanti Al Pc,
|
||||
e aderente al sistema di qualifica S.N.A.P. I diplomi non rilasciati sono
|
||||
esclusivamente disconosciuti e anziché deplorati da qualsivoglia ente affiancato
|
||||
e non garantiscono un bel nulla, in barba alle agevolazioni di legge, le
|
||||
normative vigenti e le consuetudini del convento.
|
||||
Il corso ssh for punkish è propedeutico a quello della Frombola.
|
||||
|
||||
Per la scrittura di questa slide è stato usato il formato *markdown*
|
||||
|
||||
editor-of-choice punkish-slide.md
|
||||
|
||||
Per la presentazione è stato usato *mdp*
|
||||
|
||||
mdp punkish-slide.md
|
||||
|
||||
Per la visione remota è stato usato *tmate*
|
||||
|
||||
tmate
|
||||
|
||||
Link
|
||||
|
||||
**https://git.abbiamoundominio.org/dan/presentazione-openssh**
|
||||
|
||||
|
|
|
|||
809
punkish-slide.md
Normal file
809
punkish-slide.md
Normal file
|
|
@ -0,0 +1,809 @@
|
|||
%title: ssh for punkish
|
||||
%author: dan, 2020-07-16
|
||||
|
||||
# la Remotica
|
||||
|
||||
ssh serve a collegarsi a una macchina remota, via terminale, su cui si ha un account
|
||||
(ma non solo)
|
||||
|
||||
`ssh user@macchina` (si mette la password di user) e oplà si è sulla macchina,
|
||||
dove si potranno usare programmi, far partire processi, ma anche spegnerla.
|
||||
|
||||
La particolarità di ssh, rispetto telnet, è che la comunicazione è crittata.
|
||||
|
||||
ssh permette una shell (interfaccia) sulla macchina cui ci si collega.
|
||||
|
||||
L'insieme dei software openssh si integrano in numerosi programmi anche grafici.
|
||||
|
||||
---
|
||||
|
||||
ssh ha lo scopo di permettere connessioni sicure da e verso il proprio computer,
|
||||
e non è azzardato dire che il suo uso rappresenta la rottura di un digital divide.
|
||||
|
||||
Alcune cose da sapere:
|
||||
|
||||
- occorre generare una fingerprint (ci pensa il pc all'installazione di ssh)
|
||||
- occorre configurare, per comodità, un file di configurazione ssh
|
||||
- occorrono delle nozioni base di unix e di telematica (permessi, hostname, reti)
|
||||
- normalmente la connessione via ssh avviene con scambio password
|
||||
(crittazione simmetrica)
|
||||
ma si può implementare, usando ssh-agent, lo scambio chiavi senza password
|
||||
(crittazione asimmetrica)
|
||||
|
||||
---
|
||||
|
||||
# Esempio di uso con screen manager
|
||||
|
||||
Usare ssh in concomitanza con uno screen manager, come screen o tmux, permette
|
||||
di scollegarsi lasciando andare il programma e di ricollegarsi in seguito.
|
||||
|
||||
un esempio con screen:
|
||||
|
||||
`ssh itara@altrove`
|
||||
|
||||
`screen`
|
||||
|
||||
`weechat` (un IRC client testuale)
|
||||
|
||||
scollegamento da screen (C-a C-d)
|
||||
|
||||
`exit`
|
||||
|
||||
(tempo dopo, magari da un'altra postazione)
|
||||
|
||||
`ssh itara@altrove`
|
||||
|
||||
`screen -r`
|
||||
|
||||
per ricollegarmi a screen e ritrovare weechat.
|
||||
|
||||
---
|
||||
|
||||
# Secure SHell (SSH)
|
||||
|
||||
SSH è un protocollo di rete per interfacciarsi (collegarsi) in modo sicuro
|
||||
a un'altra macchina.
|
||||
^
|
||||
|
||||
SSH è come il teletrasporto. *Beam me up, Scotty!*
|
||||
^
|
||||
|
||||
SSH è come la proiezione astrale.
|
||||
|
||||
---
|
||||
|
||||
Una *shell*, in italiano *conchiglia*, è un ambiente, un ecosistema o in questo caso
|
||||
un'interfaccia su una macchina.
|
||||
^
|
||||
|
||||
*OPENSSH* è un insieme di diversi software per effettuare una connessione tra pc
|
||||
secondo la logica client-server.
|
||||
^
|
||||
|
||||
SSH è sicura, crittografata, leggera e versatile (si può usare per farci passare
|
||||
dentro qualsiasi comunicazione al server) e già presente su tutti i sistemi operativi
|
||||
Unices-like, tra cui GNU/Linux, BSD e MacOSX.
|
||||
|
||||
Windows no (Windows fa schifo).
|
||||
Update: Windows 10 ha incorporato SSH (ma fa schifo uguale).
|
||||
|
||||
---
|
||||
|
||||
# Cosa vuol dire ssh? secure shell
|
||||
|
||||
Foneticamente ssh suona come "ssshhh", il rumore che si fa mettendo un dito davanti
|
||||
alla bocca per invitare a tenere un segreto.
|
||||
|
||||
---
|
||||
|
||||
# Piccola storia di ssh
|
||||
|
||||
Esiste dal 1995 ed è stato creata per non far passare password in chiaro durante una
|
||||
connessione tra pc (cioè per rimpiazzare telnet).
|
||||
|
||||
Si usa oggi come software nella versione chiamata *OpenSSH*, mantenuta dagli
|
||||
sviluppatori del sistema operativo OpenBSD.
|
||||
|
||||
---
|
||||
|
||||
# Installare ssh
|
||||
|
||||
Se non è già presente, occorrerà installare openssh (client-server).
|
||||
|
||||
Per Debian-based-OS: (tra cui Debian, Bunsen Labs, Linux Mint, Ubuntu)
|
||||
|
||||
`apt install ssh`
|
||||
|
||||
---
|
||||
|
||||
# Uso
|
||||
|
||||
Un collegamento dell'utente Telemaco alla macchina remota di nome Altrove
|
||||
|
||||
`ssh telemaco@altrove`
|
||||
^
|
||||
|
||||
se volessi leggere cosa succede (verbose mode)
|
||||
|
||||
`ssh -v telemaco@altrove`
|
||||
|
||||
o anche -vv o -vvv per più verbosità.
|
||||
|
||||
---
|
||||
|
||||
# A cosa serve
|
||||
|
||||
SSH serve principalmente per collegarsi (per fare login) in modo sicuro su un'altra
|
||||
macchina e per fare un tunnel crittografico dove incapsulare una trasmissione dati.
|
||||
^
|
||||
|
||||
Tutto il traffico tra le due macchine viene crittografato e ciò riduce moltissimo il
|
||||
rischio di essere sorvegliate o intercettati.
|
||||
^
|
||||
|
||||
SSH può creare dei tunnel dove far passare qualsiasi servizio di rete, può forwardare
|
||||
(girare) delle porte TCP e delle connessioni X11, e trasferire file.
|
||||
^
|
||||
|
||||
Cominciamo dal login: `ssh nome@macchina` e mi teletrasporto
|
||||
^
|
||||
|
||||
..ma aspetta, si fa in fretta a dire: "macchina".
|
||||
|
||||
---
|
||||
|
||||
# localhost, remotehost
|
||||
|
||||
ssh si usa in soggettiva: parto da me (localhost)
|
||||
^
|
||||
|
||||
*localhost* è "casa", la macchina su cui siedo,
|
||||
si trova per convenzione sempre all'indirizzo IP: 127.0.0.1
|
||||
Se il suo hostname è settato, si può anche chiamarla per nome
|
||||
^
|
||||
|
||||
*remotehost* è una macchina remota,
|
||||
se è raggiungibile si trova a un indirizzo IP
|
||||
Potrebbe avere assegnato un nome di dominio
|
||||
^
|
||||
|
||||
Ad esempio il pc da cui scrivo si chiama *querencia*,
|
||||
la posso raggiungere (partendo da me) chiamandola:
|
||||
*querencia*, *localhost* o *127.0.0.1*
|
||||
^
|
||||
|
||||
Altro esempio, la macchina di unit hacklab si chiama *zaphoda*,
|
||||
la posso raggiungere chiamandola come:
|
||||
*zaphoda*, *abbiamoundominio.org* o *51.68.188.232*
|
||||
|
||||
---
|
||||
|
||||
# Una macchina remota, detta anche server
|
||||
|
||||
(dove si scoprirà che sono il server di me stess*)
|
||||
^
|
||||
|
||||
Il primo problema, per provare ssh, è avere una macchina a cui collegarsi.
|
||||
|
||||
1. Ideale sarebbe avere un secondo Pc acceso
|
||||
^
|
||||
2. Oppure avere un account su qualche macchina in rete
|
||||
^
|
||||
3. Oppure collegarsi alla propria macchina
|
||||
^
|
||||
|
||||
proviamo la 3: `ssh 127.0.0.1`
|
||||
|
||||
(127.0.0.1 e localhost sono termini interscambiabili per: la macchina da cui parto).
|
||||
|
||||
ma prima, due parole sulle porte.
|
||||
|
||||
---
|
||||
|
||||
# Le porte
|
||||
|
||||
Le porte indicano, in telematica, il punto d'arrivo di una comunicazione.
|
||||
|
||||
È una traduzione dall'inglese "port", potevano chiamarle "porti" o approdi.
|
||||
o anche "etichette"
|
||||
^
|
||||
|
||||
*Esempio di una porta: la porta 21, dove vive FTP*
|
||||
|
||||
Una macchina ha dei processi che ascoltano in attesa di connessione su una "porta".
|
||||
Usando diverse porte, servizi diversi sulla stessa macchina allo stesso
|
||||
indirizzo e stessa interfaccia di rete possono coesistere.
|
||||
^
|
||||
|
||||
Collegandosi a Zaphoda con un navigatore senza specificare nessuna porta, il
|
||||
navigatore sceglierà la porta 80 (quella default del web, http), ma lì troverà nginx
|
||||
(il nostro software che gestisce il web) che lo rimanderà alla porta 443 (quella
|
||||
default del web crittato, ossia https.) Perché crittato è meglio che in chiaro.
|
||||
`http://abbiamoundominio.org`
|
||||
^
|
||||
|
||||
Ma collegandosi a Zaphoda specificando la porta 8000, nginx ci spedirà
|
||||
all'interfaccia web di icecast (che appunto usa la porta 8000)
|
||||
`http://abbiamoundominio.org:8000`
|
||||
|
||||
---
|
||||
|
||||
# Le porte (quante sono)
|
||||
|
||||
Le porte possibili sono infinite, ma le prime 1024 sono assegnate a servizi "noti".
|
||||
Dunque nel creare un nuovo servizio, meglio usare una porta "non-privilegiata",
|
||||
ossia dalla 1024 in su, come ad esempio la 51740.
|
||||
^
|
||||
|
||||
Nota: perché un servizio su una macchina sia raggiungibile da fuori,
|
||||
bisognerà che il firewall permetta l'accesso a quella porta.
|
||||
|
||||
**SSH usa di default la porta 22**
|
||||
|
||||
Nota: cambiare una porta senza altri motivi, viene chiamata: Sicurezza tramite oscurità.
|
||||
|
||||
---
|
||||
|
||||
# hostname, indirizzo IP, nome dominio
|
||||
|
||||
Scrivendo solo `ssh zaphoda` probabilmente non funziona.
|
||||
^
|
||||
|
||||
*zaphoda* è il nome (hostname) della macchina,
|
||||
la quale ha un indirizzo IP fisso: *51.68.188.232*
|
||||
e siccome abbiamo affittato un dominio, è raggiungibile a: *abbiamoundominio.org*
|
||||
^
|
||||
|
||||
Devo specificare esplicitamente chi sono, cosa voglio e dove voglio andare.
|
||||
|
||||
Posso dunque scrivere:
|
||||
`ssh -l dan 51.68.188.232` o anche `ssh dan@51.68.188.232`
|
||||
|
||||
oppure `ssh dan@abbiamoundominio.org`
|
||||
^
|
||||
|
||||
è possibile specificare le coordinate di una macchina nel file di configurazione di ssh.
|
||||
|
||||
---
|
||||
|
||||
# I file di configurazione di ssh
|
||||
|
||||
I file di configurazione di ssh vivono nella cartella ~/.ssh/
|
||||
^
|
||||
|
||||
`ls -l ~/.ssh`
|
||||
|
||||
- *config*
|
||||
- known_hosts
|
||||
- id_rsa-zaphoda
|
||||
- id_rsa-zaphoda.pub
|
||||
|
||||
Vengono creati al primo utilizzo di ssh, la configurazione *(config)* può essere editata.
|
||||
^
|
||||
|
||||
Un file esempio *config* contiene:
|
||||
|
||||
`cat ~/.ssh/config`
|
||||
|
||||
> Host fattanza
|
||||
> Hostname 192.168.4.42
|
||||
> User kodi
|
||||
> Port 50022
|
||||
^
|
||||
|
||||
Fattanza è una macchina su una rete interna e usa la porta 50022 con utente kodi
|
||||
|
||||
Avendo specificato nome, utente, porta e IP nel file config,
|
||||
per ottenere lo stesso risultato di:
|
||||
`ssh -p 50022 -l kodi 192.168.4.42`
|
||||
posso più semplicemente usare:
|
||||
`ssh fattanza`
|
||||
|
||||
---
|
||||
|
||||
# Zaphoda nel file di configurazione di ssh
|
||||
|
||||
> Host zaphoda
|
||||
> HostName abbiamoundominio.org
|
||||
> User dan
|
||||
> Port 22
|
||||
> ProxyCommand socat - SOCKS4A:localhost:abbiamoundominio.org:22,socksport=9050
|
||||
> IdentitiesOnly yes
|
||||
> IdentityFile ~/.ssh/id_rsa-zaphoda
|
||||
|
||||
Zaphoda è una macchina chiamata con il suo nome di dominio,
|
||||
il collegamento avviene con un tunnel via Tor (che sta già girando in localhost),
|
||||
usa utente dan con una chiave privata *id_rsa-zaphoda* per l'autenticazione,
|
||||
e la porta 22 (essendo il default non c'era bisogno di specificarla).
|
||||
^
|
||||
|
||||
È utile editare il proprio file di configurazione ssh con le informazioni su
|
||||
le macchine in uso, in modo da non dover scrivere ogni volta un lungo incantesimo.
|
||||
^
|
||||
|
||||
È anche una buona cosa fare un backup di questo file di configurazione.
|
||||
(ma fai un backup di /home/ e la vita ti sorriderà).
|
||||
|
||||
---
|
||||
|
||||
# Primo collegamento: collegarsi in ssh a localhost
|
||||
|
||||
Eccoci di ritorno al collegamento sulla macchina locale
|
||||
|
||||
`ls -l ~/.ssh`
|
||||
|
||||
- config
|
||||
- *known_hosts*
|
||||
- id_rsa-zaphoda
|
||||
- id_rsa-zaphoda.pub
|
||||
|
||||
Ad ogni collegamento, ssh tiene traccia della fingerprint del server con una
|
||||
riga nel file *known_hosts*.
|
||||
^
|
||||
|
||||
`ssh 127.0.0.1`
|
||||
|
||||
> The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
|
||||
> ECDSA key fingerprint is SHA256:xso0+Jusafdf3YJhappydaysf3Eb5cTh6P2QCvRZfs.
|
||||
> Are you sure you want to continue connecting (yes/no)?
|
||||
^
|
||||
|
||||
`yes`
|
||||
^
|
||||
|
||||
> Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
|
||||
^
|
||||
|
||||
l'indirizzo 127.0.0.1 è stato aggiunto al file *~/.ssh/known_host*
|
||||
|
||||
E al prossimo collegamento allo stesso indirizzo, non lo farà più notare,
|
||||
a meno che la fingerprint non coincida.
|
||||
In quel caso, dirà che qualcosa è andato storto.
|
||||
|
||||
---
|
||||
|
||||
# Qualcosa è andato storto
|
||||
^
|
||||
|
||||
`ssh 127.0.0.1`
|
||||
^
|
||||
|
||||
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
|
||||
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
|
||||
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
|
||||
> It is also possible that a host key has just been changed.
|
||||
> The fingerprint for the RSA key sent by the remote host is
|
||||
> SHA256:OyNcagUr5ynfsfxdciaosonoilmagopinolvGaUdlRJSxaxxmiDDtsHwf5gQc.
|
||||
> Please contact your system administrator.
|
||||
> Add correct host key in /home/dan/.ssh/known_hosts to get rid of this message.
|
||||
> Offending RSA key in /home/dan/.ssh/known_hosts:2
|
||||
> remove with:
|
||||
> ssh-keygen -f "/home/dan/.ssh/known_hosts" -R "127.0.0.1"
|
||||
> RSA host key for 127.0.0.1 has changed and you have requested strict checking.
|
||||
> Host key verification failed.
|
||||
|
||||
---
|
||||
|
||||
# Qualcosa è andato storto (cosa fare?)
|
||||
|
||||
Qui delle due l'una:
|
||||
|
||||
o io _credo_ di collegarmi alla macchina 127.0.0.1 mentre in realtà qualcuno o
|
||||
qualcosa si è messo in mezzo. La fingerprint della macchina non coincide
|
||||
con quella che avevo registrato al precedente collegamento.
|
||||
|
||||
Ahimé, i Man in Black mi hanno trovato. Stacca, stacca! [1]
|
||||
^
|
||||
|
||||
Oppure dall'ultima volta che mi sono collegato alla macchina 127.0.0.1 è stato
|
||||
reinstallato il sistema operativo, generando una nuova fingerprint che non
|
||||
coincide con quella precedente, registrata da known_host.
|
||||
^
|
||||
|
||||
Sono stato avvisat* e ho tre possibilità:
|
||||
|
||||
* contattare l'amministratore (ma sono io!)
|
||||
* rinunciare a collegarmi
|
||||
* cancellare la riga corrispondente nel file known_host, come suggerito:
|
||||
^
|
||||
|
||||
ssh-keygen -f "/home/dan/.ssh/known_hosts" -R "127.0.0.1"
|
||||
|
||||
E ricominciare.
|
||||
^
|
||||
|
||||
[1]: ecco qui una soluzione! stakka, stakka! [humor]
|
||||
https://git.zx2c4.com/knock-knock-token/tree/knock-knock-token.c
|
||||
|
||||
---
|
||||
|
||||
# OpenSSH è una suite di software
|
||||
|
||||
OpenBSD descrive OpenSSH come una suite che comprende i seguenti strumenti:
|
||||
|
||||
Per il collegamento remoto:
|
||||
|
||||
ssh
|
||||
scp
|
||||
sftp
|
||||
^
|
||||
|
||||
Per la gestione chiavi:
|
||||
|
||||
ssh-add
|
||||
ssh-keysign
|
||||
ssh-keyscan
|
||||
ssh-keygen
|
||||
^
|
||||
|
||||
Lato server:
|
||||
|
||||
sshd
|
||||
sftp-server
|
||||
ssh-agent
|
||||
|
||||
---
|
||||
|
||||
# Un account per fare le prove
|
||||
|
||||
Super Dimentional Fortress è una comunità che usa NetBSD ed esiste dagli anni 80
|
||||
Fornisce free shell access per motivi didattici.
|
||||
|
||||
`ssh unit@tty.freeshell.org`
|
||||
|
||||
`password: <nel pass-file di unit>`
|
||||
^
|
||||
|
||||
È possibile creare un nuovo account su SDF collegandosi con ssh:
|
||||
|
||||
`ssh new@sdf.org`
|
||||
|
||||
Nota: occorrerà configurare la shell (anche il backspace).
|
||||
|
||||
---
|
||||
|
||||
# Copiare file con scp
|
||||
|
||||
*scp* serve a spostare file da una macchina all'altra
|
||||
^
|
||||
|
||||
*copia da remoto a locale* (download)
|
||||
|
||||
`scp itara@altrove:file_esistente file_da_creare`
|
||||
^
|
||||
|
||||
*copia dal locale al remoto* (upload)
|
||||
|
||||
`scp file_esistente itara@altrove:file_da_creare`
|
||||
^
|
||||
|
||||
la sintassi di scp usa sempre: il file *esistente prima* e quello *da-creare dopo*.
|
||||
^
|
||||
|
||||
Opzioni
|
||||
|
||||
-r copia recursivamente tutti i file di una directory
|
||||
-p mantiene i permessi del source-file (file esistente)
|
||||
-P indica una porta
|
||||
-v modalità verbosa
|
||||
^
|
||||
|
||||
esempio punkish (dove user coincide sulle macchine):
|
||||
|
||||
Spostare su altrove tutti gli mp3 nella directory in cui mi trovo, nella home.
|
||||
|
||||
scp *.mp3 altrove:
|
||||
|
||||
Spostare da altrove la directory musica in locale, nella dir in cui mi trovo
|
||||
|
||||
scp -r altrove:~/musica .
|
||||
|
||||
---
|
||||
|
||||
# Copiare file con sftp
|
||||
|
||||
*stfp* è come FTP, ma con la esse davanti.
|
||||
|
||||
la "s" sta per "secure", come in https.
|
||||
^
|
||||
|
||||
Si usa come un ftp da linea comando.
|
||||
|
||||
`sftp altrove`
|
||||
|
||||
Esempio di comandi a disposizione: *cd lcd ls lls pwd get put bye*
|
||||
^
|
||||
|
||||
sftp è un po' legnoso, un esempio di collegamento specificando una porta:
|
||||
|
||||
`sftp -oPort=50022 itara@altrove:/media/film/`
|
||||
^
|
||||
|
||||
Sia scp che ftp hanno i loro manuali: *man scp* e *man sftp*
|
||||
^
|
||||
|
||||
Ma perché usare sftp?
|
||||
Nessun BAFH metterebbe mai rssh su una macchina piena di film.
|
||||
|
||||
E ci sono tanti software che sono in grado di utilizzare ssh, scp, sftp.
|
||||
|
||||
---
|
||||
|
||||
# Qualche software che fa uso di openssh
|
||||
|
||||
* ncftp (ftp/sftp cline client)
|
||||
* filezilla (ftp/sftp client)
|
||||
* gigolo (integrazione con filesystem remoti)
|
||||
* integrazione nel file manager (thunar con gvfs-fuse, nautilus, nemo, etc)
|
||||
* duplicity
|
||||
* sshuttle
|
||||
|
||||
---
|
||||
|
||||
# Creare una coppia di chiavi per autenticazione ssh senza password
|
||||
^
|
||||
|
||||
Per comodità, spostarsi nella directory ~/.ssh/ (se non esiste va creata)
|
||||
|
||||
`ssh-keygen -b 8192 -t rsa -f id_rsa-zaphoda`
|
||||
|
||||
-b specifica la dimensione
|
||||
-t specifica il tipo (rsa o dsa)
|
||||
-f specifica il nome
|
||||
^
|
||||
|
||||
ssh-agent impiegherà qualche minuto per creare la coppia di chiavi e chiederà di
|
||||
definire una passphrase.
|
||||
|
||||
La coppia di chiavi, privata e pubblica, avranno quest'aspetto:
|
||||
|
||||
* La chiave privata: *id_rsa-zaphoda*
|
||||
* La chiave pubblica: *id_rsa-zaphoda.pub*
|
||||
^
|
||||
|
||||
E andranno a popolare la directory: ~/.ssh/ insieme al file config e known_hosts
|
||||
|
||||
* config
|
||||
* known_hosts
|
||||
* *id_rsa-zaphoda*
|
||||
* *id_rsa-zaphoda.pub*
|
||||
^
|
||||
|
||||
La parte *pub*-blica della doppia chiave non è segreta, è riconoscibile dalla desinenza
|
||||
*.pub* ed è la chiave pubblica che deve essere messa sul server, per effettuare lo
|
||||
scambio chiavi con autenticazione senza scambio password, nella directory ~/.ssh/,
|
||||
con i giusti permessi, dove sarà rinominata come: *authorized_keys*
|
||||
|
||||
`mv id_rsa-zaphoda.pub authorized_keys`
|
||||
|
||||
---
|
||||
|
||||
# Uso di una coppia di chiavi per autenticazione ssh senza password
|
||||
|
||||
Connessione "senza password", significa che non viene chiesta la password
|
||||
dell'utente, la quale non viene così digitata e non viene trasmessa.
|
||||
|
||||
È richiesta invece la passphrase di sblocco chiavi in locale,
|
||||
e ancora: non quella dell'utente sul server.
|
||||
|
||||
Nota: Se non avrò settato una password o passphrase, non mi verrà chiesta
|
||||
(è utile per l'utilizzo automatico all'interno di uno script di backup)
|
||||
|
||||
Esempio password: *5_Gru&t75$^dU*
|
||||
Esempio passphrase: *Nutri la tua testa*
|
||||
|
||||
Una passphrase è più facile da ricordare che una buona password,
|
||||
ma è anche più sicura.
|
||||
|
||||
---
|
||||
|
||||
# i Permessi
|
||||
|
||||
Tra i file che sono stati elencati dentro ~/.ssh/ ci sono anche la chiave *privata*
|
||||
e quella *pubblica* usate per l'autenticazione con scambio di chiavi via ssh.
|
||||
^
|
||||
|
||||
- config
|
||||
- known_hosts
|
||||
- *id_rsa-zaphoda*
|
||||
- *id_rsa-zaphoda.pub*
|
||||
^
|
||||
|
||||
Questi file devono avere permesso di lettura e scrittura solo al proprietario, e la
|
||||
directory che li contiene anche, ma in più quello di esecuzione, altrimenti non
|
||||
sarebbe navigabile.
|
||||
|
||||
`chmod 700 ~/.ssh`
|
||||
`chmod 600 ~/.ssh/id_rsa-zaphoda`
|
||||
`chmod 644 ~/.ssh/id_rsa-zaphoda.pub`
|
||||
^
|
||||
|
||||
memo: 4 = scrittura, 2 = lettura, 1 = esecuzione
|
||||
esempio: scrittura+lettura=6
|
||||
|
||||
memo: UGO - cioè User, Group, Others - cioè me, mio gruppo, resto del mondu.
|
||||
esempio: U=scrittura-e-lettura G=niet O=nada --> 600
|
||||
|
||||
---
|
||||
|
||||
# SSH-Tunnel
|
||||
|
||||
Il Port Forwarding SSH, chiamato anche SSH tunneling, permette di stabilire una
|
||||
sessione protetta ssh e poi far passare connessioni arbitrarie TCP attraverso di essa
|
||||
(fa un tunnel).
|
||||
^
|
||||
|
||||
Ci sono tre tipi di Port Forwarding:
|
||||
|
||||
*ssh -L*
|
||||
|
||||
Locale port forwarding
|
||||
|
||||
*ssh -R*
|
||||
|
||||
Remote port forwarding
|
||||
|
||||
*ssh -D*
|
||||
|
||||
Dinamic port forwarding
|
||||
|
||||
---
|
||||
|
||||
# Local Port Forwarding
|
||||
|
||||
Collega una porta di una macchina sullo stesso network a un altra macchina.
|
||||
^
|
||||
|
||||
Si usa per raggiungere o spostare files da/per una macchina "dietro",
|
||||
cioè non raggiungibile direttamente.
|
||||
^
|
||||
|
||||
Ad esempio: un collegamento al pc chiamato *nanna*, che è in una sottorete non
|
||||
direttamente raggiungibile da fuori, attraverso un pc chiamato *ninna* che si
|
||||
affaccia alla rete con un IP raggiungibile.
|
||||
|
||||
Ho credenziali sia su *ninna* che su *nanna*.
|
||||
|
||||
Per raggiungere *nanna* bisogna passare da *ninna*. Con un tunnel.
|
||||
|
||||
---
|
||||
|
||||
# Local Port Forwarding (2)
|
||||
|
||||
Si dovrà prima *creare* il tunnel e poi *usarlo*.
|
||||
^
|
||||
|
||||
1: Creazione del tunnel:
|
||||
|
||||
Collegamento da *localhost* a *ninna* girando (forward) *nanna* sulla (port) porta 22000
|
||||
Altrimenti detta: collegamento di *nanna* su *ninna* sulla porta 22000
|
||||
^
|
||||
|
||||
`ssh ninna -L 22000:nanna:22`
|
||||
|
||||
L = Local tunnel
|
||||
22 = la porta dove raggiungere nanna
|
||||
22000 = la porta dove aprire il tunnel su localhost
|
||||
^
|
||||
|
||||
E si tiene la connessione, dove si può aprire un `top`.
|
||||
^
|
||||
|
||||
2: Uso del tunnel:
|
||||
|
||||
Collegamento su *localhost* alla porta 22000 dove si trova il tunnel che porta a *nanna*
|
||||
Altrimenti detta: collegamento in locale alla porta 22000 per arrivare su *nanna*
|
||||
|
||||
Apro un'altra finestra terminale.
|
||||
^
|
||||
|
||||
`ssh localhost -p 22000` (e mi trovo su *nanna*)
|
||||
|
||||
p = specifica la porta
|
||||
^
|
||||
|
||||
Nota: Una volta creato il tunnel, potrò anche usarlo con scp.
|
||||
|
||||
---
|
||||
|
||||
# Dynamic Port Forwarding
|
||||
|
||||
è un socks proxy tunnel per le app che supportano socks.
|
||||
Serve a creare un proxy con ssh
|
||||
^
|
||||
|
||||
`ssh -NvD 8080 itara@altrove`
|
||||
|
||||
N = non chiudere la shell
|
||||
v = verbose mode
|
||||
D = Dinamico tunnel
|
||||
^
|
||||
|
||||
Collega al server e crea un SOCKS proxy sulla porta 8080 in locale.
|
||||
E ora nel client potrò usare: *localhost*, *Socks5* Proxy, Port *8080*
|
||||
|
||||
Ad esempio potrei, nelle preferenze di Firefox, indirizzarlo a usare
|
||||
localhost sulla porta 8080 e così far passare la mia navigazione da Altrove.
|
||||
|
||||
Nota: si può anche usare FoxyProxy (add-on di Firefox)
|
||||
|
||||
---
|
||||
|
||||
# sshuttle
|
||||
|
||||
sshuttle è un software che usa Dinamyc port forwarding per forwardare tutto
|
||||
(una specie di VPN)
|
||||
|
||||
`sshuttle -r itara@altrove 0/0 -v`
|
||||
|
||||
A questo punto tutte le mie connessioni passano da Altrove.
|
||||
|
||||
---
|
||||
|
||||
# Remote Port Forwarding
|
||||
|
||||
Serve a rendere accessibile sulla rete pubblica una macchina che sta in una sottorete.
|
||||
|
||||
Ad esempio per rimbalzare un webserver interno e renderlo accessibile da fuori:
|
||||
^
|
||||
|
||||
`ssh -R 8080:nanna:80 ninna`
|
||||
|
||||
R = Remote tunnel
|
||||
|
||||
Ora da fuori si potrà puntare il browser a http://ninna:8080 e raggiungere
|
||||
la pagina web ospitata sulla "macchina dietro" (Nanna).
|
||||
^
|
||||
|
||||
Nota: l'uso di *ninna* e *nanna* è unicamente dovuto al fatto che i loro nomi
|
||||
sono intuitivamente percepibili in successione. Non per farvi venire sonno.
|
||||
|
||||
---
|
||||
|
||||
# Rendere sicuro l'uso di ssh (sshd)
|
||||
|
||||
Con ssh si installa anche il server,
|
||||
il nostro computer è anche un server ssh.
|
||||
^
|
||||
|
||||
È opportuno configurare sshd editando il suo file di configurazione:
|
||||
|
||||
in */etc/ssh/sshd_config*
|
||||
|
||||
> PubkeyAuthentication yes
|
||||
> PasswordAuthentication no
|
||||
> PermitRootLogin no
|
||||
> ChallengeResponseAuthentication no
|
||||
> UsePAM no
|
||||
> X11Forwarding no
|
||||
|
||||
Ora ci si potrà collegare solo con scambio chiavi,
|
||||
e non direttamente come root.
|
||||
|
||||
Per riavviare il server sshd: `/etc/init.d/ssh reload`
|
||||
|
||||
---
|
||||
|
||||
# The End
|
||||
|
||||
Per la scrittura di questa slide è stato usato il formato *markdown*
|
||||
|
||||
`emacs punkish-slide.md`
|
||||
|
||||
Per la presentazione è stato usato *mdp*
|
||||
|
||||
`mdp punkish-slide.md`
|
||||
|
||||
Per la visione remota è stato usato *tmate*
|
||||
|
||||
`tmate` (ha generato un link)
|
||||
|
||||
|
||||
|
||||
Commenti? Kudos? Consigli? Vaffa? Grazie!
|
||||
|
||||
|
||||
**https://git.abbiamoundominio.org/dan/presentazione-openssh**
|
||||
|
||||
Loading…
Reference in New Issue
Block a user