Objectifs de certification


Chapitre 12. Secure Shell

Objectifs de certification

RHCSA EX200

  • 1.Comprendre et utiliser les outils essentiels
  • 1.4. Accéder à des systèmes distants à l’aide de ssh
  • 7.Gérer la sécurité
  • 7.2. Configurer l’authentification basée sur une clé pour SSH

RHCE EX300

  1. SSH
    • 8.1. Configure key-based authentication.
    • 8.2. Configure additional options described in documentation.

LPIC 1

LPIC 2

1. Présentation de SSH

1.1 Présentation rapide de SSH

Secure Shell (SSH) est un protocole qui permet de sécuriser les communications de données entre les ordinateurs connectés au réseau.

Il permet d’assurer la confidentialité, l’intégrité, l’authentification et l’autorisation des données dans des tunnels chiffrés. Il utilise TCP habituellement sur le port 22, mais il peut en utiliser d’autres simultanément. Il est fondé sur le protocole TLS.

On utilise aujourd’hui la version SSH-2. La version SSH-1 est à proscrire.

On peut l’utiliser comme console distante à la manière de Telnet, RSH ou Rlogin.

Il supporte les authentifications centralisées (PAM), locale avec mot de passe ou sans échange de mot de passe (par le biais d’échange de clés).

On peut transférer des sessions X graphiques dans un tunnel SSH.

On peut y transférer des ports et utiliser le service comme proxy ou comme solution VPN, de manière distante ou locale.

Les sous-protocoles SCP et SFTP offrent des services de transfert de fichiers.

Il s’intègre à des logiciels comme ansible, systemd, x2go, …

Et encore d’autres fonctionnalités fines en matière de sécurité ou de facilité.

En terme de cible d’attaque, le port est très sollicité par les robots qui scannent les réseaux publics en quête de configurations faibles, nulles, négligées ou exploitables. Il peut arriver qu’un port SSH exposé publiquement soit l’objet de tentatives de Déni de Service (DoS) ou de connexions Brute Force qui rendent le service inacessible.

Il est conseillé d’auditer, voire de filter les accès au service SSH avec un logiciel comme fail2ban, des sondes IPS/IDS snort ou autre. Un pot de miel tel que Cowrie peut être une arme à manier avec précaution. Des projets comme Modern Honey Network (MHN) peuvent faciliter le déploiement de telles sondes.

!! Note OpenSSH à ajouter.

2. Installation, configuration, connexion OpenSSH

Avec les droits de root :

systemctl status sshd
  • Si nécessaire :
yum install openssh-server
systemctl enable sshd
systemctl start sshd
less /etc/ssh/sshd_config
ssh user@127.0.0.1
  • Version du client :
ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013
  • Mais aussi la bannière du service :
nc localhost 22
SSH-2.0-OpenSSH_6.6.1
  • Pare-feu Firewalld

Sous Centos 7, firewalld est activé par défaut. Sans aucune autre configuration, ssh est autorisé pour les interfaces dans la zone “public”.

Avec les droits de root :

firewall-cmd --permanent --add-service=ssh

3. Authentification par clé avec OpenSSH

L’authentification par clé fonctionne grâce à 3 composants :

  • Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter.
  • Une clé privée : elle permet de prouver son identité aux serveurs.
  • Une passphrase : optionnelle, elle permet de sécuriser la clé privée (notons la subtilité, passphrase et pas password… donc « phrase de passe » et non pas « mot de passe »).

La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa. Cet usage peut se révéler contraignant.

3.1. Création de la paire de clés

La création de la paire de clés se fait avec ssh-keygen.

Il existe 2 types de clés : RSA et DSA. Chacune pouvant être de longueur différente (les clés inférieures à 1024 bits sont à proscrire).

Pour créer une clé dans sa session avec des paramètres par défaut :

ssh-keygen

Sans paramètres, les options par défaut sont type RSA en 2048 bits.

Le commentaire permet de distinguer les clés, utile quand on a plusieurs clé (notamment une personnelle et une pour le boulot). Ici la distinction se fait sur l’adresse e-mail. Si le commentaire est omis, il sera de la forme user@host.

3.2. Clé privée / clé publique

Deux fichiers ont été créés (dans le dossier ~/.ssh/) :

  • id_rsa (ou id_dsa dans le cas d’une clé DSA) : contient la clé privée et ne doit pas être dévoilé ou mis à disposition.
  • id_rsa.pub (ou id_dsa.pub dans le cas d’une clé DSA) : contient la clé publique, c’est elle qui sera mise sur les serveurs dont l’accès est voulu.

3.3. Transmission de la clé publique au serveur

Pour transmettre la clé publique au serveur, il sera nécessaire de disposer d’avance d’un mot de passe pour le compte à authentifier, à moins que d’agir comme utilisateur privilégié. Le principe est d’aller écrire la ou les clés publiques autorisées dans le fichier ~/.ssh/authorized_keys de l’utilisateur cible.

Trois méthodes de transmission de la clé à partir d’une station distante sont proposées ici.

  • Via une console SSH :
cat ~/.ssh/id_rsa.pub | ssh user@ip_machine "cat - >> ~/.ssh/authorized_keys"
  • Via le protocole de transfert SCP :
scp ~/.ssh/id_rsa.pub user@ip_machine:/tmp
ssh user@ip_machine
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys
rm /tmp/id_rsa.pub
  • Via le binaire ssh-copy-id :
ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip_machine

4. Exécution de commande et shell distant

4.1. Le client openssh

Typiquement, on obtient un shell distant en utilisant la commande ssh utilisateur@machine. A la première connexion, on reconnaîtra l’hôte de destination comme étant valide. L’emprunte de sa clé est enregistrée dans le fichier ~/.ssh/known_hosts.

ssh user@127.0.0.1 -p 22
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is bf:ab:65:84:a3:2f:0b:f9:2c:68:88:c9:a8:24:3f:64.
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.
user@127.0.0.1's password:
Last login: Tue Sep 27 17:52:26 2016 from 172.16.98.1
$ exit
déconnexion
Connection to 127.0.0.1 closed.
  • Si on omet l’utilisateur, c’est le compte courant qui est utilisé pour l’authentification; aussi si on omet le port, c’est TCP22 qui est utilisé par défaut :
ssh localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is bf:ab:65:84:a3:2f:0b:f9:2c:68:88:c9:a8:24:3f:64.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
user@localhost's password:
Last login: Tue Sep 27 17:54:30 2016 from localhost
$ exit
déconnexion
Connection to localhost closed.
  • Exécuter une commande à distance :
ssh localhost id
user@localhost's password:
uid=1000(user) gid=1000(user) groupes=1000(user),10(wheel) contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  • Connexion en IPv6 :
ssh -6 localhost
user@localhost's password:
Last login: Tue Sep 27 18:11:41 2016 from 172.16.98.1

4.2. Options du client openssh

Le logiciel client ssh dispose de beaucoup d’options :

ssh [-1246AaCfgkMNnqsTtVvXxY] [-b adr_assoc] [-c crypt_spec] [-D port] [-e char_echap] [-F fich_config] [-i fich_identite] [-L port:host:hostport] [-l nom_login] [-m mac_spec] [-o option] [-p port] [-R port:host:hostport] [-S ctl] [utilisateur@]hostname [commande]

On retiendra des options courantes comme :

  • -p numero_port pour attaquer un port différent du port 22 par défaut.
  • -i /emplacement_clé_privéee : pour préciser l’usage d’une clé privée.
  • -q combiné avec des options -o "StrictHostKeyChecking no", -o "UserKnowHostsFile=/dev/null" et -o "LogLevel=ERROR".
  • -X, -Y, -MY pour activer le transfert de sessions graphiques sur un serveur X local.
  • -L port_local:adresse_nom_serveur:port_distant pour transférer un port du serveur sur le client (dans un tube sécurisé SSH). Par exemple, rendre un serveur Web protégé par un pare-feu accessible à travers le port local renseigné du client.
  • -R port_local:serveur_distant:port_distant pour transférer un port local vers le port d’un serveur. Soit quand un tiers sollicitera un le port du serveur, son trafic sera transféré sur le port local renseigné du client.

5. Transfert de fichiers SCP et SFTP

5.1. Transfert de fichiers SCP

SCP est la transposition de la commande cp à travers SSH, avec des arguments, une source et une destination. On désigne la ressource distante origine ou destination par user@machine:/path. Par exemple :

scp /dossier/fichier user@machine:~
scp user@machine:~/dossier/fichier .
scp -R /dossier user@machine:~

Attention: c’est l’option -P numero_port qui permet de définir un port SSH avec les binaires clients scp et sftp.

5.2. Transfert de fichiers SFTP

SFTP s’utilise comme un client FTP.

# sftp user@localhost
user@localhost's password:
Connected to localhost.
sftp> pwd
Remote working directory: /home/user
sftp> quit

5.3. Transfert de fichiers Rsync

rsync (pour remote synchronization ou synchronisation à distance), est un logiciel de synchronisation de fichiers. Il est fréquemment utilisé pour mettre en place des systèmes de sauvegarde distante.

rsync travaille de manière unidirectionnelle c’est-à-dire qu’il synchronise, copie ou actualise les données d’une source (locale ou distante) vers une destination (locale ou distante) en ne transférant que les octets des fichiers qui ont été modifiés.

Il utilise des fonctions de compression.

Il utilise SSH par défaut pour les synchronisations distantes. Il est aussi utile pour des copies locales.

# yum -y install rsync

5.4. Client rsync

rsync source/ destination/
rsync -az source/ login@serveur.org:/destination/
rsync -e ssh -avz --delete-after /home/source user@ip_du_serveur:/dossier/destination/
rsync -e ssh -avzn --delete-after /home/mondossier_source user@ip_du_serveur:/dossier/destination/

5.5. Serveur rsync

cat /etc/rsyncd.conf
# /etc/rsyncd: configuration file for rsync daemon mode

# See rsyncd.conf man page for more options.

# configuration example:

# uid = nobody
# gid = nobody
# use chroot = yes
# max connections = 4
# pid file = /var/run/rsyncd.pid
# exclude = lost+found/
# transfer logging = yes
# timeout = 900
# ignore nonreadable = yes
# dont compress   = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2

# [ftp]
#        path = /home/ftp
#        comment = ftp export area
# mkdir /home/ftp
# systemctl start rsyncd
# systemctl enable rsyncd
rsync -avpro /home/ftp serveur.org::ftp

Source : https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Automated_Backup

5.6. Montages SSH

Fuse.

6. Configuration du service OpenSSH

6.1. Fichier de configuration

Voici un fichier par défaut /etc/ssh/sshd_config en Debian 8 :

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# 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
HostKey /etc/ssh/ssh_host_ed25519_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 yes
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 yes
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

Attention, chaque distribution dispose de ses paramètres par défaut notamment sur les authentifications.

6.2. Régénération des clés du serveur

Les clés du serveur lui-même (appelé host) peuvent être régénérées à condition qu’elles soient effacées. En Debian 8, il sera nécessaire de reconfigurer le paquet avant de redémarrer le service contrairement au comportement RHEL7/Centos7.

En Debian 8 :

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
systemctl restart ssh
systemctl status ssh

En RHEL7/Centos7 :

rm /etc/ssh/ssh_host_*
systemctl restart ssh
systemctl status ssh

7. Usage sous Windows

7.1. Utilitaire Putty

https://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

7.2. Utilitaire CyberDuck

https://cyberduck.io/

7.3. Utilitaire WinSCP

https://winscp.net/eng/docs/lang:fr

7.4. Installation de OpenSSH pour Windows Server 2019 et Windows 10

Installation de OpenSSH pour Windows Server 2019 et Windows 10

8. Transfert de session graphique avec SSH

8.1. Serveur X

ssh -X user@ip_machine

8.2. Serveur X Xming

https://sourceforge.net/projects/xming/

9. Montage de tunnel

https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

9.1. Transfert de port localement

Exemple :

ssh -L 4444:127.0.0.1:80 user@machine

9.2. Proxy Socks

ssh -ND 3128 user@machine

Ensuite configurer le proxy sur 127.0.0.1:3128

9.3. Transfert distant distant et autossh pour la persistence

10. Serveur X2Go

Solution de bureau distant.

10.1. Installation du serveur

yum install x2goserver
yum groupinstall “Xfce”
yum groupinstall “MATE Desktop”
firewall-cmd –permanent –zone=public –add-service=ssh
firewall-cmd –reload

10.2. Installation du client

Pour Linux, Windows ou Mac OS X : https://wiki.x2go.org/doku.php

11. Fail2ban

Site officiel : https://www.fail2ban.org/wiki/index.php/Main_Page

Fail2ban est un service qui surveille les logs de comportement malveillant (tentative de connexions, DDoS, etc.) et qui inscrit dynamiquement des règles de bannissement dans iptables. Fail2ban est compatible avec un grand nombre de services (apache, sshd, asterisk, …).

11.1. Installation de fail2ban

  • Installer epel-relase et puis fail2ban :
# yum install -y epel-release
# yum install -y fail2ban
  • Activation du service :
systemctl enable fail2ban

Tous les fichiers de configuration sont situés dans /etc/fail2ban. Les valeurs par défaut sont situées dans un fichier jail.conf. Le fichier jail.local aura la précédence sur le fichier jail.conf, dans l’ordre.

  1. /etc/fail2ban/jail.conf
  2. /etc/fail2ban/jail.d/*.conf par ordre alphabétique
  3. /etc/fail2ban/jail.local
  4. /etc/fail2ban/jail.d/*.local par ordre alphabétique

11.2. Activation des règles

Créer un fichier /etc/fail2ban/jail.local avec ce contenu :

[DEFAULT]
# Ban hosts for one hour:
bantime = 3600

# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = iptables-multiport

[sshd]
enabled = true

Activer et démarrer fail2ban :

systemctl start fail2ban
systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
   Active: active (running) since mar 2016-09-27 21:39:13 CEST; 6s ago
     Docs: man:fail2ban(1)
  Process: 64203 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
 Main PID: 64229 (fail2ban-server)
   CGroup: /system.slice/fail2ban.service
           └─64229 /usr/bin/python2 -s /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

sep 27 21:39:12 localhost.localdomain systemd[1]: Starting Fail2Ban Service...
sep 27 21:39:12 localhost.localdomain fail2ban-client[64203]: 2016-09-27 21:39:12,358 fail2ban.server         [64221]: INFO    Starting Fail2ban v0.9.3
sep 27 21:39:12 localhost.localdomain fail2ban-client[64203]: 2016-09-27 21:39:12,358 fail2ban.server         [64221]: INFO    Starting in daemon mode
sep 27 21:39:13 localhost.localdomain systemd[1]: Started Fail2Ban Service.

Surveiller Fail2ban :

fail2ban-client status
Status
|- Number of jail:	1
`- Jail list:	sshd
fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/secure
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:
tail -F /var/log/fail2ban.log

11.3. Aller plus loin avec fail2ban

  • Lire le fichier /etc/fail2ban/jail.conf et s’en inspirer pour personnaliser le module ssh

  • Le dossier /etc/fail2ban/filter.d/ donne une idée des applications supportées :

ls /etc/fail2ban/filter.d/
3proxy.conf                apache-shellshock.conf  dropbear.conf       horde.conf            openwebmail.conf    qmail.conf            squirrelmail.conf
apache-auth.conf           assp.conf               drupal-auth.conf    ignorecommands        oracleims.conf      recidive.conf         sshd.conf
apache-badbots.conf        asterisk.conf           ejabberd-auth.conf  kerio.conf            pam-generic.conf    roundcube-auth.conf   sshd-ddos.conf
apache-botsearch.conf      botsearch-common.conf   exim-common.conf    lighttpd-auth.conf    perdition.conf      selinux-common.conf   stunnel.conf
apache-common.conf         common.conf             exim.conf           monit.conf            php-url-fopen.conf  selinux-ssh.conf      suhosin.conf
apache-fakegooglebot.conf  counter-strike.conf     exim-spam.conf      mysqld-auth.conf      portsentry.conf     sendmail-auth.conf    tine20.conf
apache-modsecurity.conf    courier-auth.conf       freeswitch.conf     nagios.conf           postfix.conf        sendmail-reject.conf  uwimap-auth.conf
apache-nohome.conf         courier-smtp.conf       froxlor-auth.conf   named-refused.conf    postfix-rbl.conf    sieve.conf            vsftpd.conf
apache-noscript.conf       cyrus-imap.conf         groupoffice.conf    nginx-botsearch.conf  postfix-sasl.conf   sogo-auth.conf        webmin-auth.conf
apache-overflows.conf      directadmin.conf        gssftpd.conf        nginx-http-auth.conf  proftpd.conf        solid-pop3d.conf      wuftpd.conf
apache-pass.conf           dovecot.conf            guacamole.conf      nsd.conf              pure-ftpd.conf      squid.conf            xinetd-fail.conf

12. Renforcement du service SSH

13. Jouer avec SELINUX et SSH

13.1. Changer le contexte du port SSH

Contexte du port SSH :

semanage port -l | grep ssh
ssh_port_t                     tcp      22

Changer ou ajouter le port d’écoute dans le fichier /etc/ssh/sshd_config et adapter le contexte selinux :

semanage port -a -t ssh_port_t -p tcp 2222

Vérification du contexte SSH :

semanage port -l | grep ssh
ssh_port_t                     tcp      2222, 22

13.2. Booléens SSH

getsebool -a | grep ssh
fenced_can_ssh --> off
selinuxuser_use_ssh_chroot --> off
sftpd_write_ssh_home --> off
ssh_chroot_rw_homedirs --> off
ssh_keysign --> off
ssh_sysadm_login --> off
# setsebool -P sftpd_write_ssh_home on
yum install -y setroubleshoot-server
semanage boolean -m --on ftp_home_dir
semanage boolean -l | grep ssh
ssh_chroot_rw_homedirs         (fermé,fermé)  Allow ssh to chroot rw homedirs
sftpd_write_ssh_home           (fermé,fermé)  Allow sftpd to write ssh home
ssh_keysign                    (fermé,fermé)  Allow ssh to keysign
fenced_can_ssh                 (fermé,fermé)  Allow fenced to can ssh
selinuxuser_use_ssh_chroot     (fermé,fermé)  Allow selinuxuser to use ssh chroot
ssh_sysadm_login               (fermé,fermé)  Allow ssh to sysadm login

14. Exercices

  • Créer une paire de clé DSA et la transmettre au serveur.
  • Exécuter une session X avec Firefox à partir du serveur sur votre PC
  • Transferts de ports : se connecter à l’interface LAN du routeur
  • Essais Clients/serveurs X2go
  • Renforcement du service en modifiant la configuration
  • Activation de la compression
  • Intégration iptables, fail2ban
  • Découverte du logiciel d’automation Ansible

15. notes

Références

Intégrer google authenticator à PAM et SSH

Laisser un commentaire