[ Root passwd ] sans mot-de-passe à l'ouverture d'un logiciel

Support Debian
#1

Bonjour les amis, :slight_smile:

Connaissez-vous l’astuce pour ne pas avoir à taper le mot-de passe de ( root ) à chaque ouverture d’un logiciel ??

(( Je sais qu’il n’est pas recommendé de faire cà … Mais je veux le faire … )) …

Ce n’est pas d’être sudoer que je désire … Je suis sudoer …

–> C’est de canceller la demande du passwd que je désire --> à l’ouverture d’un logiciel comme ex: ( gparted ou autre logiciel ) …

Merci à l’avance de votre aide …

#2

Si tu es sûr que personne, jamais, n’aura accès à ta machine, c’est faisable mais c’est plus que déconseillé.
Si quelqu’un, pas forcément mal intentionné, mais seulement curieux, peut ouvrir sans MDP un logiciel comme Gparted, en un seul clic, il casse entièrement et définitivement ta machine.

#3

Savez-vous comment désactiver l’agent d’authentification dans les paramètres de démarrage ?

#4

L’ensemble des mécanismes d’authentification, d’autorisation est devenu complexe sous Linux, pour pouvoir intégrer facilement un système Debian dans un ensemble plus large comme un domaine NIS, LDAP, Kerberos, Active Directory, …
La technologie utilisée s’appelle PAM

 PAM, pam - Pluggable Authentication Modules for Linux
pam(7) fourni par le paquet libpam-runtime

Oui :smile:
Avant de vous expliquer comment je procéderais, je me permet de vous expliquer la démarche qui m’a permis de trouver cette astuce. Pour administrer facilement un certain nombre de systèmes Linux, je me connecte depuis mon poste client sur un des systèmes en ssh avec la configuration suivante

  • agent forwarding activé

  • X11 forwarding activé (pas toujours utilisé)

  • Compte cible est dans les sudoers

Je commence par vérifier que l’authentification par agent SSH fonctionne et corrige le tir si besoin est. Par exemple, j’ai du faire redémarrer mon poste client Windows 7 et donc relancer un pageant pour créer une nouvelle instance. Une fois connecté, je peux retrouver une session tmux avec la commande

tmux attach -t 0

Cependant le lien avec l’agent qui était utilisé dans les shells des fenêtres tmux n’est plus valide. Je dois donc corriger

fp2x@halc9:/bigs9/misc$ ssh-add -l
Could not open a connection to your authentication agent.
fp2x@halc9:/bigs9/misc$ cd
fp2x@halc9:~$ env | fgrep SSH
SSH_CLIENT=10.67.6.43 53206 22
SSH_TTY=/dev/pts/0
SSH_AUTH_SOCK=/tmp/ssh-u7xGqBqS4a/agent.17703
SSH_CONNECTION=10.67.6.43 53206 10.67.24.34 22
fp2x@halc9:~$ l /tmp/ssh-UzHE8atjR3/agent.3881
0 srwxr-xr-x 1 fp2x fp2x 0 juil. 15 11:52 /tmp/ssh-UzHE8atjR3/agent.3881
fp2x@halc9:~$ SSH_AUTH_SOCK=/tmp/ssh-UzHE8atjR3/agent.3881
fp2x@halc9:~$ ssh-add -l
1024 b6:0f:81:4e:f9:9a:a8:97:ef:52:6f:f9:d6:90:67:cb imported-openssh-key  id_dsa (DSA)
1024 1c:22:50:8a:0c:04:98:89:40:90:b9:60:2f:28:83:ab openssh-key du 8 janvier 2003 (RSA)
fp2x@halc9:~$

Autrement dit, c’est la variable d’environnement SSH_AUTH_SOCK qui doit être bien renseignée.

Sur chacun des systèmes administrés, j’ai mis mes clés publiques dans le fichier /root/.ssh/authorized_keys .

fp2x@halc9:~$ sudo ls -lApst /root/.ssh
total 8
4 -rw-r--r-- 1 root root 3732 févr.  8  2012 known_hosts
4 -rw-r--r-- 1 root root 1941 sept. 15  2003 authorized_keys
fp2x@halc9:~$

Pour exécuter une commande sur un autre système en me faisant passer pour root je lance par exemple

fp2x@halc9:~$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh halc10 ls -lApst /root/.ssh
total 20
16 -rw-r--r-- 1 root root 12596 août  16  2013 known_hosts
 4 -rw-r--r-- 1 root root  1941 sept. 15  2003 authorized_keys
fp2x@halc9:~$
fp2x@halc9:~$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh halc10 id
uid=0(root) gid=0(root) groupes=0(root)
fp2x@halc9:~$

Décomposons

  • sudo je passe en super utilisateur.

  • SSH_AUTH_SOCK=$SSH_AUTH_SOCK environnement pour ssh.

  • ssh halc10 id La commande (ici id) envoyée sur le système cible (halc10).

Remarquez qu’il n’y a pas de demande de mot de passe pour la partie ssh, seulement pour la partie sudo si vous n’avez pas fait de sudo depuis quelque temps.

Fort de cette remarque, tentons de se faire passer pour root sur le système local

fp2x@halc9:/tmp$ ssh root@localhost id
ssh: connect to host localhost port 22: Connection refused
fp2x@halc9:/tmp$ cd /etc
fp2x@halc9:/etc$ cd ssh
fp2x@halc9:/etc/ssh$ fgrep -i root sshd_config
PermitRootLogin yes
fp2x@halc9:/etc/ssh$

Par défaut, Debian ne veut pas :grin:

Le refus de connexion est du à

fp2x@halc9:/etc/ssh$ fgrep -i liste sshd_config
# What ports, IPs and protocols we listen for
#ListenAddress ::
#ListenAddress 0.0.0.0
ListenAddress 10.67.24.34
ListenAddress 192.168.1.109
fp2x@halc9:/etc/ssh$ sudo pwd

En ajoutant une ligne

ListenAddress localhost

suivi de

fp2x@halc9:/etc/ssh$ sudo systemctl restart  ssh.service

Je peux maintenant lancer des commandes d’administration sans taper de mot de passe :slight_smile:

fp2x@halc9:/etc/ssh$ ssh root@localhost id
uid=0(root) gid=0(root) groupes=0(root)
fp2x@halc9:/etc/ssh$

Je peux maintenant créer un alias pour me simplifier la tâche (merci d’avoirr posé la question)

alias susu='ssh root@localhost'
fp2x@halc9:/etc/ssh$ susu pvs
  PV         VG      Fmt  Attr PSize   PFree
  /dev/sdc   data_vg lvm2 a--  136,73g     0
  /dev/sdd10 data_vg lvm2 a--  120,88g 57,61g
fp2x@halc9:/etc/ssh$ sudo pvs
[sudo] password for fp2x:
  PV         VG      Fmt  Attr PSize   PFree
  /dev/sdc   data_vg lvm2 a--  136,73g     0
  /dev/sdd10 data_vg lvm2 a--  120,88g 57,61g
fp2x@halc9:/etc/ssh$

J’espère avoir répondu à la question

Note
(*) Je n’arrive plus à faire afficher une liste à puces :frowning:

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#5

Wow !! Super …

Merci mon ami …:slight_smile: