Outils pour utilisateurs

Outils du site


logiciels:ssh

ssh : se connecter sur des machines


Renforcement de la sécurité

Suite aux révélations d'Edward Snowden concernant la NSA, nous allons renforcer la sécurité de ssh.

Coté serveur

Modification du fichier /etc/ssh/sshd_config :

nano /etc/ssh/sshd_config
# 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 no # or 'without-password' to allow SSH key based login
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 no
 
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
 
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
 
# Cipher selection
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
 
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

Coté client

Modification du fichier /etc/ssh/sshd_config, possibilité de mettre ces options dans /home/$USER/.ssh/config :

nano /etc/ssh/ssd_config
# Github needs diffie-hellman-group-exchange-sha1 some of the time but not always.
#Host github.com
#    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
 
Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Authentification par clé

Mise en place d'une authentification par clé :

Création de la clé RSA sur le poste client pour une compatibilité avec Windows :

ssh-keygen -t rsa -b 4096 -o -a 1000

Ou bien une clé Ed25519 préférable si pas de Windows:

ssh-keygen -t ed25519 -o -a 1000

Mettre une bonne passphrase.
On exporte la clé sur le serveur ssh par ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur

Si le serveur écoute sur un port différent que le 22 alors :

ssh-copy-id -i ~/.ssh/id_rsa.pub -p 53222 utilisateur@serveur

Si vous avez plusieurs clés il est possible de déterminer celle que l'on veux utiliser. Placer dans config :

IdentitiesOnly yes
IdentityFile ~/.ssh/id_ed25529_SERVER1

Maintenir une connexion ouverte

Deux possibilités pour maintenir une connexion ouverte.

Coté client

Si vous êtes administrateur de la machine cliente (root) et que vous souhaitez corriger ce problème pour tous les utilisateurs, il faut éditer le fichier /etc/ssh/ssh_config. Si vous préférez appliquer les réglages que pour vous, éditez le fichier ~/.ssh/config (créez-le s'il n'existe pas). Dans les deux cas, voici ce qu'il faut mettre :

Host *
  ServerAliveInterval 300
  ServerAliveCountMax 2

L'option ServerAliveInterval 60 signifie que des données seront envoyées toutes les 60 secondes pour demander au serveur de confirmer que la connexion est toujours ouverte, et permet au passage de garder une connexion active au niveau des routeurs NAT.
L'option ServerAliveCountMax 2 indique au client SSH de considérer la connexion comme fermée si l'on ne reçoit pas de réponse après deux demandes de confirmation.

Coté serveur

si vous êtes administrateur du serveur SSH, vous pouvez également mettre la configuration suivante dans le fichier /etc/ssh/sshd_config pour corriger le problème pour tous les clients qui se connectent à ce serveur :

ClientAliveInterval 300
ClientAliveCountMax 2

Le principe reste le même que pour la configuration côté client, seul les noms des paramètres changent. Toutefois n'oubliez pas de redémarrer le service SSH pour que ces changements de configuration soient pris en compte.

Créer un alias tunnel

Éditer/créer le fichier ~/.ssh/config et coller :

Host mysearch
  HostName IP-serveur-ssh
  Port 22
  User adrien
  LocalForward=60061 127.0.0.1:60061

Établir la connexion avec ( à vérifier ) :

ssh -N mysearch &

On créé donc un tunnel ssh, qui va “relier” le port 60061 de ma machine sur le port 60061 de la machine distante. Je peux accéder à mysearch (qui écoute sur le port 60061) maintenant, avec le navigateur sur mon PC à l'adresse http://localhost:610061. http://localhost:8080

Tunnel Socks

Ssh permet de créer un tunnel Socks par lequel on fait transiter un trafic réseau. Ce trafic est donc chiffré entre votre poste et le serveur ssh. Il faut évidement que le serveur ssh soit disponible depuis l'extérieur.
A titre d'exemple, sur un réseau wifi public, il est possible de faire transiter le trafic du navigateur internet ou bien d'un client mail.
J'utilise aussi un tunnel socks pour Thunderbird lors d'une connexion VPN ( UDP ) fournit par un tiers.

On commence par établir le tunnel avec cette commande :

ssh -C -TND 41200 user_distant@serveur_distant

Quelques explications sur les arguments employés :

-T désactive toute allocation de pseudo terminal
-N pour signifier à SSH qu'il n'y a aucune commande à lancer, on ne cherche qu'à créer un tunnel pour le proxy SOCKS
-D 41200 on demande à SSH de créer un service SOCKS sur le port local 41200. À partir de là, toute requête faite sur le port 41200 de la machine locale, passera par le tunnel chiffré et sera exécutée sur la machine distante ( le serveur ssh )
-C active la compression du trafic
-v pour que ssh soit bavard

Lorsque cette commande a été lancée, deux choix s'offrent à vous pour utiliser ce tunnel :

  • Soit on configure l'application. Pour Firefox on modifie les réglages dans Édition ⇨ Préférences ⇨ Avancées ⇨ Réseau ⇨ Paramètres pour cocher Configuration manuelle du proxy. Dans le champs Hôte SOCKS il faut mettre mettre localhost et 41200 dans le champ Port. Cochez SOCKS v5 puis validez. Surfer un peu et voyer votre terminal devenir bavard.
  • Soit on utilise un programme tsokcs ( qu'il faut bien sûr installer ). Créer/modifier le fichier /home/$USER/.tsocks.conf comme suit :
server = localhost
server_port = 41200
server_type = 5

Puis on lance par exemple Firefox comme ceci dans un terminal :

TSOCKS_CONF_FILE=/home/$USER/.tsocks.conf tsocks firefox
La variable TSOCKS_CONF_FILE peut bien sûr être exportée dans le .bashrc par exemple.
Par défaut tsocks utilise le fichier de configuration /etc/tsocks.conf. Par le passé, tsocks fuitait les DNS avec Thunderbird, je ne sais pas si actuellement c'est encore le cas.
  • Soit on utilise un programme proxychains-ng, qui a ma préférence. Modification à faire en fin de fichier /etc/proxychains :
socks5 127.0.0.1 41200

Pour lancer le programme :

proxychains thunderbird
logiciels/ssh.txt · Dernière modification: 2018/10/25 18:19 (modification externe)