Connexion SSH automatique

Vous en avez peut-être marre de sans arrêt devoir taper un mot de passe pour vous connecter à vos serveurs en ssh. Voir pire, ça vous inquiète de devoir passer en clair un mot de passe dans un script qui à besoin d’une connexion ssh.

Mais saviez-vous les amis qu’il est tout à fait possible de se passer de ce mot de passe ? Il suffit pour cela de configurer une reconnaissance du client par clef ssh. C’est à dire que la machine à partir de laquelle vous vous connectez publie une clef (sa signature), laquelle sera enregistrée sur le serveur ssh. Par la suite, le serveur ssh saura reconnaitre ce client, donc si la signature est identique, il ne demandera plus aucun mot de passe. Et tout ceci s’effectue en à peine quelques minutes !

Côté serveur, modification du sshd

La première chose à faire est d’aller effectuer une petite modification dans le fichier de configuration de ssh, le sshd_config. En effet, l’option de connexion sans mot de passe par clef est désactivée par défaut :

sudo nano /etc/ssh/sshd_config

# décommenter la ligne ci-dessous
AuthorizedKeysFile      %h/.ssh/authorized_keys

Une fois la ligne dé-commentée et le fichier enregistré, on redémarre le serveur ssh :

service ssh restart

Il est aussi possible d’effacer les clefs non utilisées et d’en générer une ed25519 toute neuve pour encore plus de prudence.

cd /etc/ssh
rm ssh_host_*key*
ssh_keygen -t ed25519 -f ssh_host_ed25519

Côté client, création et export des clefs ssh

Création de la clef

Là encore, l’opération est très simple et très rapide. On commence par créer une paire de clefs avec la commande ssh-keygen. On ne précisera pas de mot de passe pour protéger les clefs. Cette option est utile afin de vous permettre d’avoir un seul mot de passe pour l’ensemble de vos connexions ssh, au lieu d’un différent par serveur. Néanmoins, ça complique les choses dans un script, et puis vous n’avez cas garder un œil sur votre laptop ou chiffrer l’ensemble du disque (ça aide en cas de vol – ou de voyage en Chine) De même, je laisse l’emplacement de sauvegarde par défaut (suffit donc d’appuyer sur entrer).

Plusieurs algorithmes sont disponibles pour la création de clef ssh, le plus sécurisé étant le ed25519, c’est celui-ci que nous allons générer. Si cela vous intéresse vous pouvez lire un comparatif des différents algorithme sur le Stackexchange security. Quoi qu’il en soit, quelque soit l’algorithme utilisé, l’usage ne change ensuite absolument pas. L’avantage de ce dernier par rapport au RSA par exemple, est aussi d’avoir des clefs publiques plus courtes

Prenez garde car les clefs DSA ne sont plus supportées à partir de OpenSSH 7.

ssh-keygen -t ed25519
Generating public/private rsa key pair.
Enter file in which to save the key (/home/buzut/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/buzut/.ssh/id_rsa.
Your public key has been saved in /home/buzut/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:n2Blsvev8IXeCkPsAMEortJd/qm1BUEyMxsMbHgm5OA
The key's randomart image is:
+--[ED25519 256]--+
|...o.=B .        |
|.o+ * oX         |
| E.*  o o o      |
|  .   .. B       |
| o . o  S +      |
|o . . .. O o .   |
|.      ...O o .  |
|       .oo * +   |
|      ...   =oo  |
+----[SHA256]-----+

Export de la clef

Voici l’ultime et dernière étape avant de pouvoir se connecter sans entrer aucun mot de passe : exporter sur le serveur ssh, notre clef ssh nouvellement créée. Cette étape, triviale, s’effectue avec la commande ssh-copy-id user@serverAdress. Il va vous demander le mot de passe (pour la dernière fois). Une fois l’opération effectuée, testez : ssh user@serverAddress, hop vous devriez être connecté sans autre forme de procès, pratique !

Il peut arriver que la commande ssh-copy-id ne soit pas installée. Dans ce cas, on procède manuellement. Il faut copier la clef publique qui se trouve dans le dossier de l’utilisateur qui l’a créé donc ~/.ssh/id_rsa.pub, puis coller celle-ci dans le dossier .ssh du compte du serveur sur lequel vous voulez vous logguez dans le fichier authorized_keys (créez-le s’il n’existe pas déjà !).

Import de la clef

En parlant d’export, une même clef peut aisément être partagée entre différentes machines. Une machine de bureau et un portable par exemple. Lorsqu’on promène son .ssh d’une machine à l’autre, il faut bien veiller aux droits et au propriétaire des dossiers.

Sur Linux comme sur BSD (et donc Mac), chaque utilisateur dispose d’un dossier .ssh dans son dossier utilisateur. Il est possible d’avoir plusieurs clefs pour un même utilisateur. Vous pouvez par exemple importer sur votre Mac les clefs que vous venez de créer sur votre Linux.

Par prudence, on préférera les transférer sur une clef USB que de s’envoyer un mail ou de les faire passer par Dropbox…

Au niveau des permissions, comme c’est très souvent source d’erreur, le dossier ssh ainsi que les clefs doivent appartenir à l’utilisateur qui les utilisera :

chown -R your_user:your_user .ssh

Si vos utilisateurs n’ont pas le même nom sur les différentes machines, pensez-y ! En ce qui concerne les droits, 700 pour .ssh, 644 pour la clef publique et 600 pour la clef privée. Si vous avez également modifié le authorized_keys, c’est 600 également.

chmod 700 .ssh
chmod 644 id_ed25519.pub
chmod 600 .ssh/id_ed25519 .ssh/authorized_keys

Interdire la connexion par mot de passe

Maintenant que nous avons rendu notre système plus pratique, pourquoi ne pas aussi améliorer la sécurité en désactivant la connexion par mot de passe ? Ainsi, il vous sera impossible de vous connecter depuis tout ordinateur dont le certificat n’a pas été enregistré sur le serveur !

Pour ce faire, c’est très simple, décommenter et de mettre à no la directive suivante :

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

Déjà 7 réponses, rejoignez la discussion !

  • MagiCrazy

    dit :

    Très très bien, j’ajouterais que c’est une forme de sécurité qui se répand, puisque vous pouvez désactiver côté serveur la connexion par mot de passe et ne vous baser que sur ces clés :) Ca permettra de ne plus vous inquiéter lors des tentatives de bruteforce des botnets très très courantes sur internet.
    Pour simplifier les connexions ssh, il y a aussi la ssh_config client.
    http://linux.die.net/man/5/ssh_config
    Par exemple, au lieu de taper « ssh username@nom_de_serveur_un_peu_long », on peut configurer un Host dans ~/.ssh/config, avec un hostname et un user pour ne taper que « ssh prod » (cas pratique à mon taff) ^^

    • Buzut

      dit :

      Ah ça faisait longtemps que je ne t’avais pas croisé (faut dire que j’ai plus le temps de trainer sur l’irc aussi…).

      Génial la ssh_config client !! Je savais qu’il y avait moyen de faire ça (je l’avais lu un jour quelque part), mais je ne savais plus comment. Donc merci de tout me porter sur un plateau :D

      Pour la désactivation côté serveur de la connexion par mot de passe, j’y ai pensé, mais si tu pers ou te fait voler ton ordinateur « client », t’as plutôt intérêt à avoir un autre client sous le coude pour pouvoir accéder audit serveur, sinon, comment dire… t’es baisé…

      • Buzut

        dit :

        Bon ça y est, j’ai mis en place les hosts avec ssh_config_client, suffit de créer un fichier ~/.ssh/config
        Host alias
        HostName ip/vrai nom
        User login

        Et voilà le travail :)

        • MagiCrazy

          dit :

          Il y a pas mal d’autres options, c’est assez complet, même si c’est souvent très avancé. En tous les cas, c’est tellement génial d’en avoir beaucoup moins à taper à chaque fois ^^

          Au sujet de la clé SSH, c’est comme tout, faut du backup… Et au pire, chez les hébergeurs, t’as des modes rescue avec axx http://FTP... Enfin bon, ça reste une solution viable pour se prémunir contre les attaques en brute-force, et c’est moins chiant à retenir ^^

          • Buzut

            dit :

            Absolument, niveau pratique c’est certain c’est le top du top ! Je l’ai tout de suite mis en place. Pareil pour la sécurité c’est un bon point, j’ai désactivé la connexion par mdp aussi du coup.

            Et j’ai backup sur un autre serveur qui lui prend une connexion ssh par pass, comme ça, même si je me retrouve à poil, j’aurais toujours une solution de secours :).

  • MagiCrazy

    dit :

    Allez, j’en rajoute !
    Il y a pas mal d’options intéressantes que je suis en train de tester sur le fichier de configuration client SSH :
    ControlMaster et ControlPath qui permettent de n’ouvrir qu’une seule connexion pour plusieurs sessions,

    DynamicForward qui permet de forward un port (ou d’ouvrir un tunnel SOCKS5 pour s’esquiver au proxy du travail…)

    ForwardAgent qui permet de s’identifier une bonne fois pour toutes (avec un ssh-add le matin !),

    Port, pour ceux qui n’aiment pas le chiffre 22,

    et plein plein d’autres (mais ce sont celles que j’ai regardé principalement aujourd’hui !).

    A bientôt =)

    • Buzut

      dit :

      Ahh c’est très bon à savoir tout ça !

      Il est un fait que je suis habituellement très adepte des ssh -D port-local user@hostname

      Selon le degré d’hostilité de l’endroit duquel je me connecte, ça s’avère salvateur ;)

Laisser un commentaire

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