Ellendhel's Blog

LinuxLe mystère de la clé SSH refusée

Parmi les recommandations les plus courantes lors de l'utilisation du protocole SSH, l'utilisation de clés est probablement la plus fréquente.

Utiliser une paire de clés (publique et privée) en lieu et place d'un mot de passe améliore la sécurité lors de l'authentification et permet d'automatiser les connections et transferts de fichiers vers une machine distante.

Et donc par défaut, je génère une paire de clés pour tout nouveau système auquel je dois me connecter régulièrement.

Le problème auquel je me suis confronté est le suivant : ayant accès à un nouveau serveur, je crée les clés nécessaires, effectue l'installation initiale et teste le tout. Aucun souci.

Puis quelque jours suivants, ayant besoin de me connecter à un de mes serveurs habituels (et non pas le nouveau), ma connexion SSH échoue avec le message "Too many authentication failures".

Mon premier réflexe est de vérifier que mon fichier de configuration SSH est correct (ce qui est le cas) puis de tenter la même opération en augmentant la verbosité des messages d'erreurs. Pas de solution, le message d'erreur demeure identique.

Ayant accès direct au serveur en question je vérifie les fichiers journaux qui confirment que trois tentatives d'authentification ont effectivement échoué, ce qui est étrange, car je n'effectue qu'une connexion à chaque fois.

Je tente alors d'effectuer une connexion SSH "pure" en utilisant un mot de passe et non pas de clé. Succès. Puis une autre connexion en ne chargeant uniquement la clé destinée à ce serveur avec ssh-agent. Succès à nouveau.

Il semble donc que le problème soit lié à l'utilisation de la clé avec ssh-agent ; non pas que la clé ne soit pas chargée correctement, mais qu'une "mauvaise" clé soit utilisée à la place. En continuant sur cette piste je réalise qu'à partir du moment où ma clé SSH est listée en quatrième position ou plus avec ssh-agent, l'accès est refusé. Ce qui correspond aux erreurs vues précédemment dans les fichiers journaux.

En vérifiant le fichier de configuration d'OpenSSH sur le serveur cible, je vois qu'une des directives est "MaxAuthTries" avec une valeur de "3". La page de manuel est assez claire, indiquant que cette valeur est le nombre d'essais maximum autorisés, la valeur par défaut étant "6".

Et c'est là que je comprend où se trouve la source du problème : ssh-agent charge un certain nombre de clés lors de l'ouverture de ma session, clés chargées dans l'ordre alphabétique des noms de fichiers.

Lors d'une nouvelle connexion ssh-agent envoie au serveur toutes les clés listées dans l'ordre où elles ont été chargées (ce que l'on peut vérifier avec la commande ssh-add -l) jusqu'à ce qu'une des conditions suivantes soit remplie : 1) la clé appropriée est disponible et la session SSH est établie ou 2) le serveur ayant refusé plus de "mauvaises clés" que la valeur de la directive "MaxAuthTries" le message d'erreur "Too many authentication failures" est retourné.

La solution consiste donc simplement à augmenter la valeur de la directive "MaxAuthTries" sur le serveur, de manière à ce que la clé appropriée puisse être chargée et utilisée automatiquement.

Au final quelques recommandations pour l'utilisation de clés SSH :

- Ne pas charger toutes les clés existantes avec ssh-agent, limitez-vous au nécessaire, quitte à ajouter de nouvelles clés en cours de session.

Je n'ai pas effectué de test avec PuTTY et Pageant mais il est probable que la situation soit identique.

- Ne pas définir de valeur trop faible pour la directive "MaxAuthTries" ; elle n'est pas utilisée uniquement pour l'authentification par mot de passe, mais pour toute forme d’authentification.

publié le 21 août 2019

lien direct

LinuxGestion de comptes utilisateurs sous Linux

Parmi les tâches assignées à un administrateur système se trouve la gestion des comptes utilisateurs. C'est à dire permettre à plusieurs personnes d'accéder à des ressources, de manière sécurisée, en tenant compte des besoins de chacun et si possible, simple à mettre en œuvre.

Lorsqu'il s'agit d'une ou deux personnes à ajouter, de manière ponctuelle, la création d'un compte sur le système peut se faire manuellement en utilisant adduser (qui fonctionne de manière interactive) ou useradd (qui nécessite plusieurs paramètres). Évidemment les choses deviennent plus compliquée dès que plus de personnes sont concernées ("Two is company, three's a crowd").

adduser est une solution à exclure, useradd peut-être utile pour écrire votre propre script, qui est généralement la solution préconisée.

Une autre solution existe : la commande newusers ; cette commande est effectivement destinée à ajouter des utilisateurs en masse. Le principe est de préparer un fichier équivalent à /etc/passwd, à ce détail que le mot de passe est conservé en clair, et de l'utiliser comme argument pour cette commande. Tous les utilisateurs listés seront crées, ainsi que leur répertoires personnels.

Admettons que vous ayez une série de nouveaux utilisateurs à créer, votre fichier d'import ressemblera à ceci :

ash:o+uykC49Hw:2001:500:Ash:/home/ash:/bin/bash
ava:ct2yYGu2o*:2002:500:Ava:/home/ava:/bin/bash
bender:sF8\guswB1:2003:500:Bender:/home/bender:/bin/bash
ed-209:tko+8Cj1Kk:2004:500:ED-209:/home/ed-209:/bin/bash
glados:hn3+qep4EO:2005:500:GLaDOS:/home/glados:/bin/bash
hal:Oya4uF8sj{:2006:500:HAL:/home/hal:/bin/bash
jarvis:a%bfi2ID1t:2007:500:Jarvis:/home/jarvis:/bin/bash
joshua:udH}8Gmzq4:2008:500:Joshua:/home/joshua:/bin/bash
optimus:po8uh#M5oZ:2009:500:Optimus Prime:/home/optimus:/bin/bash
r2-d2:9@lIh3inQa:2010:500:R2-D2:/home/r2-d2:/bin/bash
t-800:z5flLDw=1z:2011:500:T-800:/home/t-800:/bin/bash
wall-e:e5q%3NMfut:2012:500:Wall-E:/home/wall-e:/bin/bash

Générer ce fichier requiert quelques étapes préliminaires :

- Définir les comptes utilisateurs. Notre exemple ne comporte pas vraiment de cas particulier, mais vous pouvez vous retrouver à à gérer des noms particulièrement longs, ou avec des caractères spéciaux (espace, apostrophe, accents, ...). Ces identifiants seront probablement aussi ceux que vous utiliserez pour le répertoire personnel de chacun, vous devez donc vous assurer qu'ils n'engendreront pas de problème au niveau du système de fichiers.

Une règle que vous pouvez choisir d'appliquer est normaliser tous les identifiants en n'acceptant que certains caractères (de a à z, minuscules uniquement, chiffres et le symbole tiret). La gestion des collisions (deux personnes ayant un identifiant potentiellement identique) doit aussi être préparée à l'avance. La lecture du chapitre 8 "Namespaces" du livre "The Practice of System and Network Administration" à ce sujet est recommandée.

- Générer des mots de passe. Vous pouvez assigner un mot de passe unique à chaque utilisateur avec l'aide de la commande mkpasswd. Vous pouvez facilement contrôler l'utilisation de chiffres, caractères spéciaux et la longueur du mot de passe.

La première chose à s'assurer est que ce fichier est proprement sécurisé (droits d'accès minimum, une seule copie de travail, ...). Vous devrez conserver au moins une copie après utilisation pour founir le mot de passe initial à chaque utilisateur, après cela le fichier pourra être supprimé.

Une fois votre fichier d'import préparé, il est fortement recommandé de le tester avant utilisation. Là encore, une commande existe pour cette tâche en particulier : pwck. Utilisez cette commande avec les options -q et -r sur votre liste pour repérer les possibles erreurs.

Si votre liste d'utilisateurs est facilement accessible en consultation (base de données, annuaire, ...) la mise en place d'une solution automatique pour ajouter de nouveaux utilisateurs peut se faire aisément.

publié le 20 juin 2016

lien direct

LinuxContrôler votre historique de commandes

Une des fonctions couramment utilisée avec l'interpréteur de commandes Bash est l'historique de commandes : par une simple pression sur la touche fléchée "Haut" vous retrouvez les commandes lancées précédemment, avec leurs options. Vous pouvez éviter de fastidieuses saisies, limiter les erreurs et être plus efficace d'un manière générale.

Ce qui est parfois moins connu est l'utilisation de la commande history, qui affiche l'intégralité de commandes sauvegardées (500 lignes par défaut). Cet historique n'est toutefois pas parfait, entre autre exemple aucune date ou heure n'est indiquée.

Cela se règle assez facilement en déclarant une variable dans votre fichier ~/.profile :

export HISTTIMEFORMAT='%F %T '

Une fois le fichier enregistré, vous pouvez appliquer ce nouveau paramètre dans votre session :

source ~/.profile

Et la commande history vous donnera maintenant la date et l'heure pour chaque entrée de votre historique.

Mais dans certaines situations vous ne souhaitez pas que certaines commandes soit enregistrées. L'exemple le plus évident est lors de l'utilisation de commandes intégrant un mot de passe en clair (mysql, smbclient ou testsaslauthd entre autre). Une autre option peut être ajoutée à votre fichier .profile pour déclarer des exceptions :

export HISTIGNORE="mysql *:smbclient *:testsaslauthd *"

Toute ligne de commande débutant par une des commandes listées suivies d'un espace et d'arguments ne sera pas inclue dans votre historique.

Il reste quelques rares cas où vous souhaitez qu'une commande soit ignorée, mais que vous n'avez pas définie à l'avance. Bash propose alors une option supplémentaire adaptée à cette situation :

export HISTCONTROL=ignorespace

Toute commande débutant par un espace sera alors ignorée dans l'historique, sans que cela interfère lors de l'exécution.

Bash dispose d'autres options liées à l'historique de commandes, que vous pouvez trouver dans la page de manuel correspondante.

publié le 29 janvier 2016

lien direct