Generation Libre

Sécuriser l’accès à SSh pour éviter le bruteforce entre autres avec une authentification forte par clés asymetrique.
Ce système de clé publie / clé privée permet d’éviter que des utilisateurs non authentifiés ayent le droit de faire une demande de login et de soumettre un mot de passe au serveur.

Accès à un serveur SSh via une authentification par clefs asymétriques.

Pré – requis :

• Un serveur Open-SSH installé sous Linux

#apt-get update
#apt-get install openssh-server (et xbase-clients si vous souhaitez faire de l’export d’affichage X)

• Un client SSH sous linux ou Windows :

Le client par défaut de Linux sait gérer les clés générées par la commande ssh-keygen
Il en va de même pour le logiciel tunnelier.
puTTY quant à lui ne sait gérer que les clés générées par l’utilitaire puttygen.exe mais c’est un des clients SSH libres pour Windows le plus utilisé.

Voir à cette adresse pour le logiciel Tunnelier :
Voir à cette adresse pour la dernière version de la suite puTTY gérant les clés et Téléchargez le fichier putty-0.59-installer.exe

Il existe donc deux méthodes dans cet exemple pour configurer le client en fonction de celui que vous utiliserez.

Configurer le serveur SSH pour accepter UNIQUEMENT l’authentification par clés.

Aller dans /etc/ssh et éditer le fichier de configuration du démon SSH :

# cd /etc/ssh && ls
# vi sshd_config

Modifier les lignes suivantes (celles indiquées par un < = commentaire)

# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port 22 < = Si vous souhaitez modifer le port d'écoute du serveur pour éviter le bruteforce via le port standard changez le ici
(voir annexe en fin de document
# 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
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024 <== Mettre une taille de clé de 1024 ou 2048 Octets UNIQUEMENT pour la version 1 du protocole
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes <== Mettre cette ligne sur YES pour activer l'authentification clé publique/privée
AuthorizedKeysFile %h/.ssh/authorized_keys <== Décommenter cette ligne pour indiquer où sont stockées les clés publiques
# 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 no to disable s/key passwords
ChallengeResponseAuthentication yes
# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no <== Mettre sur NO pour désactiver le password
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
Subsystem sftp /usr/lib/sftp-server
UsePAM no <== NO pour interdire l'accès au serveur SSh SANS clés.

Relancer le serveur SSh avec la commande suivante :

# killall sshd && sshd ou plus proprement :
# /etc/init.d/sshd restart

Générer une paire de clés pour le client SSh Linux ou Tunnelier :

Sur le serveur Linux :
Soit le postulat suivant,
L’utilisateur de SSh est l’administrateur du serveur et il souhaite pouvoir se logger directement en root sur le serveur SSh puisque nous autorisons l’accès à ce service par des clés UNIQUEMENT.

DANS TOUT AUTRE CAS METTEZ PermitRootLogin sur NO dans /etc/ssh/sshd_config et remplacez le répertoire de travail des commandes suivantes (/root/.ssh) par celui de l’utilisateur que vous souhaitez autoriser (, il pourra passer en root avec la commande SU s’il en possède les droits.
< == Dans le répertoire perso de root nous créons le répertoire où seront stockées les informations comme les clés publiques autorisées à l’usage lors d’une connexion SSh
# cd /root && mkdir .ssh

• a. Générons un couple de clés publique/privée RSA d’une taille de 1024 Octets :

# ssh-keygen –t rsa –b 1024 –C "test-clef" –f id_test_rsa
Ne pas utiliser d’accents dans les commandes comme pour clefs par exemple
Ssh-keygen va ensuite demander la passphrase pour la clé privée à entrer deux fois pour confirmation.
Attention la passphrase protège la clé privée…
Il affiche ensuite un message type :

Your identification has been saved in id_test_rsa.
Your public key has been saved in id_test_rsa.pub.
The key fingerprint is:
49:f7:5d:d9:b3:8d:08:94:e4:e4:71:96:36:93:40:99 test-clef-pour-synth
Donc maintenant dans /root/.ssh quand on fait un ls on peut voir les clés
debian-netserv:~/.ssh# ls
total 24K
-rw------- 1 0 0 951 Feb 27 12:18 id_test_rsa < == clé privée à stocker sur la machine cliente et à effacer du serveur
-rw-r--r-- 1 0 0 230 Feb 27 12:18 id_test_rsa.pub <== clé publique utilisée par le serveur pour identifier la clé privée lors de la demande de connexion
ATTENTION AUX PERMISSIONS SUR LES CLEFS (chmod 400)

• b. Inscrire la CLE PUBLIQUE dans un fichier d’autorisation des clés sur le serveur DANS LE REPERTOIRE DE L’UTILISATEUR du service SSH avec lequel on souhaite se logger, ici root .

Dans /root/.ssh :
#cat id_test_rsa.pub > authorized_keys < == Cette commande inscrit le contenu de la clé publique dans le fichier qu’elle crée au préalable nommé obligatoirement authorized_keys et en permission 600
Récupérez votre clé privée sur le serveur et stockez la sur le pc client.

Utilisation avec le client SSh pour Windows tunnelier :
Pour utiliser la clé avec tunnelier faite le pointer sur l’endroit où elle se trouve en utilisant l’outil : User keypair manager

Utilisation avec le client ssh natif de Linux en mode commande :
# ssh –i /root/.ssh/id_test_rsa root@IP_du_serveur

Le chemin indiqué /root/.ssh/ correspond au répertoire de l’utilisateur SSh du client Linux où est stockée la clé privée utilisée pour la connexion.

Ici, c’est /root.ssh mais cela pourrait très bien en être un autredu type /home/$user/.ssh .
Ne pas confondre avec le fait de se connecter EN TANT QUE root sur le serveur.

Utilisation avec le client SSh pour Windows puTTY :

(Attention version 0.59 [lien donné en début de capa] ou plus, sinon le système de clés ne fonctionnera pas de la manière attendue)
Putty ne sachant pas gérer les clefs générées par le serveur avec ssh-keygen il faut utiliser l’utilitaire puttygen.exe pour générer un couple de clés utilisable. Ouvrez puTTYKey generator puis générer une nouvelle paire de clés.

Cocher SSH-2 RSA et Number of bits in a generated key à 1024
Copier ce qui est indiqué dans l’ovale rouge (la clé publique générée par putty) dans le fichier /root/.ssh/authorized_keys sur le serveur.
Puis sauvegarder le couple public/private sur la machine cliente (au minimum la privée).

Se connecter avec putty en utilisant la clé privée :
Renseigner les informations de connexion :
Puis aller dans SSH >> Auth

Et faire pointer putty sur la clé privée :

Retournez sur session cliquez save et open pour tester la connexion.
une version en pdf de ce document est disponible ici

Annexe :

• Redirection du port d’écoute du serveur :

Dans /etc/ssh/sshd_config modifier la ligne port 22 en mettant le numéro de port que vous souhaitez, par exemple 9999.
Redémarrez le serveur ssh

/etc/init.d/ssh restart
Faites ensuite la redirection du port dans votre routeur :
Redirigez tout ce qui entre sur le port 9999 du routeur vers le 9999 sur le LAN.
Indiquez ensuite à chaque connexion par ssh le nouveau port d’écoute avec l’option -p
Le port 22 n’est alors plus utilisé

• Avec le port forwarding ssh :

ssh -L 1234:localhost:9999 root@serveur_ssh

Cette commande permet d’envoyer depuis le port 1234 du client ssh vers le port 9999 du serveur.
Voir sur le site officiel OPEN-SSH pour plus d’informations. Vous pouvez également faire de la NAT avec Iptables.

En parlant d’Iptable … :

• Une règle Iptable intéressante permet d’interdire tout accès au serveur ssh au bout de trois connexions illégale (pas de clé ou erreur d’authentification) :

iptable -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 30 --hitcount 3 --name DEFAULT --rsource -j DROP
iptable -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
Attention à ne pas vous enfermez dehors !

Thomas SIMON http://equanux.no-ip.org/