Forum Linux.débutant Probléme de script automatisation de nouvel user sur serveur

Posté par syhnes le 12 septembre 2024 à 12:05. Licence CC By‑SA.

Étiquettes : aucune

sept.

2024

Bonjour, je suis étudiant en première année de Dev (c'est ma première semaine en entreprise et il n'y a pas de dev pour m'aider là ou je travaille)

et… je suis en train de m'arracher les cheveux sur un script (cheveux que je n'ai déjà plus :,/)

Je découvre linux.

*voici la situation initiale: *

j'ai installé un serveur local avec linux serveur.

Par soucis de sécurité, j'ai bloqué tout les port (sauf un) et j'autorise au cas par cas les accés via l'adresse IMAC de la machine client.

Comme je suis faignant, j'essaye d'automatiser tout ça (je suis encore aus tade script kidies donc je ne comprend pas encore tout. j'ai fouillé sur google, un peu dans tout le sens (même Gpt pour dire).

mais en gros:

j'ai une clef USB avec un petit script qui me permet de récupérer l'adresse MAC de l'ordi client, le nom de l'utilisateur et son mot de passe.

Tout cela est enregistré dans un fichier "credential.txt" sur ma clef usb tel que:
Adresse MAC : 12:34:56:78:99:00 Nom d'utilisateur : test6 Mot de passe : password(Lorsque je créé un utilisateur à la mano, pas de problème, tout marche. J'arrive à implémenter un nouvel utilisateur, et à me connecter avec.)

Ensuite, je met ma clef usb sur mon serveur, et je lance mon script (que j'ai apellé NU pour Nouvel Utilisateur)

*Le soucie est le suivant: *

Le script arrive à ajouter l'adresse mac dans les adresses autorisées (iptables)

Mais je me retrouve avec un message d'erreur:

david@Bishop:~$ NU
Montage de la clé USB...
[sudo] password for david:
Adresse MAC (debug) : 'XX:XX:XX:XX:XX:XX' 
(j'ai remplacé l'adresse mac par XXXXXX sur le forum hein 00)
L'adresse MAC XX:XX:XX:XX:XX:XX a été autorisée pour l'accès via le port XXXXX (idem normalement y a mon port ici).
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
La règle autorisant l'adresse MAC XX:XX:XX:XX:XX:XX sera supprimée dans 2 mois.
.réation du nouvel utilisateur test6
': use --badname to ignore 'test6
useradd: failure while writing changes to /etc/passwd
) pam_chauthtok() failed, error:
Authentication token manipulation error
) password not changedr test6
.rreur lors du changement de mot de passe pour l'utilisateur test6
Vous pouvez retirer la clé USB.

Voilà ma problématique.

Je rajoute ici le code de mon script:

#!/bin/bash

# Définir-tion point montage
usb_mount="/mnt/usb"

# if pas de point de montage
if [ ! -d "$usb_mount" ]; then
    echo "Création du point de montage $usb_mount..."
    sudo mkdir -p "$usb_mount"
fi

# Detect periph USB
device="/dev/sdc2"

# If periph umount
if ! mount | grep "$usb_mount" > /dev/null; then
    echo "Montage de la clé USB..."
    sudo mount "$device" "$usb_mount"
    if [ $? -ne 0 ]; then
        echo "Erreur : Impossible de monter la clé USB." >&2
        exit 1
    fi
fi

# Path credentials.txt on USB
credentials_file="$usb_mount/credentials.txt"

# if credentials.txt exist?
if [ ! -f "$credentials_file" ]; then
    echo "Le fichier credentials.txt n'a pas été trouvé sur la clé USB." >&2
    sudo umount "$usb_mount"
    exit 1
fi

# read credentials.txt
macAddress=$(grep "Adresse MAC" "$credentials_file" | cut -d ':' -f2- | xargs | tr -d '[:space:]')
newUser=$(grep "Nom d'utilisateur" "$credentials_file" | cut -d ':' -f2 | xargs)
newPassword=$(grep "Mot de passe" "$credentials_file" | cut -d ':' -f2 | xargs)

# Debug : Afficher l'adresse MAC (quotes pour voir les espaces invisibles)
echo "Adresse MAC (debug) : '$macAddress'"

# Valid MAC (format de type XX:XX:XX:XX:XX:XX)
if [[ ! "$macAddress" =~ ^([a-fA-F0-9]{2}:){5}[a-fA-F0-9]{2}$ ]]; then
    echo "Erreur : Adresse MAC invalide. Veuillez utiliser le format XX:XX:XX:XX:XX:XX."
    sudo umount "$usb_mount"
    exit 1
fi

# Insert rules iptables first position on good port (partage forum: port remplacé par XXXX)
sudo iptables -I INPUT 1 -p tcp --dport XXXX -m mac --mac-source "$macAddress" -j ACCEPT
echo "L'adresse MAC $macAddress a été autorisée pour l'accès via le port XXXX."

# Règles iptables persistante
sudo netfilter-persistent save

# Plan supr rules 2 month 
cronCommand="sudo iptables -D INPUT -p tcp --dport 56723 -m mac --mac-source $macAddress -j ACCEPT"
cronJob="0 0 $(date --date='+2 months' '+%d') $(date --date='+2 months' '+%m') * $cronCommand"
(crontab -l 2>/dev/null; echo "$cronJob") | crontab -
echo "La règle autorisant l'adresse MAC $macAddress sera supprimée dans 2 mois."

# Create/Update user
if id "$newUser" &>/dev/null; then
    echo "L'utilisateur $newUser existe déjà. Mise à jour de son mot de passe."
else
    echo "Création du nouvel utilisateur $newUser."
    sudo useradd -m -s /bin/bash "$newUser" || sudo useradd -m -s /bin/bash --badname "$newUser"
fi

# Changepasswrd if exist
echo "$newUser:$newPassword" | sudo chpasswd
if [ $? -ne 0 ]; then
    echo "Erreur lors du changement de mot de passe pour l'utilisateur $newUser."
else
    echo "Le mot de passe de l'utilisateur $newUser a été mis à jour."
fi

# Suppr credentials.txt
sudo rm -f "$credentials_file"

# Umount USB
sudo umount "$usb_mount"


echo -e "\e[32mVous pouvez retirer la clé USB.\e[0m"

Existe t il une solution, et si oui, dans quelle diréction dois je chercher? parceque là j'ai l'impression de creuser avec une pelle de plage dans une dalle en béton ><

# à creuser

Posté par gaaaaaAab le 12 septembre 2024 à 17:31. Évalué à 3 (+1/-0).

useradd: failure while writing changes to /etc/passwd

si j’interprète bien, ce message suggère que useradd a bien essayé de faire l'ajout. Il faut voir pourquoi l'écriture du fichier n'aurait pas fonctionné. Deux pistes plausibles:
la partition où il y a /etc est pleine, ou elle est montée en lecture seule peut-être ?

Répondre
- [^] # Re: à creuser
  
  Posté par Voltairine le 14 septembre 2024 à 18:19. Évalué à 2 (+1/-0). Dernière modification le 14 septembre 2024 à 18:21.
  C'est possible, mais le message d'erreur bien que bizarrement mis en forme est assez explicite : il s'agit apparemment d'un nom d'utilisateur contenant des caractères non autorisés :
  
  ': use --badname to ignore 'test6
  
  C'est facile à reproduire en lançant la commande avec par exemple tes:t comme nom d'utilisateur.
  
  Sur une Debian, voir le fichier /etc/adduser.conf, extrait :
```
# Non-system user- and groupnames are checked against this regular
# expression.
# Default: NAME_REGEX="^[a-z][-a-z0-9_]*\$?$"
#NAME_REGEX="^[a-z][-a-z0-9_]*\$?$"
```
  Comme on ne voit pas de caractère interdit dans le retour, je suppose que le nom réel a été caviardé…
  
  N.B. : le seule présence de l'option peu usitée --badname laisse supposer qu'il ya eu un souci dès le départ avec le nom d'utilisateur.
  Répondre
  - [^] # Re: à creuser
    
    Posté par gaaaaaAab le 15 septembre 2024 à 05:48. Évalué à 2 (+0/-0).
    il s'agit apparemment d'un nom d'utilisateur contenant des caractères non autorisés
    
    oui, mais c'est pas si simple que ça, sinon, syhnes poserait pas la question ;)
    
    mais bien vu, ton commentaire me fait reconsidérer mes assomptions initiales:
    - si le nom était faux, syhnes s'en serait rendu compte
    - le nom d'utilisateur est bien test6 (idem)
    - le script sait gérer les noms invalides puisqu'il fait "useradd (…) || useradd -badname (…), cad que dans le cas ou le nom est incorrect, le premier useradd va échouer et afficher cette erreur sur stderr, mais ensuite, useradd avec l'option badname va être lancée.
    - ajouter un chiffre dans le nom, ça paraît pas particulièrement invalide,
    D'autre part, les partitions pleines, ça fait souvent des symptôme déroutants et on ne pense pas toujours à regarder ça. Sur un serveur pro, on peut espérer qu'il y a du monitoring, mais sur un poste de travail, pas forcément.
    
    Suite à ton commentaire, j'ai une autre piste, mais basée sur une hypothèse que je n'ai pas vérifiée. L'hypothèse est que l'option badname gère plus de caractère que la normale, mais peut-être pas tous les caractères. Ça vaudrait p-e le coup de vérifier si les changements de ligne du fichier de config serait pas au format CRLF
    Répondre
    - [^] # Retour chariot
      
      Posté par Arthur Accroc le 15 septembre 2024 à 07:51. Évalué à 2 (+0/-0).
      Ça vaudrait p-e le coup de vérifier si les changements de ligne du fichier de config serait pas au format CRLF
      
      C’est sûrement le problème, puisque echo "Création du nouvel utilisateur $newUser." affiche
      
      .réation du nouvel utilisateur test6
      
      Cette modification devrait supprimer le retour chariot (je ne l’ai pas testée ; à ajouter aussi aux autres lignes) :
      
      newUser=$(grep "Nom d'utilisateur" "$credentials_file" | tr -d '\r' | cut -d ':' -f2 | xargs)
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
      Répondre
      - [^] # Re: Retour chariot
        
        Posté par gaaaaaAab le 15 septembre 2024 à 14:16. Évalué à 2 (+0/-0).
        
        je m'étais concentré sur le problème, j'avais pas trop regardé le reste. ça fait beaucoup de commande pour extraire juste un mot ! :)
        (en notant que l'appel a xargs me semble inutile)
        
        on peut aussi utiliser awk (ou sed, et probablement un grep bien écrit avec l'option -o quand elle est disponible)
        
        awk '{sub(/\r/,"",$NF); print $NF}'
        
        Dans les améliorations possible, on peut aussi commencer par mouliner le fichier d'entrée pour qu'il soit toujours en fin de ligne format Unix. Comme c'est un script qui a vocation a tourner sous ce type d'environnement, ça n'a pas beaucoup de sens de garder CRLF. Tous les éditeurs windows potables savent aussi gérer le simple LF de nos jours.
        
        Ça serait aussi mieux d'utiliser un format de fichier différent. Soit directement des affectations de variable en shell, soit un format structuré (.ini, .json, .yaml, …)
        
        Répondre
# pour apporter mon petit grain de sable a la dalle en beton

Posté par guitou le 12 septembre 2024 à 19:11. Évalué à 4 (+3/-0). Dernière modification le 13 septembre 2024 à 09:20.
Hello,

Avec une petite recherche gogol sur pam_chauthtok() failed, error: Authentication token manipulation error, je tombe sur ce lien. Meme si tu n'es pas sous Ubuntu, tu peux toujours verifier:
- si ta partition racine est elle montee en lecture seule sudo mount -o remount,rw /
- si mauvaises permissions du fichier shadow sudo chmod 640 /etc/shadow
Plus generalement, c'est souvent plus prudent de commencer tout script shell par un petit set -eu, le "e" pour s'arreter a la premiere erreur, le "u" pour s'eviter les problemes de variables non definies. Et pour le debug, rajouter un "x" te permet d'afficher les commandes executees.

Enfin, tu peux faire directement:
```
sudo useradd -m -s /bin/bash --badname "$newUser"
```
++
Gi)
Répondre
- [^] # Re: pour apporter mon petit grain de sable a la dalle en beton
  
  Posté par MicP le 15 septembre 2024 à 12:32. Évalué à 2 (+1/-0).
  
  Bonjour
  
  Si tu dois utiliser la commande sudo dans ton script, autant lancer directement le script avec sudo.
  
  Répondre
# Un peu d'aide au debugage

Posté par Gauthier Monserand (site web personnel) le 13 septembre 2024 à 09:44. Évalué à 3 (+2/-0).

Rajouter sur la deuxième ligne de ton fichier :

set -x

Cela va t'afficher les commandes que le script essaie d'executer. Tu pourras ainsi plus facilement les tester à la main

Répondre
# nom d'utilisateur

Posté par Chris K. le 20 septembre 2024 à 13:36. Évalué à 2 (+0/-0).

La réponse est dans le retour de useradd : il n'aime pas test6 comme nom d'utilisateur.

Le man de useradd te donnes une solution :
--badname Allow names that do not conform to standards.

Sinon modifier la vérification pour que "test6" puisse passer mais je ne sais pas ou cela se passe pour useradd, adduser utilise une expression régulière dans son /etc/adduser.conf qui est personnalisable.

Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.