Life in SSH (Secure Shell)

Provo a mettere insieme alcuni appunti che nel tempo si sono ammucchiati nel cassetto, cercando di mantenere un ‘ordine logico nei passi.

Le solite cose che si trovano in rete, però in questo caso affiancate alla mia esperienza di utilizzo pratico.

Da tempo per la gestione del raspberryPI e del server a distanza mi sono affidato a SSH, e le possibili soluzioni che si appoggiano (vedi immagine sotto) sono diverse, così vediamo di affrontarne alcune tra le più interessanti che ho potuto sperimentare di persona.

Per i test come server abbiamo

  • Debian Jessie (da poco aggiornata) come server

Un vecchio AtlhonXP1700 con 2GB di ram e 2 dischi ATA in RAID1 con mdadm , (la sua storia è sparsa nel blog), abbiamo a disposizione apache2, mysql e php lato web , poi è pure relay server di posta, scarica con fetchmail e finisce in IMAP locale.

  • RaspberryPI

Un giocattolino con 512MB di ram, una SD da 8GB più una chiavetta USB come storage data con rullante Raspbian Jessie minimalizzata senza X (just only SSH), c’è apache2 (colpa di rtorrent-gui) e postfix per le mail di sistema (anche di questo la storia è sul blog)

Per le connessioni abbiamo 3 distinte categorie

  1. PC fisso o portatile, con win  o una distro GNU/Linux (meglio se Debian)
  2. Tablet 10.1 con android 4.2 (simply rooted)
  3. Smartphone Galaxy S3 (simply rooted)

L’elenco degli obiettivi :

  • configurazione del server SSH
  • configurazione client SSH
  • sshfs (kill FTP)
  • browser proxificato
  • IMAP in tunnel

ass

Dopo esserci lavati le mani passiamo al lavoro.

Assolutamente necessaria una colonna sonora all’articolo, da ascoltare in lettura come sotto fondo.

Configurazione del server SSH

Cominciamo con l’installare un pò di pacchetti :  ssh, openssh-server e openssh-client

Di default il demone parte all’avvio così che possiamo rifarci subito sul file di configurazione /etc/ssh/sshd_config che segue nella versione default.

# What ports, IPs and protocols we listen for , default 22
### consiglio di cambiare subito
### dopo la 1024 vanno bene quasi tutte
Port 9731
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Dalla configurazione di base mi piace modificare la porta che al posto della classica 22 diventerà una a nostra scelta ( dopo la 1024), almeno per eliminare certi scan che a priori si buttano sulla porta di default (22).

Con questa configurazione per collegarsi basterà conoscere l’indirizzo della macchina, il nome utente e la password, ma è possibile creare una cosa più simpatica inserendo una chiave nell’autenticazione, facendo così sarà necessario inserire nome utente e indirizzo della macchina inoltre la chiave pubblica deve essere presente sul server e dovrà essere inserita la password di sblocco della chiave ( la cui corrispondente chiave privata è sulla macchina client).

La parte modificata per forzare l’accesso con le chiavi e password è di sole 3 righe:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Oltre alla porta cambiata come segnalato a priori, occorre decommentare la riga:

AuthorizedKeysFile %h/.ssh/authorized_keys

Senza uscire dalla connessione riavviare il servizio

#sudo systemctl restart ssh

o

#/etc/.init.d/ssh restart

apriamo un’altra connessione per provare a vedere se tutto funziona.

Se avete problemi basta riportare a ‘yes‘ le opzioni sopra indicate e attenzione perché se non avete accesso fisico alla macchina un piccolo errore vi negherà qualsiasi tentativo di connessione futura.

Possiamo usare un’utente predefinito e dedicato al solo accesso SSH ! (useradd begamorta919)

Creare nella dir dell’utente prescelto per la connessione

/home/user/.ssh

il file

authorized_keys.

Se la directory non esiste, crearla con proprietario l’user prescelto:

$ mkdir /home/user/.ssh
$ chmod 700 /home/user/.ssh
$ cd /home/user/.ssh
$ touch authorized_keys
$ chmod 600 authorized_keys

Prestiamo attenzione ai permessi attribuiti.

Ora inseriamo le chiavi pubbliche nel file authorized_keys.

Come amante di MC e mcedit faccio la cosa manualmente, ma pare sia possibile usare un semplice comando:

$ scp -P <porta> ~/.ssh/id_rsa.pub <username>@<ip del server>:~/.ssh/authorized_keys

Per maggiori informazioni consultare anche : ssh-copy-id e ssh-add

Se la modifica viene fatta con un editor di testo (es. mcedit)

ATTENZIONE : inserire ogni chiave in una singola riga.

A riguardo potete anche consultare i miei vecchi appunti : SSH Sicuro .

Volendo da Jessie è possibile avere antrambe i controlli (chiave pubblica+password chiave + password utente) inserendo una riga

AuthenticationMethods publickey,password

è possible commentare

#AuthorizedKeysFile     %h/.ssh/authorized_keys

che è di default.

tips

Nel caso non siano ancora presenti le chiavi ECDSA aggiungere a sshd_config

HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

seguite dalla riconfigurazione con :

#dpkg-reconfigure openssh-server

Ora che la configurazione del server è terminata passiamo alla connessione con un client.

Passiamo la lettura alla pagina 2

4 risposte a “Life in SSH (Secure Shell)”

  1. Io modificherei anche il modt inserendo qualche messaggio minaccioso…
    Tipo: “Caro intrusore… e ora sono cazzi tuoi!!!”

    😀

  2. Carissimo quale onore…
    controbatto alla tua proposta con questa simpatica soluzione.
    Andiamo a modificare il file /etc/ssh/sshd_config decommentando la linea :
    Banner /etc/issue.net
    poi modifichiamo il file con il nostro editor preferito (mc_edit)


    ***********************************************
    *..............Protected Area.................*
    ***********************************************
    ...........Secure_check_by_buho_ritto..........

    Questo sarà il messaggio al login. (l’immagine in ascii dovrebbe comparire diversamente)

    Sempre con il nostro editor modifichiamo /etc/motd per il messaggio che seguirà il login avvenuto con successo.

    Se sei arrivato fino a qui e non sono io ..... son cazzi !!!

  3. Quale oNore o quale oDore? 😀

    +1 Per mini tutorial + messaggio !!

    PS un’ascii art rappresentante un dito medio non sarebbe malaccio…

  4. Ci starebbe proprio bene, una volta il dito medio in ASCII era il mio forte
    http://www.chris.com/ascii/
    http://www.asciiworld.com/

    …………………./´¯/)
    ………………..,/¯../
    ………………./…./
    …………./´¯/’…’/´¯¯`·¸
    ………./’/…/…./……./¨¯\
    ……..(‘(…´…´…. ¯~/’…’)
    ………\……………..’…../
    ……….”…\………. _.·´
    …………\…………..(
    …………..\………….\…

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.