Le nom d'utilisateur dans Unix est-il sensible à la casse?

20

Est ssh abc@servernamedifférent de ssh Abc@servername? Le cas du nom d'utilisateur est-il important sous Unix?

Mon utilisateur s'authentifie via LDAP.

login authentication case-sensitivity saga saga
la source
3
Presque tout sous Linux est sensible à la casse. Signification: cdn'est pas la même chose que CD... La seule façon de vraiment les faire signifie la même chose est de définir des alias dans votre .bashrcfichier ..
ryekayo
1
Je suppose que cela dépend de l'attribut LDAP que vous utilisez pour le nom d'utilisateur. Si c'est uid de RFC 4519 , alors il ne respecte pas la casse, mais les implémentations d'authentification peuvent toujours imposer une signification de casse par-dessus. Cela dépend également de la façon dont l'authentification est effectuée avec LDAP.
Stéphane Chazelas
1
Une simple tentative de connexion avec votre nom d'utilisateur en majuscule aurait répondu à cette question en quelques secondes.
Courses de légèreté avec Monica

Réponses:

14

Tout comme les noms d'hôte et les noms de domaine, le nom d'utilisateur n'est pas strictement une chose Unix mais peut et couvre souvent un plus large éventail de types de systèmes d'exploitation.

Le fait qu'ils soient considérés comme sensibles à la casse dépend alors de la norme utilisée pour les spécifier.

Les noms d'hôte et les noms de domaine sont clairement insensibles à la casse selon la norme DNS (voir RFC4343 ).

Les noms d'utilisateurs stockés sur un backend local (/ etc / passwd) ou un style Unix (NIS) ne sont pas sensibles à la casse selon la norme POSIX .

Les noms d'utilisateurs stockés dans un backend LDAP ou Active Directory suivront la définition de schéma d'attribut utilisée uidet cnqui stockent souvent le nom d'utilisateur ont des attributs de schéma différents, insensibles à la casse pour le premier mais sensibles à la casse pour le second. Cela signifie les deux Abcet abcpeut correspondre ou non à abcl'entrée en fonction de la configuration du serveur LDAP.

En raison de cette incohérence, je recommanderais de n'utiliser que des minuscules pour les noms d'utilisateur et le nom d'hôte / domaine, puis d'éviter ssh [email protected]ce qui est grossier de toute façon.

jlliagre
la source
1
Donc, la façon dont je lis le standard POSIX , car il n'est pas spécifié comme sensible à la casse ou sensible à la casse et l'ensemble du jeu de caractères de nom de fichier portable est disponible (qui comprend les majuscules et les minuscules), il dépend de l'implémentation. Est-ce exact? Cela étant dit, existe-t-il une convention standard?
Doug R.
1
@DougR. En ce qui concerne POSIX, les noms d'utilisateur dépendent de la casse. L'insensibilité à la casse aurait autrement été spécifiée. La casse est implicite lors de la référence au jeu de caractères de nom de fichier portable.
jlliagre
Merci pour la clarification. C'était mon hypothèse initiale, mais je n'ai rien trouvé concernant le jeu de caractères de nom de fichier portable qui l'indiquait d'une manière ou d'une autre.
Doug R.
5

Oui, il est sensible à la casse. Je ne suis pas en mesure d'apporter des informations techniques, je viens de les tester et je me demande pourquoi vous ne l'avez pas (?)

ma machine locale est linux mint comme vous pouvez le voir:

# cat /etc/*release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.2
DISTRIB_CODENAME=rafaela
DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
cat: /etc/upstream-release: Is a directory

et j'ai essayé de me connecter au serveur CentOS comme ceci:

· Utilisation d'un nom d'utilisateur en majuscules (incorrect): 

8D prova # ssh Root@agora-server
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password:

· Utilisation d'un nom d'utilisateur correct:

8D prova # ssh root@agora-server
root@agora-server's password: 
Last login: Fri Oct  2 01:50:13 2015 from 192.168.0.31
[root@agora-server ~]#
lèse
la source
En tant que problème secondaire, ce n'est pas une bonne pratique en termes de sécurité d'autoriser la connexion SSH en tant que root comme cela a été fait ici (en particulier si la machine est connectée à Internet). dans le sshd_config. Il est préférable de se connecter en tant qu'utilisateur normal, puis d'utiliser sudo ou su pour devenir root uniquement en cas de besoin.
JohnGH
Oui, c'est exact, je suis d'accord, d'abord parce que c'est un superutilisateur, et deuxièmement, le nom d'utilisateur «root» est connu de l'attaquant, qui n'a qu'à attraper le mot de passe. Quoi qu'il en soit, il s'agit en fait d'une machine virtuelle fonctionnant localement, non exposée aux internés. La bonne pratique consiste à utiliser les certificats rsa ssh pour se connecter, ou / plus à ouvrir le port ssh uniquement pour les demandes provenant des adresses autorisées (règles de pare-feu)
lee
3

Dans le cas des comptes locaux, le nom d'utilisateur est sensible à la casse. Lorsque vous utilisez LDAP, cela dépend. J'ai vu des cas où le nom d'utilisateur est sensible à la casse (sur une appliance ZFS connectée à LDAP) et des cas où cela n'a pas d'importance comme le client Solaris LDAP connecté à Windows AD.

Ce que vous devriez / pourriez essayer de voir si votre système utilise correctement LDAP en émettant getent passwd <username>. L'utilisation de cette commande devrait vous donner un enregistrement avec le nom d'utilisateur, le répertoire personnel et le shell pour l'utilisateur spécifié. Si vous ne voyez pas un tel enregistrement, LDAP n'est pas configuré correctement.

Il y a plusieurs endroits où vous devez configurer LDAP et l'un des endroits est:

/etc/nsswitch.conf

passwd: files ldap
group:  files ldap

Vous devez également vérifier si PAM est correctement configuré et peut-être l'étape la plus importante consiste à vérifier si le client LDAP est configuré et fonctionne. Essayez un outil comme ldapsearchpour vérifier si LDAP peut être interrogé.

Plusieurs livres de recettes LDAP sont disponibles et la plupart dépendent de la version Unix et de la version LDAP que vous utilisez. Mettez à jour votre question avec ces détails si vous avez besoin d'aide. Incluez également votre configuration (sans mots de passe bien sûr) qui peut aider les membres du forum à analyser votre problème particulier.

Lambert
la source
1

Les noms d'utilisateur Unix sont définitivement sensibles à la casse, et de plus, l'utilisation de noms d'utilisateur avec des caractères majuscules sur les systèmes Unix peut produire des résultats indésirables, donc devrait généralement être évité.

Quelques exemples sont:

Il peut casser le courrier électronique de l'utilisateur. Les normes pour SMTP autorisent les adresses e-mail à ne pas respecter la casse, et par défaut, le MTA qui reçoit le message pliera l'adresse e-mail en minuscules pour trouver l'utilisateur à livrer. Si le nom d'utilisateur a des caractères majuscules, il ne sera pas résolu sans remplacements de configuration spéciaux pour répondre à cela. (cela affecte les MTA tels que sendmail, postfix, etc. et également les agents de traitement de la livraison comme procmail)

De nombreux premiers terminaux matériels n'étaient pas sensibles à la casse. Il était courant qu'ils n'utilisent que des majuscules. Lorsque vous vous connectez à certaines versions d'Unix, le démarrage d'un nom de connexion avec un caractère majuscule déclenchera le système à supposer que vous utilisez un ancien terminal uniquement en majuscules et il permettra le pliage de la casse - qui convertit tous vos majuscules saisies en minuscules ( vous devez ensuite échapper les caractères majuscules pour dire qu'ils sont en majuscules) pour vous aider à entrer votre nom d'utilisateur qui, selon lui, sera en minuscules. Je ne crois pas que ce soit quelque chose sous Linux, mais je l'ai vu démontré sur HP-UX.

Comme il a longtemps été la convention d'utiliser uniquement des caractères en minuscules dans les noms d'utilisateur, il est raisonnable de s'attendre à ce que d'autres outils (certains auxquels nous n'avons peut-être pas pensé) sur le système puissent également supposer que le nom d'utilisateur doit être en minuscules et effectuer des vérifications, des conversions, etc. en conséquence, brisant ainsi les choses pour cet utilisateur.

JohnGH
la source
0

Les noms d'utilisateur sont définitivement sensibles à la casse. Vous pouvez facilement tester cela en ajoutant deux utilisateurs avec des noms similaires:

~ # useradd foobar
~ # useradd fooBar
~ # grep ^foo /etc/passwd
foobar:x:1001:1001::/home/foobar:/bin/sh
fooBar:x:1002:1002::/home/fooBar:/bin/sh

Cette question / réponse montre comment compenser quelqu'un qui essaie de se connecter avec un nom d'utilisateur qui a le "mauvais" cas selon les serveurs LDAP. Mais notez que cela ne fonctionnera que si les noms d'utilisateur sont tous répertoriés en minuscules (ou vous pouvez tous les mettre en majuscules si vous le souhaitez).

Falsenames
la source