Connexion à root via su impossible

Support Debian
#1

Salut,

Ce soir je viens de constater que j’ai un petit soucis de connexion à un serveur distant, je suis sûr de ne pas m’être fait piraté car je reçoit un email à chaque connexion d’un login. De plus, le serveur est pour l’instant qu’un serveur de test, mais je n’ai pas touché à la configuration depuis un moment, a part pour faire un update vers la 7.4.

Du coup voici ce que j’ai fait :

J’entre mon mot de passe de mon utilisateur (ce soir j’allais justement mettre en place une clé pour me connecter automatiquement)

Ensuite

J’entre le mot de passe de root, et là, il me dit “Autorisation refusée”

Si je fais

Là, aucun problème, je peux me connecter …

Avez-vous une idée d’où ca peut venir ? je tente de chercher sur google, je suis tombé sur un sujet ici, mais rien pour l’instant qui m’a aidé à comprendre ce qu’il se passe, je suis un peu paumé :confused:

Je suis d’autant plus inquiet, que j’allais, après avoir installé la clef ssh, désactiver la connexion via root, j’aurais alors, sûrement, perdu totalement le contrôle de la machine :confused: Est-ce que ca vous est déjà arrivé ? et si oui, y a t’il une possibilité de régler le problème ou bien c’est perdu de chez perdu ? (car ce problème le laisse vraiment perplexe et me demande si c’est bien de désactiver la connexion via root, du coup…)

Merci par avance pour votre aide !!

P.S : je me suis aussi rendu compte, après avoir reboot, que ma bannière (qui apparait après connexion) a disparu remplacé par le truc standard que met en place OVH… c’est un serveur hébergé chez OVH.

#2

En principe, on se connecte en SSH en tant qu’user.
Surtout si, comme c’est souvent recommandé, on a interdit la connexion en tant que Root dans sshd_config.

EDIT :
Excuse, j’avais compris le contraire, que tu ne pouvais pas te connecter en tant que ‘Root’.

Je ne vois donc qu’une erreur de MDP si tu n’as pas de jeu de clefs.
Ptet le clavier à tester ?
Parfois, on tape un MDP alors que le clavier est bloqué sur les MAJ.

En dernier ressort, tu te logues en tant que ‘root’ et tu refais ton MDP ‘user’.

passwd monlogin

#3

Le problème ne vient pas de mon clavier, ni du mot de passe , ni de moi :mrgreen:
J’ai testé une dizaine de fois pour dire, et même rebooté la machine pour voir, tester aussi le copier/coller… resultat :
Je ne peux pas me connecter en root depuis un autre utilisateur via su, mais je peux me connecter directement a root :open_mouth:
C’est donc un problème vraiment très inquietant!!!

J’ai pensé au changement du mot de passe (root et non user) mais je ne le fais pas car je pars du principe ou seul root peut le faire, et vu que c’est lui qui bug… Je dois arriver a regler le probleme sans l’utiliser…

Donc voila si quelqu’un a une solution, merci a lui !!!

#4

Bonjour,

J’ai peut être une piste à étudier … L’usage de su peut être limité à certain groupe …

#5

Voici mon fichier [mono]/etc/pam.d/su[/mono]

[code]#

The PAM configuration file for the Shadow `su’ service

This allows root to su without passwords (normal operation)

auth sufficient pam_rootok.so

Uncomment this to force users to be a member of group root

before they can use `su’. You can also add “group=foo”

to the end of this line if you want to use a group other

than the default “root” (but this may have side effect of

denying “root” user, unless she’s a member of “foo” or explicitly

permitted earlier by e.g. “sufficient pam_rootok.so”).

(Replaces the `SU_WHEEL_ONLY’ option from login.defs)

auth required pam_wheel.so

Uncomment this if you want wheel members to be able to

su without a password.

auth sufficient pam_wheel.so trust

Uncomment this if you want members of a specific group to not

be allowed to use su at all.

auth required pam_wheel.so deny group=nosu

Uncomment and edit /etc/security/time.conf if you need to set

time restrainst on su usage.

(Replaces the `PORTTIME_CHECKS_ENAB’ option from login.defs

as well as /etc/porttime)

account requisite pam_time.so

This module parses environment configuration file(s)

and also allows you to use an extended config

file /etc/security/pam_env.conf.

parsing /etc/environment needs “readenv=1”

session required pam_env.so readenv=1

locale variables are also kept into /etc/default/locale in etch

reading this file in addition to /etc/environment does not hurt

session required pam_env.so readenv=1 envfile=/etc/default/locale

Defines the MAIL environment variable

However, userdel also needs MAIL_DIR and MAIL_FILE variables

in /etc/login.defs to make sure that removing a user

also removes the user’s mail spool file.

See comments in /etc/login.defs

“nopen” stands to avoid reporting new mail when su’ing to another user

session optional pam_mail.so nopen

Sets up user limits, please uncomment and read /etc/security/limits.conf

to enable this functionality.

(Replaces the use of /etc/limits in old login)

session required pam_limits.so

The standard Unix authentication modules, used with

NIS (man nsswitch) as well as normal /etc/passwd and

/etc/shadow entries.

@include common-auth
@include common-account
@include common-session[/code]

Je tiens aussi à préciser, qu’avant je pouvais me connecter à root via mon login!

#6

Sur mon fichier “d’ordinateur de bureau”.

La ligne de ton fichier:

est chez moi :

#7

J’y avais pensé, j’avais décommenté cette ligne, wheel n’est pas toujours utilisé par défaut, et je voulais utiliser wheel, il me semblais que c’était un moyen d’autoriser uniquement certains user à devenir root avec su :think:

Est-ce que du coup ca pourrait être la dernière version (7.4) qui a causé ce problème ? je n’ai pas trouvé d’infos sur la publication !

Ce qui est étrange c’est que je n’ai pas eu de problème jusqu’à maintenant, et ca depuis plusieurs semaines :confused:

#8

ligne commentée chez moi aussi

#9

Je me souviens pas trop de mes cours de PAM, mais le module pam_wheel, oblige les users à faire partir du groupe “wheel” (groupe par défaut) pour utiliser la commande “su” ?

# auth       required   pam_wheel.so

Commenté chez moi aussi.

Edit: t’as fait une maj recemment? Oui ca pourrait être dut a ca si c’est le cas (ce que tu laisses sous entendre)

#10

Il serait ptet intéressant de voir le [mono]/etc/ssh/sshd_config[/mono] de ton serveur.

‘ricardo’ n’est pas dans le groupe wheel chez moi et je n’ai pas de problème de connexion à mon serveur extérieur.
Par contre, mais ça ne compte certainement pas, j’utilise toujours ‘[mono]su -[/mono]’ (avec le tiret)

#11

Salut,

Non !

J’ai effectué cette mise à jour (ovh) ce 12 Février.

[13:42:42][root@facteur] / # aptitude upgrade Les paquets suivants seront mis à jour : apache2 apache2-mpm-prefork apache2-threaded-dev apache2-utils apache2.2-bin apache2.2-common apt apt-listbugs apt-utils base-files curl denyhosts gnupg gpgv iftop kpartx libapache2-mod-php5 libapt-inst1.5 libapt-pkg4.12 libc-bin libc-dev-bin libc6 libc6-dev libc6-i686 libcurl3 libcurl3-gnutls libcurl4-openssl-dev libexpat1 libexpat1-dev libicu48 libmysqlclient-dev libmysqlclient18 libmysqld-dev libpixman-1-0 libpq-dev libpq5 libruby1.8 libruby1.9.1 libssl-dev libssl1.0.0 libyaml-0-2 linux-image-3.2.0-4-686-pae linux-libc-dev localepurge locales multiarch-support mysql-client-5.5 mysql-common mysql-server mysql-server-5.5 mysql-server-core-5.5 openssl php-pear php5 php5-cli php5-common php5-curl php5-dev php5-gd php5-imap php5-intl php5-mcrypt php5-mysql ruby1.8 ruby1.9.1 tzdata wget whois Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés : gnupg-curl libssl-doc manpages-dev 68 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 0 o/89,4 Mo d'archives. Après dépaquetage, 3 635 ko seront libérés. Voulez-vous continuer ? [Y/n/?] y Récupération des rapports de bogue… Fait Analyse des informations Trouvé/Corrigé… Fait Lecture des fichiers de modifications (« changelog »)... Terminé ...

Rien à voir avec PAM, de près où de loin !

#12

Commentaires du passage concernant pam_wheel en /etc/pam.d/su

[code]

Uncomment this to force users to be a member of group root

before they can use `su’. You can also add “group=foo”

to the end of this line if you want to use a group other

than the default “root” (but this may have side effect of

denying “root” user, unless she’s a member of “foo” or explicitly

permitted earlier by e.g. “sufficient pam_rootok.so”).

(Replaces the `SU_WHEEL_ONLY’ option from login.defs)

auth required pam_wheel.so[/code]

« force users to be a member of group root before they can use `su’ » Décommenté, l’usage de su sera réservé aux utilisateurs du groupe visé par pam_wheel.
Le groupe wheel de pam n’est autre que le groupe root à moins de définir explicitement group=xxxxx
Recommenter ou ajouter l’utilisateur au groupe root afin qu’il lui soit permis d’appeler $ su.

#13

[quote=“Kristy”]Je me souviens pas trop de mes cours de PAM, mais le module pam_wheel, oblige les users à faire partir du groupe “wheel” (groupe par défaut) pour utiliser la commande “su” ?

# auth       required   pam_wheel.so

Commenté chez moi aussi.

Edit: t’as fait une maj recemment? Oui ca pourrait être dut a ca si c’est le cas (ce que tu laisses sous entendre)[/quote]
D’après ce que j’ai compris oui c’est ca, c’est pour ca que je l’avais décommenté, et ajouter au groupe wheel :think:

J’ai fait la maj 7.3 vers 7.4 le jour suivant de la sortie de la version. Je n’avais pas ce problème avant la MAJ (sûr à 100%) mais ce n’est pas dit que c’est la MAJ qui a fait foiré ca.

Ricardo : j’ai aussi utilisé su - rien n’y a fait

Voici mon fichier config sinon

[code]# Package generated configuration file

See the sshd_config(5) manpage for details

What ports, IPs and protocols we listen for

Port 23000

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM yes
[/code]

Au passage en décommentant la ligne, ca a réglé le problème, donc merci à vous ! Mais je ne comprends toujours pas le problème. Je continue de chercher!

etxeberrizahar c’est en effet ca, mais c’était volontaire de ma part de le faire. Je tiens aussi à préciser que j’ai la même configuration sur plusieurs machines, et il n’y a que sur celle là que ca bug :confused:
Ce qui est bizarre aussi, c’est que le problème ne se déclare que maintenant, et dans la logique, aurait du se déclarer depuis déjà un moment

#14

[quote=“Balian”]D’après ce que j’ai compris oui c’est ca, c’est pour ca que je l’avais décommenté, et ajouter au groupe wheel :think:

Mais je ne comprends toujours pas le problème. Je continue de chercher![/quote]

Comme déjà dit …

[quote=“etxeberrizahar”]Le groupe wheel de pam n’est autre que le groupe root à moins de définir explicitement group=xxxxx
Recommenter ou ajouter l’utilisateur au groupe root afin qu’il lui soit permis d’appeler $ su.[/quote]

$ cat /etc/pam.d/su

auth       required   pam_wheel.so
...
auth        requisite   pam_wheel.so group=wheel debug[/code]
[code]$ cat /etc/group
...
wheel:x:1001:[b]user[/b]
...
#15

Et pour en finir. :016

[quote=“Balian”]mais je n’ai pas touché à la configuration depuis un moment, a part …
[/quote]

L’éternel relation Chaise/Clavier … :083

4.11 Fournir des accès sécurisés aux utilisateurs

#16

À propos de wheel, recyclons un vieux message :

administrateur-vs-utilisateur-lambda-t28561.html#p284574

[quote=“neronek nioenez”]Sur le thème de la symbolique de la roue.
fr.wikipedia.org/wiki/Chakra#Un_ … de_pouvoir

Dans la lointaine antiquité la roue à rayons c’est à dire l’usage de chars légers offrait une supériorité militaire sur les attardés aux chars lourds à roues pleines ou les primitifs piétons.
fr.wikipedia.org/wiki/Char_%28An … o-Iraniens

[quote]Les chars sont un élément important de la mythologie des Indo-Iraniens et de la mythologie hindoue, tout comme dans la mythologie perse : la plupart des dieux du panthéon perse sont représentés sur un char de guerre. Le mot sanskrit pour un char, ratha, est commun à tous les Proto-indo-européens pour désigner la roue, et a donné en latin la rota.
[/quote]
La roue représentait la puissance.

La roue de paon a-t-elle des freins ?

Refermons la parenthèse, revenons à nos moutons.

Wheel n’est pas une émanation de root comme toor (root dupliqué), ce n’est qu’un groupe dans lequel on inclut des comptes “de confiance” comme tu inclus des membres au groupe audio pour qu’ils puissent écouter le cor le soir au fond des bois.

Subjectif et arbitraire , qu’est-ce qu’un compte “de confiance” ?
Imagine que les comptes de Jean-Kevin et de Raymonde aient droit au privilège suprême du groupe % wheel "famille du patron"
et le restant au groupe %users “sherpas corvéables”.
L’user sherpa1 du groupe %users sera empeché d’éxécuter
$ su sherpa2
pour prendre l’identité de sherpa2.

wheel se rencontre surtout en *BSD.
Moins courant en debian (même kfreebsd) , il y a une raison plus politique que technique .

en anglais
gnu.org/software/coreutils/m … ation.html
23.6.1 Why GNU su does not support the ‘wheel’ group
(This section is by Richard Stallman.)

“Sa sainteté” assure que wheel n’est qu’un groupe autoritariste privilégié , le club privé de ceux qui s’approprient /bin/su excluant les pauvres manants de la basse plèbe .

ricardo, je pense que tu pourrais t’inspirer de
debian.org/doc/manuals/refer … ne.fr.html

9.2.2 Pourquoi GNU su ne supporte pas le groupe wheel

Le titre est trompeur, il soutient le contraire.
recettes à base de pam.[/quote]

#17

ligne commentée :017
connexion exclusivement sous clefs ?
[mono]#PasswordAuthentication yes[/mono]

#18

Alors messieurs, tout d’abord, je suis sincèrement désolé du retard de ma réponse !
Saint valentin oblige (madame oblige de ne rien toucher à ce qui est électronique :118 ) et ensuite déplacement pour le travail pendant une semaine, je n’ai pas pu venir :confused:

Alors oui j’ai activé [mono]auth required pam_wheel.so[/mono] intentionnellement, mais le soir j’ai vérifié que mon utilisateur était bien dans le groupe, c’était le cas. Du coup j’ai posté ici car je n’avais pas compris le soucis. Sauf qu’après vos réponses, je me suis dit, ce n’est pas normal, tout est ok… Je refais une vérification… et là l’utilisateur n’est pas dans le groupe :013 je regarde mes emails, et je me rend compte que la première fois que j’avais vérifié j’étais connecté sur le mauvais serveur :033 :033 :033 :033 :033

Alors du coup, oui, le probème vient du fait que j’avais oublié d’ajouter l’utilisateur au groupe :open_mouth: :open_mouth: comme on dit, le problème vient entre le siège et le clavier. D’ailleuurs c’était posté sur ce sujet je crois ? :mrgreen:

Bon maintenant, comme j’en parlais, et je me le demande toujours, le problème est “sûrement” (je l’ai vu qu’après) la dernière MAJ 7.4, quelqu’un a des infos là dessus ? car je n’ai rien trouvé ? avant ca fonctionnait sans soucis, et du coup je me demande pourquoi :unamused: parceque, ce n’est pas normal …

#19

Salut,

L’absence du fichier [mono]/etc/pam.d/su.dpkg-old[/mono] confirme le fait que tu ne peux en aucun cas mettre en cause l’upgrade vers Wheezy-7.4 ! :mrgreen:

:016 … :whistle:

#20

[quote=“BelZéButh”]Salut,

L’absence du fichier [mono]/etc/pam.d/su.dpkg-old[/mono] confirme le fait que tu ne peux en aucun cas mettre en cause l’upgrade vers Wheezy-7.4 ! :mrgreen: [/quote]

Ca n’explique pas pourquoi ca a fonctionné sans probème pendant des mois !!