Définir le mot de passe sudo différemment de la connexion un

En tant qu'utilisateur privilégié, j'essaie de définir un sudomot de passe différent de celui utilisé lors de la connexion.

J'ai fait quelques recherches mais je n'ai pas trouvé de réponse. Prend en sudocharge ce type de configuration?

Si jamais vous perdez votre mot de passe, vous perdez tout. Quelqu'un pourrait se connecter et se promouvoir rootavec le même mot de passe.

sudoa une option pour demander le rootmot de passe au lieu du mot de passe utilisateur invoqué, ( rootpw), mais le partage du rootmot de passe n'est certainement pas une option, c'est pourquoi nous avons mis en place sudo.

Je l'ai fait config 2FAdans le passé, cela a très bien fonctionné, mais cela défait également l'objectif d'automatisation. Par exemple, si vous souhaitez exécuter une commande privilégiée sur une douzaine de serveurs avec un expectscript, l'ajout 2FAne vous permet pas de le faire.

La solution la plus proche que j'ai trouvée consiste à autoriser uniquement la clé privée SSH et la phrase de passe de configuration avec une clé qui diffère du sudomot de passe (de connexion). Pourtant, ce n'est pas confortable, car dans une situation d'urgence, vous ne pouvez pas vous connecter avec un PC où il n'a pas cette clé.

Si vous souhaitez demander le mot de passe root, par opposition au mot de passe de l'utilisateur, vous pouvez insérer des options /etc/sudoers. rootpwen particulier, il demandera le mot de passe root. Il y a runaspwet targetpwaussi; voir la page de manuel sudoers (5) pour plus de détails.

En dehors de cela, sudo fait son authentification (comme tout le reste) via PAM. PAM prend en charge la configuration par application. La configuration de Sudo est dans (au moins sur mon système Debian) /etc/pam.d/sudo, et ressemble à ceci:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

En d'autres termes, par défaut, il s'authentifie comme tout le reste sur le système. Vous pouvez modifier cette @include common-authligne et demander à PAM (et donc à sudo) d'utiliser une autre source de mot de passe. Les lignes non commentées dans common-auth ressemblent à quelque chose (par défaut, ce sera différent si vous utilisez par exemple LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Vous pouvez par exemple utiliser, pam_userdb.soau lieu de pam_unix.so, et stocker vos mots de passe alternatifs dans une base de données Berkeley DB.

Exemple

J'ai créé le répertoire /var/local/sudopass, propriétaire / groupe root:shadow, mode 2750. À l'intérieur, j'ai continué et créé un fichier de base de données de mots de passe en utilisant db5.1_load(qui est la version de Berkeley DB utilisée sur Debian Wheezy):

# umask 0027
# db5.1_load -h / var / local / sudopass -t hash -T passwd.db
anthony
WMaEFvCFEFplI
^D

Ce hachage a été généré avec mkpasswd -m des, en utilisant le mot de passe "mot de passe". Très hautement sécurisé! (Malheureusement, pam_userdb ne semble pas prendre en charge mieux que l'ancien crypt(3)hachage).

Maintenant, modifiez /etc/pam.d/sudoet supprimez la @include common-authligne, et placez-la à la place:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Notez que pam_userdb ajoute une .dbextension à la base de données passée, vous devez donc laisser cette option .dbdésactivée.

Selon dannysauer dans un commentaire , vous devrez peut-être également effectuer la même modification /etc/pam.d/sudo-i.

Maintenant, pour sudo, je dois utiliser à la passwordplace de mon vrai mot de passe de connexion:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit travaillé'
[sudo] mot de passe pour anthony: passwordRETURN

ça a marché

Pour Redhat / Centos, l'exigence peut être satisfaite en suivant les étapes suivantes:

Créez un utilisateur personnalisé et passez:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Modifiez le fichier sudo pam.d pour qu'il ressemble à:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Je cherche toujours le moyen de configurer, de sorte que seul un certain utilisateur / groupe doit être authentifié par cette méthode personnalisée, d'autres peuvent toujours être authentifiés par la méthode normale d'authentification système. Quelqu'un peut-il me donner quelques conseils?

Je ne pense pas que sudo supporte une telle configuration. Le but de l'invite de mot de passe sudo est de s'assurer que la personne émettant la commande sudo est la même personne qui est connectée, et la manière la plus simple de le faire est de demander à l'utilisateur actuellement connecté de s'authentifier à nouveau.

En d'autres termes, le but de l'invite de mot de passe sudo n'est pas d'établir l' autorité , c'est d'établir l' identité . Sur la base de l'identité établie et de la configuration sudo, il est possible de décider si l'utilisateur en question dispose des droits d'accès ou des droits d'accès nécessaires.

Votre souci est que le mot de passe de votre compte puisse être divulgué. La solution consiste à ne pas utiliser le mot de passe de connexion de manière à ce qu'il puisse être divulgué. Avec ssh, le mot de passe est crypté sur le fil, donc ça va. Les gens désactivent l'authentification par mot de passe avec ssh pour empêcher les attaques par devinette, et non pour protéger la confidentialité des mots de passe. Si vous utilisez le même mot de passe de compte pour autre chose, assurez-vous que vous utilisez un canal sécurisé et crypté pour fournir le mot de passe. Si vous vous inquiétez d'un enregistreur de frappe ou autre, arrêtez d'utiliser des machines non fiables pour vous connecter.

Si quelqu'un peut obtenir votre mot de passe ssh, il peut probablement également obtenir l'autre mot de passe sudo, il est donc préférable d'investir du temps pour rendre vos connexions plus sécurisées que de passer du temps à compliquer les choses simplement pour l'illusion d'une plus grande sécurité.

Je n'ai pas immédiatement accès à un système où je peux tester cela et travailler sur les détails, mais j'ai une idée:

• (Supposons que votre compte de connexion normal soit shau.)
• Créer un deuxième compte: shau2. (Je ne sais pas si vous voulez qu'il ait le même UID que shau.)
• Configurez shau2pour avoir les privilèges sudo avec NOPASSWD.
• Configurez un alias ou un script shell à faire su shau2 -c sudo "$@". Cela devrait demander shau2le mot de passe de. Si cela est entré correctement, il fonctionnera sudocomme shau2 (qui ne devrait pas demander de mot de passe).
• Supprimer shaules privilèges sudo de.

Malheureusement, vous devrez répéter cette opération pour chaque utilisateur disposant de privilèges sudo.

Merci @ Shâu Shắc pour la réponse ! Cette solution fonctionne également pour LinuxMint 17.1 Cinnamon 32bit (je n'ai installé le db-utilpaquet que pour fonctionner db_load).

Mais je suis très confus avec le passwd.dbfichier résultant . J'ai fait la même chose que dans votre réponse (mais utilisé David et Jones , ils ont l'air plus accrocheurs):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Mais les informations d'identification saisies sont stockées dans le fichier de hachage sous forme de texte brut:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Vous pouvez également voir david et jones via mcedit :

Oui, il est possible de restreindre les autorisations de /usr/local/etc/passwd.db. Mais de toute façon, le nom d'utilisateur et le mot de passe stockés en texte brut sont mauvais.

Même avec un mot de passe sudo séparé, il existe des failles de sécurité potentielles (par défaut, la configuration de la distribution). Ainsi, un mot de passe séparé n'est pas applicable pour su (il est donc possible de démarrer la session racine en utilisant un sumot de passe de connexion). Le mot de passe séparé n'est pas non plus respecté par Policy Kit (il est possible de démarrer Synaptic à l' aide du synaptic-pkexecmot de passe de connexion. Ensuite, supprimez les packages ...). Ces problèmes peuvent être éliminés par un réglage supplémentaire des fichiers de configuration.

En général, un mot de passe sudo séparé sécurisé ne peut être obtenu qu'avec l'aide d'un module PAM personnalisé (peut-être, un tel module comparera le mot de passe et le hachage SHA-512 lu à partir d'un fichier) ou la fonctionnalité SELinux.

PS: désolé, ça devrait être un commentaire. Mais cela va comme réponse en raison du format texte. Merci de votre compréhension.