L’aventure Raspberry PI – intermède 5 – Sécurisation de SSH

Un article très court aujourd’hui sur la configuration de SSH.

Par défaut à l’installation, SSH est configuré pour autoriser la connection root. Une très bonne habitude à prendre est de désactiver cette option. Ainsi un éventuel hacker n’aura pas uniquement le mot de passe à trouver mais devra deviner le nom d’utilisateur, mais surtout, une fois sur la machine, il lui faudrait devenir root pour réussir à abimer la machine.

Je sens déjà venir la critique « oui mais toi le sudo ne demande pas de mot de passe ». Oui mais le hacker n’est pas censé le savoir ? Ah si… Je l’ai dit sur mon blog. Flûte. Du coup, de mon côté, j’ai décidé d’utiliser un système de clé privée clé publique pour l’authentification, j’explique plus bas comment. J’ai désactivé l’accès par authentification user/mot de passe.

Configuration de SSH pour interdire l’accès root

On édite le fichier de configuration avec son éditeur préféré, nano pour les noobs ou les feignants !

Une fois la configuration changée, il faut redémarrer le serveur ssh.

On peut aussi vérifier que sshd est bien configuré pour se lancer au démarrage pour quand on rebootera la machine ne pas se retrouver dans les choux :

Si il y a marqué enabled, c’est bon !

Sécurisation par clé privée / clé publique

Le principe est le suivant : sur l’ordinateur (le client) que l’on souhaite autoriser  à se connecter à notre serveur, on va créer un couple clé privée / clé publique.

Puis on va déposer la clé publique générée sur le serveur dans les dossiers de l’utilisateur qui a droit de l’utiliser. La clé privée, elle devrait automatiquement être stockée sur l’ordinateur client.

Pour générer les clés, on utilise la façon suivante :

On peut laisser par défaut le répertoire où sauver la clé. En revanche, je recommande fortement d’utiliser une passphrase pour sécuriser la clé, elle sera demandée à chaque connexion.

Ensuite on envoie la clé sur le serveur. Pas besoin de bricoler des fichiers textes, l’outil s’en charge pour nous :

Ensuite on teste la connexion :

Si une fois entrée la passphrase on est bien sûr le serveur, alors ça marche.

Une fois qu’on est sûr que ça fonctionne par le système de clés, on peut modifier ligne 68 pour indiquer PasswordAuthentitication no

A présent, il faudra toujours une authentification par clé pour se connecter. On pourra repasser ponctuellement le paramètre à yes pour faire les manipulations afin d’autoriser un nouveau client.

Lundi, je vous parlerai de zsh et de sa configuration ! Ça n’a pas grand chose à voire avec l’auto-hébergement de ses données personnelles, mais ça me fait plaisir !

Merci à Framasoft pour l'outil GéGé et à Gee de prêter ses personnages.

Merci à Framasoft pour l’outil GéGé et à Gee de prêter ses personnages.

Florck

Je suis Ingénieur en Technologies de l'Information, consultant en systèmes (GNU/Linux) et bases de données (Oracle). En recherche de contrôle sur mes informations personnelles : "La route est longue mais la voie est libre !"

3 réponses

  1. Paul dit :

    Je dis sans doute n’importe quoi, mais c’est pas dangereux de laisser trainer ces infos :
    The key fingerprint is:
    63:7d:65:23:84:70:fd:0a:82:b7:d3:cb:1a:70:1f:6a florck@machine_cliente
    The key’s randomart image is:
    +–[ RSA 2048]—-+
    | …o. |
    | …. |
    | . ..+ |
    | . o.. +.. |
    | ..S+o… |
    | +o+.o. |
    | Eo.. |
    | . .o |
    | .. |
    +—————–+

    ??

  2. Florck dit :

    Si c’était vraiment une clé active sûr mon serveur peut-être, mais en l’occurrence c’est un exemple construit de toute pièce sur une machine de test 😉
    Mais merci de ta vigilance, y a des risques qu’un jour quelque chose m’échappe !

  1. 1 janvier 2014

    […] puisqu’il est une reprise avec à peine une seule modification de l’article présenté ici pour les Raspberry Pi. Je me rends compte que j’avais oublié de le rajouter ici. C’est à présent chose […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *