ssh - PermitRootLogin

*Bonjour*,

Le 17 nov 2004, Thomas a formulé :

c'est quoi la difference entre
PermitRootLogin no
et AllowUsers sans root dedans ?

(pour root bien sur :-) )

La doc (man sshd_config) est claire sur le sujet :

- si il existe un paramètre AllowUsers, aucun autre utilisateur que ceux
présent dans la liste ne peut se logguer
- si PermitRootLogin est à "no" root n'est pas autoriser à se logguer par
ssh, ça évite à remplir AllowUsers sans root s'il y a beaucoup
d'utilisateurs

PermitRootLogin peut aussi permettre d'autre possibilités comme autoriser le
lancement de commandes, ou désactiver l'accès par mot de passe.

est ce que PermitRootLogin ca empeche de faire su root ou sudo apres ?

Bien sûr, une fois qu'un utilisateur est loggué, il peut ensuite faire «su».
Pour sudo, il faut bien sûr paramétrer sudoers.

Pour ma part, je trouve logique de désactiver l'accès root sur une
passerelle (par exemple), aussi il vaut mieux ensuite passer par su et ne
pas avoir de sudoer ce qui pourrait affaiblir la sécurité.
De même une autre mesure est de supprimer les accès par mot de passe et de
configurer les accès par clé (authorised_key) uniquement pour rentrer sur
cette passerelle.

d'autres differences ?

?

Sébastien Kirche

In article (Dans l'article) <85k6skq5rd.fsf@obelix.seki.fr>,
Sebastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> wrote
(écrivait) :

*Bonjour*,

Le 17 nov 2004, Thomas a formulé :

c'est quoi la difference entre
PermitRootLogin no
et AllowUsers sans root dedans ?

(pour root bien sur :-) )

La doc (man sshd_config) est claire sur le sujet :

- si il existe un paramètre AllowUsers, aucun autre utilisateur que ceux
présent dans la liste ne peut se logguer
- si PermitRootLogin est à "no" root n'est pas autoriser à se logguer par
ssh, ça évite à remplir AllowUsers sans root s'il y a beaucoup
d'utilisateurs

autrement dit,
PermitRootLogin no
c'est l'equivalent absolu de
DenyUsers root
?

PermitRootLogin peut aussi permettre d'autre possibilités comme autoriser le
lancement de commandes, ou désactiver l'accès par mot de passe.

ah oui, effectivement :-)

donc l'utilité c'est de permetre ces choix supplémentaires
dommage, j'aurais aimé avoir ces choix pour chaque utilisateur ...

est ce que PermitRootLogin ca empeche de faire su root ou sudo apres ?

Bien sûr, une fois qu'un utilisateur est loggué, il peut ensuite faire «su».
Pour sudo, il faut bien sûr paramétrer sudoers.

ok, donc, ce parametrage n'a absolument aucune incidence sur su et sudo,
ok :-)

Pour ma part, je trouve logique de désactiver l'accès root sur une
passerelle (par exemple), aussi il vaut mieux ensuite passer par su et ne
pas avoir de sudoer ce qui pourrait affaiblir la sécurité.

moi j'ai laissé la config par defaut (mac os x) : compte root desactivé,
et les "admins" sont sudoers pour tout

De même une autre mesure est de supprimer les accès par mot de passe et de
configurer les accès par clé (authorised_key) uniquement pour rentrer sur
cette passerelle.

fait :-)

d'autres differences ?

?

oui, c'etait en supposant que celle ci en soit une :-)

donc, aucune difference en fait ?
(voir 1ere question, si c'est pas clair :-) )

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

Dans le message
<news:fantome.forums.tDeContes-168E29.08563417112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

Sebastien Kirche écrivait :

c'est quoi la difference entre
PermitRootLogin no
et AllowUsers sans root dedans ?

La doc (man sshd_config) est claire sur le sujet :
- si il existe un paramètre AllowUsers, aucun autre utilisateur que
ceux présent dans la liste ne peut se logguer - si PermitRootLogin est
à "no" root n'est pas autoriser à se logguer par ssh, ça évite à
remplir AllowUsers sans root s'il y a beaucoup d'utilisateurs

autrement dit,
PermitRootLogin no
c'est l'equivalent absolu de
DenyUsers root
?

Non.

La directive 'PermitRootLogin no' interdit à tous les utilisateurs dont leur
uid serait 0, de se logger, donc pas que nécéssairement l'utilisateur root,
mais aussi l'utilisateur toor (sur les *BSD) ou plus généralement les
comptes super utilisateur.

Quant à la directive 'DenyUsers root', elle interdit uniquement à
l'utilisateur nommé root de se logger, mais n'empêcherait pas, par exemple,
à l'utilisateur w00t dont l'uid serait 0, de se logger.

--
TiChou

In article (Dans l'article)
<pwet.20041117142730@florizarre.tichou.org>,
"TiChou" <gro.uohcit@uohcit> wrote (écrivait) :

Dans le message
<news:fantome.forums.tDeContes-168E29.08563417112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

Sebastien Kirche écrivait :

c'est quoi la difference entre
PermitRootLogin no
et AllowUsers sans root dedans ?

La doc (man sshd_config) est claire sur le sujet :
- si il existe un paramètre AllowUsers, aucun autre utilisateur que
ceux présent dans la liste ne peut se logguer - si PermitRootLogin est
à "no" root n'est pas autoriser à se logguer par ssh, ça évite à
remplir AllowUsers sans root s'il y a beaucoup d'utilisateurs

autrement dit,
PermitRootLogin no
c'est l'equivalent absolu de
DenyUsers root
?

Non.

La directive 'PermitRootLogin no' interdit à tous les utilisateurs dont leur
uid serait 0, de se logger, donc pas que nécéssairement l'utilisateur root,
mais aussi l'utilisateur toor (sur les *BSD) ou plus généralement les
comptes super utilisateur.

Quant à la directive 'DenyUsers root', elle interdit uniquement à
l'utilisateur nommé root de se logger, mais n'empêcherait pas, par exemple,
à l'utilisateur w00t dont l'uid serait 0, de se logger.

ah bon, je savais pas :-)


en l'occurence, puisque toor existe, DenyUsers root le permet ?

et plus generalement, c'est possible autant qu'on veut, de creer des
"alias" cad des utilisateurs "differents" qui ont le meme nom, qui
seraient en fait le meme utilisateur pour la machine ?
et dans ce cas, donc, DenyUsers est dangereux parce qu'il faut penser à
les lister tous pour que ca marche ?

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

Dans le message
<news:fantome.forums.tDeContes-E5D293.15444417112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

en l'occurence, puisque toor existe, DenyUsers root le permet ?

Je n'ai pas compris votre question.

et plus generalement, c'est possible autant qu'on veut, de creer des
"alias" cad des utilisateurs "differents" qui ont le meme nom, qui
seraient en fait le meme utilisateur pour la machine ?

Je n'ai pas compris non plus. Des utilisateurs différents mais qui ont le
même nom et qui seraient le même utilisateur ?! Vous vouliez peut être
parler d'utilisateurs différents mais avec le même uid ?
Avez-vous un exemple concret de ce que vous voulez dire ?

et dans ce cas, donc, DenyUsers est dangereux parce qu'il faut penser à
les lister tous pour que ca marche ?

Je recommande généralement de n'utiliser que la directive AllowFroups. Par
exemple :

AllowGroups sshd

Ainsi, seuls les utilisateurs membres du groupe sshd sont autorisés à se
logger.

--
TiChou

In article (Dans l'article)
<pwet.20041117155445@florizarre.tichou.org>,
"TiChou" <gro.uohcit@uohcit> wrote (écrivait) :

Dans le message
<news:fantome.forums.tDeContes-E5D293.15444417112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

en l'occurence, puisque toor existe, DenyUsers root le permet ?

Je n'ai pas compris votre question.

effectivement c'etait pas clair :-)

puisque toor existe, "DenyUsers root" permet qu'on se logue en root à
condition d'indiquer toor au lieu de root ?

et plus generalement, c'est possible autant qu'on veut, de creer des
"alias" cad des utilisateurs "differents" qui ont le meme nom, qui
seraient en fait le meme utilisateur pour la machine ?

Je n'ai pas compris non plus. Des utilisateurs différents mais qui ont le
même nom et qui seraient le même utilisateur ?! Vous vouliez peut être
parler d'utilisateurs différents mais avec le même uid ?
Avez-vous un exemple concret de ce que vous voulez dire ?

je suis pas un *grand specialiste* unix, ca aide pas :-)

si par ex on fait toto avec un uid, et titi avec le meme uid,
ben pour le systeme, toto et titi c'est le meme utilisateur, puisque
c'est l'uid qui compte, non ?

et dans ce cas, "DenyUsers toto" ca sert à rien, puisque on peut tjr se
logger en titi et avoir les meme droits ?
(sauf si la personne exterieure n'a pas connaissance du nom titi)

et dans ce cas, donc, DenyUsers est dangereux parce qu'il faut penser à
les lister tous pour que ca marche ?

Je recommande généralement de n'utiliser que la directive AllowFroups. Par
exemple :

AllowGroups sshd

Ainsi, seuls les utilisateurs membres du groupe sshd sont autorisés à se
logger.

j'ai posé la question au départ pour etre certain de comment ca marche,
mais j'ai mis un allow user avec ma petite liste :-)

j'avais surtout peur que ca m'empeche de faire sudo :-)

ce qui aurait été une bonne sécurité, en passant :-) possibilité de
faire sudo seulement en local :-)

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"

Dans le message
<news:fantome.forums.tDeContes-3127A0.20110617112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

puisque toor existe, "DenyUsers root" permet qu'on se logue en root à
condition d'indiquer toor au lieu de root ?

'DenyUsers root' interdit à l'utilisateur qui se nomme root, de se logger
mais n'empêche pas à l'utilisateur qui se nomme toor de se logger même si
toor a le même uid que root. La distinction se fait bien au niveau du nom de
login et non pas au niveau de l'uid, contrairement à la directive
PermitRootLogin qui se fie qu'à l'uid.

si par ex on fait toto avec un uid, et titi avec le meme uid,
ben pour le systeme, toto et titi c'est le meme utilisateur, puisque
c'est l'uid qui compte, non ?

Oui et non. Pour le système d'authentification, c'est deux utilisateurs
distincts et donc les règles de filtrage qui s'appliqueraient à
l'utilisateur toto lors de l'authentification ne s'appliqueraient pas
obligatoirement à l'utilisateur titi. Après la phase d'authentification, ces
deux utilisateurs ayant le même uid, sont vu par le système avec le même uid
mais peuvent avoir des droits différents (gid par exemple) mais aussi un
environnement différent (shell, boite mail, répertoire home, ...). Il n'y a
donc pas que l'uid qui compte même s'il définit en général et en grand
partie les droits que possèdent ces utilisateurs.

et dans ce cas, "DenyUsers toto" ca sert à rien, puisque on peut tjr se
logger en titi et avoir les meme droits ?

Si, ça sert à interdire toto mais à autoriser titi. Faut bien voir que c'est
deux comptes, chacun avec son mot de passe, pouvant être membres de groupes
différents et avoir un environnement différent. Ils n'ont en commun que leur
uid et les directives Deny et Allow ne se fient qu'au nom de login, pas à
l'uid.

(sauf si la personne exterieure n'a pas connaissance du nom titi)

Elle peut avoir connaissance de l'utilisateur titi, mais ça ne lui donne pas
pour autant la possibilité de se logger car il faudrait pour cela qu'elle
est connaissance aussi du mot de passe de titi.

--
TiChou

In article (Dans l'article)
<gniii.20041117211254@florizarre.tichou.org>,
"TiChou" <gro.uohcit@uohcit> wrote (écrivait) :

Dans le message
<news:fantome.forums.tDeContes-3127A0.20110617112004@news11-e.proxad.net>,
*Thomas* tapota sur f.c.o.unix :

puisque toor existe, "DenyUsers root" permet qu'on se logue en root à
condition d'indiquer toor au lieu de root ?

'DenyUsers root' interdit à l'utilisateur qui se nomme root, de se logger
mais n'empêche pas à l'utilisateur qui se nomme toor de se logger même si
toor a le même uid que root. La distinction se fait bien au niveau du nom de
login et non pas au niveau de l'uid, contrairement à la directive
PermitRootLogin qui se fie qu'à l'uid.

ok :-)

si par ex on fait toto avec un uid, et titi avec le meme uid,
ben pour le systeme, toto et titi c'est le meme utilisateur, puisque
c'est l'uid qui compte, non ?

Oui et non. Pour le système d'authentification, c'est deux utilisateurs
distincts et donc les règles de filtrage qui s'appliqueraient à
l'utilisateur toto lors de l'authentification ne s'appliqueraient pas
obligatoirement à l'utilisateur titi. Après la phase d'authentification, ces
deux utilisateurs ayant le même uid, sont vu par le système avec le même uid
mais peuvent avoir des droits différents (gid par exemple) mais aussi un
environnement différent (shell, boite mail, répertoire home, ...). Il n'y a
donc pas que l'uid qui compte même s'il définit en général et en grand
partie les droits que possèdent ces utilisateurs.

ok, je savais pas tout ca :-)



[hs]

mais alors, root et toor sont deux utilisateurs différents, qui peuvent
avoir 2 mdp differents, tout ca ??
je croyais que c'etait le meme utilisateur, moi ...

--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"