Extinction SIMPLISSIME à distance d'un poste linux...depuis une machine windows

TiChou

12/08/2003 à 17:21

Dans l'article news:3f38faf8$0$6214$,
j'écrivais :

Suite à une annulation de post et un copié/collé trop hatif, mes slashs sont
mals passés dans mon précédent post.
Je redonne ici la partie concernant la configuration de la machine Linux
avec les bons slashs. :)

Sur la machine Linux :

On crée le compte 'eteindre'

# useradd -u 0 -o -g 0 -d /root/.halt -m -k /dev/null -s /sbin/halt eteindre
# mkdir /root/.halt/.ssh
# chmod -R 700 /root/.halt

On crée le fichier /root/.halt/.ssh/authorized_keys2 en y insérant la clé
publique générée précédement.

# vi /root/.halt/.ssh/authorized_keys2
# chmod 600 /root/.halt/.ssh/authorized_keys2

On vérifie que dans la configuration de sshd /etc/ssh/sshd_config on a :
PermitRootLogin without-password

--
TiChou

J. Mayer

13/08/2003 à 01:13

On Tue, 12 Aug 2003 17:11:36 +0200, TiChou wrote:

Dans l'article news:,
J. Mayer écrivait :

Une solution simple et relativement secure est de créer un compte
'eteindre' d'uid 0 sur la machine Linux avec comme shell la commande
^^^^^

/sbin/halt et d'utiliser ssh avec l'authentification par clé (RSA

ça suppose que /sbin/halt soit suid root...

# useradd -u 0 -o -g 0 -d root.halt -m -k /dev/null -s /sbin/halt
^^^^^^^

Et pourquoi donc ? :)

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un compte d'uid
0, c'est là l'avantage de cette solution en plus de l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!
Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...
Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

TiChou

13/08/2003 à 02:10

Dans l'article news:,
J. Mayer écrivait :

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un
compte d'uid 0, c'est là l'avantage de cette solution en plus de
l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!

Oui, vous n'avez pas fait gaffe et je crois même, si je puis me permettre,
que vous n'avez rien compris.

Quel utilisateur ? Il n'y a aucun utilisateur, aucun shell, aucune
possibilité de lancer quoique ce soit.
Il n'y a qu'une seule commande et une seule, sans la possibilité d'y insérer
le moindre paramètre et qui de toute manière, quelque soit la méthode, ne
peut être lancé qu'avec l'uid 0.

Par contre suid /sbin/halt ça c'est le *PIRE*.
Et prétendre qu'il est préférable de suid un binaire que plutôt utiliser
sudo comme vous le disiez dans l'autre partie du thread c'est remettre en
cause l'origine de nombreux buffer overflow et donc remettre en cause
certain fondement de la sécurité sur Linux et autres Unix.

Petit rappel, il est demandé dans le post initial de pouvoir lancer la
commande /sbin/halt de la manière le plus simple sans que l'utilisateur
n'est à faire la moindre saisie (commande et/ou mot de passe) tout en
gardant un minimum de sécurité.

Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...

C'est la faiblesse de votre argumentation et la prétention avec laquelle
vous vous exprimez qui est horrible... Elle n'aide vraiment pas au thread...

M'enfin si pour vous aujourd'hui un jeu de clé RSA est à considérer comme
insecure et que suid un binaire est secure, je comprends alors la pauvreté
de votre intervention.

Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

Mais là quoi ? J'attends impatiemment votre argumentation.
Démontrez en quoi cette méthode est si insécure que vous le sous-entendez.
Et surtout démontrez en quoi votre méthode est plus secure...

--
TiChou

Dans l'article news:pan.2003.08.12.23.13.34.196731@magic.fr,
J. Mayer <l_indien_no_more_spams@magic.fr> écrivait :

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un
compte d'uid 0, c'est là l'avantage de cette solution en plus de
l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!

Oui, vous n'avez pas fait gaffe et je crois même, si je puis me permettre,
que vous n'avez rien compris.

Quel utilisateur ? Il n'y a aucun utilisateur, aucun shell, aucune
possibilité de lancer quoique ce soit.
Il n'y a qu'une seule commande et une seule, sans la possibilité d'y insérer
le moindre paramètre et qui de toute manière, quelque soit la méthode, ne
peut être lancé qu'avec l'uid 0.

Par contre suid /sbin/halt ça c'est le *PIRE*.
Et prétendre qu'il est préférable de suid un binaire que plutôt utiliser
sudo comme vous le disiez dans l'autre partie du thread c'est remettre en
cause l'origine de nombreux buffer overflow et donc remettre en cause
certain fondement de la sécurité sur Linux et autres Unix.

Petit rappel, il est demandé dans le post initial de pouvoir lancer la
commande /sbin/halt de la manière le plus simple sans que l'utilisateur
n'est à faire la moindre saisie (commande et/ou mot de passe) tout en
gardant un minimum de sécurité.

Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...

C'est la faiblesse de votre argumentation et la prétention avec laquelle
vous vous exprimez qui est horrible... Elle n'aide vraiment pas au thread...

M'enfin si pour vous aujourd'hui un jeu de clé RSA est à considérer comme
insecure et que suid un binaire est secure, je comprends alors la pauvreté
de votre intervention.

Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

Mais là quoi ? J'attends impatiemment votre argumentation.
Démontrez en quoi cette méthode est si insécure que vous le sous-entendez.
Et surtout démontrez en quoi votre méthode est plus secure...

--
TiChou

Vous avez filtré cet utilisateur ! Consultez son message

J. Mayer

13/08/2003 à 07:14

On Wed, 13 Aug 2003 02:10:08 +0200, TiChou wrote:

Dans l'article news:,
J. Mayer écrivait :

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un
compte d'uid 0, c'est là l'avantage de cette solution en plus de
l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!

Oui, vous n'avez pas fait gaffe et je crois même, si je puis me permettre,
que vous n'avez rien compris.

Quel utilisateur ? Il n'y a aucun utilisateur, aucun shell, aucune
possibilité de lancer quoique ce soit.
Il n'y a qu'une seule commande et une seule, sans la possibilité d'y insérer
le moindre paramètre et qui de toute manière, quelque soit la méthode, ne
peut être lancé qu'avec l'uid 0.

Il y a bien un utilisateur de crée avec l'uid 0 et le gid 0.

A mon sens, il n' y a rien de moins secure, et rien que cette
manip devrait être interdite.

Par contre suid /sbin/halt ça c'est le *PIRE*.
Je l'ai dit que ça posait un gros problème de sécurité.

Et il y a eu une discussion et la solution proposée
est d'avoir un wrapper suid qui n'est accessible que par un seul
user et qui vérifie l'identité du user en question_avant_ de
lancer halt.

Et prétendre qu'il est préférable de suid un binaire que plutôt utiliser
sudo comme vous le disiez dans l'autre partie du thread c'est remettre en
cause l'origine de nombreux buffer overflow et donc remettre en cause
certain fondement de la sécurité sur Linux et autres Unix.
Non, aucun binaire suid n'est à l'origine d'un buffer overflow.

C'est exactement l'inverse !!!
Il y a des bugs, dont des problèmes de buffer overflow (mais
ce n'est pas le seul bug dangereux, loin de là....), qui peuvent
survenir dans n'importe quel programme et peuvent être exploités
de façon plus ou moins importante. Et celà se révèle évidement
beaucoup plus dangereux si le binaire en question est suid root
(et non pas s'il est suid d'ailleurs...).
Le programme que j'ai proposé, qui serait suid root, est simple
et il n'est pas dur de garantir qu'il ne pourra pas être exploité...
Déjà, il ne prends pas d'arguments, n'a pas d'input, n'ouvre
pas de fichier. J'aimerai que quelqu'un m'explique comment
il est possible de déclencher un buffer overflow dans ces conditions !!!

Petit rappel, il est demandé dans le post initial de pouvoir lancer la
commande /sbin/halt de la manière le plus simple sans que l'utilisateur
n'est à faire la moindre saisie (commande et/ou mot de passe) tout en
gardant un minimum de sécurité.
Oui, justement, avec un peu de sécurité...

Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...

C'est la faiblesse de votre argumentation et la prétention avec laquelle
vous vous exprimez qui est horrible... Elle n'aide vraiment pas au thread...
Il me semble que d'autres solutions ont été proposées,

et que le but est justement de trouver la meilleure.
Je ne prétends pas avoir trouvé *LA* solution, je dis d'ailleurs
que la solution proposée découle des propositions de Thierry
Boudet... Et que la votre me parait remettre en cause la sécurité
globale du système, à partir du moment ou root n'est plus le seul
à bénéficier des privilèges que lui confèrent son uid et son
gid. Ces privilèges _sont_ la base de la sécurité sous Unix...

M'enfin si pour vous aujourd'hui un jeu de clé RSA est à considérer comme
insecure et que suid un binaire est secure, je comprends alors la pauvreté
de votre intervention.
Le jeu de clé RSA n'est pas en cause, j'ai même dit que ça me semblait

être la meilleure solution pour la partie ssh !
Il faut lire avant de troller !

Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

Mais là quoi ? J'attends impatiemment votre argumentation.
Démontrez en quoi cette méthode est si insécure que vous le sous-entendez.
Et surtout démontrez en quoi votre méthode est plus secure...
Voilà, c'est fait je crois...

OK, je n'ai pas vraiment argumenté, vu l'heure quand j'ai répondu,
mais je crois que c'est corrigé.

Encore une fois, ma méthode est peut-être (et surement) perfectible
mais elle a le mérite:
- de limiter l'impact sur le système à 1 nouveau binaire crée.
- Ce binaire est dans un répertoire privé de l'utilisateur à
qui il est destiné.
- Ce binaire vérifie l'identité de celui qui le lance.
- Il n'a pas d'output, ne sert pas de l'environnement, n'ouvre pas
de fichiers, n'utilise pas la pile et ne peux donc pas être
exploité avec un exploit du type buffer-overflow
Il est peut-être exploitable d'une autre façon, ou buggé
ce qui le rend dangereux. Toute amélioration est bienvenue.
Mais sur le principe, c'est ce qui à apparement le moins d'impact
sur la sécurité globale de la machine sur lequel il sera installé.

On Wed, 13 Aug 2003 02:10:08 +0200, TiChou wrote:

Dans l'article news:pan.2003.08.12.23.13.34.196731@magic.fr,
J. Mayer <l_indien_no_more_spams@magic.fr> écrivait :

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un
compte d'uid 0, c'est là l'avantage de cette solution en plus de
l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!

Oui, vous n'avez pas fait gaffe et je crois même, si je puis me permettre,
que vous n'avez rien compris.

Quel utilisateur ? Il n'y a aucun utilisateur, aucun shell, aucune
possibilité de lancer quoique ce soit.
Il n'y a qu'une seule commande et une seule, sans la possibilité d'y insérer
le moindre paramètre et qui de toute manière, quelque soit la méthode, ne
peut être lancé qu'avec l'uid 0.

Il y a bien un utilisateur de crée avec l'uid 0 et le gid 0.

A mon sens, il n' y a rien de moins secure, et rien que cette
manip devrait être interdite.

Par contre suid /sbin/halt ça c'est le *PIRE*.
Je l'ai dit que ça posait un gros problème de sécurité.

Et il y a eu une discussion et la solution proposée
est d'avoir un wrapper suid qui n'est accessible que par un seul
user et qui vérifie l'identité du user en question_avant_ de
lancer halt.

Et prétendre qu'il est préférable de suid un binaire que plutôt utiliser
sudo comme vous le disiez dans l'autre partie du thread c'est remettre en
cause l'origine de nombreux buffer overflow et donc remettre en cause
certain fondement de la sécurité sur Linux et autres Unix.
Non, aucun binaire suid n'est à l'origine d'un buffer overflow.

C'est exactement l'inverse !!!
Il y a des bugs, dont des problèmes de buffer overflow (mais
ce n'est pas le seul bug dangereux, loin de là....), qui peuvent
survenir dans n'importe quel programme et peuvent être exploités
de façon plus ou moins importante. Et celà se révèle évidement
beaucoup plus dangereux si le binaire en question est suid root
(et non pas s'il est suid d'ailleurs...).
Le programme que j'ai proposé, qui serait suid root, est simple
et il n'est pas dur de garantir qu'il ne pourra pas être exploité...
Déjà, il ne prends pas d'arguments, n'a pas d'input, n'ouvre
pas de fichier. J'aimerai que quelqu'un m'explique comment
il est possible de déclencher un buffer overflow dans ces conditions !!!

Petit rappel, il est demandé dans le post initial de pouvoir lancer la
commande /sbin/halt de la manière le plus simple sans que l'utilisateur
n'est à faire la moindre saisie (commande et/ou mot de passe) tout en
gardant un minimum de sécurité.
Oui, justement, avec un peu de sécurité...

Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...

C'est la faiblesse de votre argumentation et la prétention avec laquelle
vous vous exprimez qui est horrible... Elle n'aide vraiment pas au thread...
Il me semble que d'autres solutions ont été proposées,

et que le but est justement de trouver la meilleure.
Je ne prétends pas avoir trouvé *LA* solution, je dis d'ailleurs
que la solution proposée découle des propositions de Thierry
Boudet... Et que la votre me parait remettre en cause la sécurité
globale du système, à partir du moment ou root n'est plus le seul
à bénéficier des privilèges que lui confèrent son uid et son
gid. Ces privilèges _sont_ la base de la sécurité sous Unix...

M'enfin si pour vous aujourd'hui un jeu de clé RSA est à considérer comme
insecure et que suid un binaire est secure, je comprends alors la pauvreté
de votre intervention.
Le jeu de clé RSA n'est pas en cause, j'ai même dit que ça me semblait

être la meilleure solution pour la partie ssh !
Il faut lire avant de troller !

Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

Mais là quoi ? J'attends impatiemment votre argumentation.
Démontrez en quoi cette méthode est si insécure que vous le sous-entendez.
Et surtout démontrez en quoi votre méthode est plus secure...
Voilà, c'est fait je crois...

OK, je n'ai pas vraiment argumenté, vu l'heure quand j'ai répondu,
mais je crois que c'est corrigé.

Encore une fois, ma méthode est peut-être (et surement) perfectible
mais elle a le mérite:
- de limiter l'impact sur le système à 1 nouveau binaire crée.
- Ce binaire est dans un répertoire privé de l'utilisateur à
qui il est destiné.
- Ce binaire vérifie l'identité de celui qui le lance.
- Il n'a pas d'output, ne sert pas de l'environnement, n'ouvre pas
de fichiers, n'utilise pas la pile et ne peux donc pas être
exploité avec un exploit du type buffer-overflow
Il est peut-être exploitable d'une autre façon, ou buggé
ce qui le rend dangereux. Toute amélioration est bienvenue.
Mais sur le principe, c'est ce qui à apparement le moins d'impact
sur la sécurité globale de la machine sur lequel il sera installé.

Vous avez filtré cet utilisateur ! Consultez son message

On Wed, 13 Aug 2003 02:10:08 +0200, TiChou wrote:

Dans l'article news:,
J. Mayer écrivait :

Nullement besoin de suid /sbin/halt, puisqu'il est lancé par un
compte d'uid 0, c'est là l'avantage de cette solution en plus de
l'auth par clé.
Aaarg, c'est encore pire,

je n'avais pas fait gaffe: l'utilisateur EST root !!!

Oui, vous n'avez pas fait gaffe et je crois même, si je puis me permettre,
que vous n'avez rien compris.

Quel utilisateur ? Il n'y a aucun utilisateur, aucun shell, aucune
possibilité de lancer quoique ce soit.
Il n'y a qu'une seule commande et une seule, sans la possibilité d'y insérer
le moindre paramètre et qui de toute manière, quelque soit la méthode, ne
peut être lancé qu'avec l'uid 0.

Il y a bien un utilisateur de crée avec l'uid 0 et le gid 0.

A mon sens, il n' y a rien de moins secure, et rien que cette
manip devrait être interdite.

Par contre suid /sbin/halt ça c'est le *PIRE*.
Je l'ai dit que ça posait un gros problème de sécurité.

Et il y a eu une discussion et la solution proposée
est d'avoir un wrapper suid qui n'est accessible que par un seul
user et qui vérifie l'identité du user en question_avant_ de
lancer halt.

Et prétendre qu'il est préférable de suid un binaire que plutôt utiliser
sudo comme vous le disiez dans l'autre partie du thread c'est remettre en
cause l'origine de nombreux buffer overflow et donc remettre en cause
certain fondement de la sécurité sur Linux et autres Unix.
Non, aucun binaire suid n'est à l'origine d'un buffer overflow.

C'est exactement l'inverse !!!
Il y a des bugs, dont des problèmes de buffer overflow (mais
ce n'est pas le seul bug dangereux, loin de là....), qui peuvent
survenir dans n'importe quel programme et peuvent être exploités
de façon plus ou moins importante. Et celà se révèle évidement
beaucoup plus dangereux si le binaire en question est suid root
(et non pas s'il est suid d'ailleurs...).
Le programme que j'ai proposé, qui serait suid root, est simple
et il n'est pas dur de garantir qu'il ne pourra pas être exploité...
Déjà, il ne prends pas d'arguments, n'a pas d'input, n'ouvre
pas de fichier. J'aimerai que quelqu'un m'explique comment
il est possible de déclencher un buffer overflow dans ces conditions !!!

Petit rappel, il est demandé dans le post initial de pouvoir lancer la
commande /sbin/halt de la manière le plus simple sans que l'utilisateur
n'est à faire la moindre saisie (commande et/ou mot de passe) tout en
gardant un minimum de sécurité.
Oui, justement, avec un peu de sécurité...

Si tu commences comme ça, ne t'embêtes pas, enlève toutes les
sécuritées, elles ne servent à rien....
Quelle horeur...

C'est la faiblesse de votre argumentation et la prétention avec laquelle
vous vous exprimez qui est horrible... Elle n'aide vraiment pas au thread...
Il me semble que d'autres solutions ont été proposées,

et que le but est justement de trouver la meilleure.
Je ne prétends pas avoir trouvé *LA* solution, je dis d'ailleurs
que la solution proposée découle des propositions de Thierry
Boudet... Et que la votre me parait remettre en cause la sécurité
globale du système, à partir du moment ou root n'est plus le seul
à bénéficier des privilèges que lui confèrent son uid et son
gid. Ces privilèges _sont_ la base de la sécurité sous Unix...

M'enfin si pour vous aujourd'hui un jeu de clé RSA est à considérer comme
insecure et que suid un binaire est secure, je comprends alors la pauvreté
de votre intervention.
Le jeu de clé RSA n'est pas en cause, j'ai même dit que ça me semblait

être la meilleure solution pour la partie ssh !
Il faut lire avant de troller !

Déjà qu'un utilisateur puisse être root directement depuis l'exterieur
est une horreur, mais là....

Mais là quoi ? J'attends impatiemment votre argumentation.
Démontrez en quoi cette méthode est si insécure que vous le sous-entendez.
Et surtout démontrez en quoi votre méthode est plus secure...
Voilà, c'est fait je crois...

OK, je n'ai pas vraiment argumenté, vu l'heure quand j'ai répondu,
mais je crois que c'est corrigé.

Encore une fois, ma méthode est peut-être (et surement) perfectible
mais elle a le mérite:
- de limiter l'impact sur le système à 1 nouveau binaire crée.
- Ce binaire est dans un répertoire privé de l'utilisateur à
qui il est destiné.
- Ce binaire vérifie l'identité de celui qui le lance.
- Il n'a pas d'output, ne sert pas de l'environnement, n'ouvre pas
de fichiers, n'utilise pas la pile et ne peux donc pas être
exploité avec un exploit du type buffer-overflow
Il est peut-être exploitable d'une autre façon, ou buggé
ce qui le rend dangereux. Toute amélioration est bienvenue.
Mais sur le principe, c'est ce qui à apparement le moins d'impact
sur la sécurité globale de la machine sur lequel il sera installé.

ripilaf2003

13/08/2003 à 15:45

Merci à tous pour vos contributions.

L'objectif premier est la simplicité d'extinction (voire reboot) de la
paserelle linux, la sécurité n'est pas la priorité dans mon cas.

Parmi les solutions proposées:
1) le wrapper en C: je n'ai pas les compétences pour l'implémenter
2) présence du user "halt" sur une mandrake puis connexion par shh:
c'est pas mal mais il faut se connecter ou scripter la connexion
3) creation d'un compte "éteindre", shell /bin/halt, uid 0, créeation
de clé sur la machine windows et intégration de la clé pub sur le
linux: cette solution me plait beaucoup car c'est la plus simple, il y
a une simple ligne de commande à lancer depuis windows, même pas de
script

je vais donc tenter de mettre en oeuvre la solution 3, sachant que la
distribution de la machine linux est debian et que les fichiers de ssh
ne sont pas rangés comme sur les autres distributions.

Merci
JD

ripilaf2003

13/08/2003 à 22:53

"TiChou" wrote in message news:<3f390614$0$6246$...

Dans l'article news:3f38faf8$0$6214$,
j'écrivais :

Suite à une annulation de post et un copié/collé trop hatif, mes slashs sont
mals passés dans mon précédent post.
Je redonne ici la partie concernant la configuration de la machine Linux
avec les bons slashs. :)

Sur la machine Linux :

On crée le compte 'eteindre'

# useradd -u 0 -o -g 0 -d /root/.halt -m -k /dev/null -s /sbin/halt eteindre
# mkdir /root/.halt/.ssh
# chmod -R 700 /root/.halt

On crée le fichier /root/.halt/.ssh/authorized_keys2 en y insérant la clé
publique générée précédement.

# vi /root/.halt/.ssh/authorized_keys2
# chmod 600 /root/.halt/.ssh/authorized_keys2

On vérifie que dans la configuration de sshd /etc/ssh/sshd_config on a :
PermitRootLogin without-password

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.
Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Voici les logs ssh:
Aug 13 22:35:19 WEBBER sshd[9729]: Server listening on 0.0.0.0 port
22.
Aug 13 22:40:00 WEBBER ssh(pam_unix)[9739]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:06 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:09 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: 3 more authentication
failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: service(ssh) ignoring max
retries; 4 > 3

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???
Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Merci.
JD

"TiChou" <gro.uohcit@uohcit> wrote in message news:<3f390614$0$6246$626a54ce@news.free.fr>...

Dans l'article news:3f38faf8$0$6214$626a54ce@news.free.fr,
j'écrivais :

Suite à une annulation de post et un copié/collé trop hatif, mes slashs sont
mals passés dans mon précédent post.
Je redonne ici la partie concernant la configuration de la machine Linux
avec les bons slashs. :)

Sur la machine Linux :

On crée le compte 'eteindre'

# useradd -u 0 -o -g 0 -d /root/.halt -m -k /dev/null -s /sbin/halt eteindre
# mkdir /root/.halt/.ssh
# chmod -R 700 /root/.halt

On crée le fichier /root/.halt/.ssh/authorized_keys2 en y insérant la clé
publique générée précédement.

# vi /root/.halt/.ssh/authorized_keys2
# chmod 600 /root/.halt/.ssh/authorized_keys2

On vérifie que dans la configuration de sshd /etc/ssh/sshd_config on a :
PermitRootLogin without-password

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.
Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Voici les logs ssh:
Aug 13 22:35:19 WEBBER sshd[9729]: Server listening on 0.0.0.0 port
22.
Aug 13 22:40:00 WEBBER ssh(pam_unix)[9739]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:06 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:09 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: 3 more authentication
failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: service(ssh) ignoring max
retries; 4 > 3

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???
Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Merci.
JD

Vous avez filtré cet utilisateur ! Consultez son message

"TiChou" wrote in message news:<3f390614$0$6246$...

Dans l'article news:3f38faf8$0$6214$,
j'écrivais :

Suite à une annulation de post et un copié/collé trop hatif, mes slashs sont
mals passés dans mon précédent post.
Je redonne ici la partie concernant la configuration de la machine Linux
avec les bons slashs. :)

Sur la machine Linux :

On crée le compte 'eteindre'

# useradd -u 0 -o -g 0 -d /root/.halt -m -k /dev/null -s /sbin/halt eteindre
# mkdir /root/.halt/.ssh
# chmod -R 700 /root/.halt

On crée le fichier /root/.halt/.ssh/authorized_keys2 en y insérant la clé
publique générée précédement.

# vi /root/.halt/.ssh/authorized_keys2
# chmod 600 /root/.halt/.ssh/authorized_keys2

On vérifie que dans la configuration de sshd /etc/ssh/sshd_config on a :
PermitRootLogin without-password

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.
Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Voici les logs ssh:
Aug 13 22:35:19 WEBBER sshd[9729]: Server listening on 0.0.0.0 port
22.
Aug 13 22:40:00 WEBBER ssh(pam_unix)[9739]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:06 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:09 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER sshd[9739]: Failed password for eteindre from
10.0.0.1 port 3217 ssh2
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: 3 more authentication
failures; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost.0.0.1
user=eteindre
Aug 13 22:40:39 WEBBER ssh(pam_unix)[9739]: service(ssh) ignoring max
retries; 4 > 3

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???
Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Merci.
JD

TiChou

14/08/2003 à 13:03

Dans l'article news:,
Jean Dupond écrivait :

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.

Probablement que le problème est du à l'utilisation de vos clés.
Le client ssh Windows lors de la session avec le Linux utilise-t-il bien la
bonne clé privé ?
Avec cygwin ça donnerait :
$ ssh -i /path/clé_private

(en supposant que webber est le nom de la machine Linux)

Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Il faut choisir entre yes ou without-password. Il ne peut y avoir deux fois
la même option avec une définition différente.
Je vous renvoie au man de sshd_config pour configurer au mieux votre sshd.
Sachez quand même qu'avec 'yes' on peut se loguer en root, soit avec le mot
de passe root, soit avec un jeu de clé. Avec 'without-password' on ne peut
se loguer en root seulement avec un jeu de clé.

Voici les logs ssh:

[snip les logs]

Les logs montrent que l'authentification se fait par mot de passe et donc
confirme que l'utilisation du jeu de clé n'est pas prise en compte.
Vous auriez du avoir quelque chose comme :

Aug 13 22:40:06 WEBBER sshd[9739]: Accepted publickey for eteindre from
10.0.0.1 port 3217 ssh2

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???

Non, c'est bien sur la machine cliente qu'il fallait générer les clés et
conserver la clé privé.
Je vous rassure, votre problème ne se situe pas au niveau de votre firewall.

Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Vous pouvez toujours les faire vos tests, cela confirmera que le problème ne
se situe pas au niveau réseau. :)

Pour résumer, vérifiez :

- que vos clés ont bien été généré avec le keygen fournit avec le client
ssh que vous utilisez
- que la clé privé (sous forme de fichier) est présente sur votre machine
Windows et utilisé par le client ssh
- que la clé publique est présente sur votre machine Linux, dans le
fichier ~/.ssh/authorized_keys2 (ou peut être ~/.ssh/authorized_keys) donc
ici dans mon exemple dans /root/.halt/.ssh/authorized_keys2 (ou
/root/.halt/.ssh/authorized_keys) et que les droits des répertoires et du
fichier sont corrects.

--
TiChou

Dans l'article news:5474da58.0308131253.2a07be59@posting.google.com,
Jean Dupond <ripilaf2003@yahoo.fr> écrivait :

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.

Probablement que le problème est du à l'utilisation de vos clés.
Le client ssh Windows lors de la session avec le Linux utilise-t-il bien la
bonne clé privé ?
Avec cygwin ça donnerait :
$ ssh -i /path/clé_private eteindre@webber

(en supposant que webber est le nom de la machine Linux)

Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Il faut choisir entre yes ou without-password. Il ne peut y avoir deux fois
la même option avec une définition différente.
Je vous renvoie au man de sshd_config pour configurer au mieux votre sshd.
Sachez quand même qu'avec 'yes' on peut se loguer en root, soit avec le mot
de passe root, soit avec un jeu de clé. Avec 'without-password' on ne peut
se loguer en root seulement avec un jeu de clé.

Voici les logs ssh:

[snip les logs]

Les logs montrent que l'authentification se fait par mot de passe et donc
confirme que l'utilisation du jeu de clé n'est pas prise en compte.
Vous auriez du avoir quelque chose comme :

Aug 13 22:40:06 WEBBER sshd[9739]: Accepted publickey for eteindre from
10.0.0.1 port 3217 ssh2

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???

Non, c'est bien sur la machine cliente qu'il fallait générer les clés et
conserver la clé privé.
Je vous rassure, votre problème ne se situe pas au niveau de votre firewall.

Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Vous pouvez toujours les faire vos tests, cela confirmera que le problème ne
se situe pas au niveau réseau. :)

Pour résumer, vérifiez :

- que vos clés ont bien été généré avec le keygen fournit avec le client
ssh que vous utilisez
- que la clé privé (sous forme de fichier) est présente sur votre machine
Windows et utilisé par le client ssh
- que la clé publique est présente sur votre machine Linux, dans le
fichier ~/.ssh/authorized_keys2 (ou peut être ~/.ssh/authorized_keys) donc
ici dans mon exemple dans /root/.halt/.ssh/authorized_keys2 (ou
/root/.halt/.ssh/authorized_keys) et que les droits des répertoires et du
fichier sont corrects.

--
TiChou

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article news:,
Jean Dupond écrivait :

Je viens d'essayer cette méthode: linux demande un mot de passe à
l'utilisateur "etiendre" alors que je n'en ai indiqué aucun lors de la
génération de la clef rsa.

Probablement que le problème est du à l'utilisation de vos clés.
Le client ssh Windows lors de la session avec le Linux utilise-t-il bien la
bonne clé privé ?
Avec cygwin ça donnerait :
$ ssh -i /path/clé_private

(en supposant que webber est le nom de la machine Linux)

Dans sshd_config j'ai:
PermitRootLogin yes
PermitRootLogin without-password

Il faut choisir entre yes ou without-password. Il ne peut y avoir deux fois
la même option avec une définition différente.
Je vous renvoie au man de sshd_config pour configurer au mieux votre sshd.
Sachez quand même qu'avec 'yes' on peut se loguer en root, soit avec le mot
de passe root, soit avec un jeu de clé. Avec 'without-password' on ne peut
se loguer en root seulement avec un jeu de clé.

Voici les logs ssh:

[snip les logs]

Les logs montrent que l'authentification se fait par mot de passe et donc
confirme que l'utilisation du jeu de clé n'est pas prise en compte.
Vous auriez du avoir quelque chose comme :

Aug 13 22:40:06 WEBBER sshd[9739]: Accepted publickey for eteindre from
10.0.0.1 port 3217 ssh2

Question:
le serveur windows qui prend la main sur le linux se trouve derrière
un firewall qui fait du nat (iptables), dans les logs je vois
rhost.0.0.1 qui est l'adresse IP d'une des cartes du firewall mais
pas l'adreses du client windows qui est en 192.168.0.x. Faut-il que je
génère la clé sur le firewall 10.0.0.1 afin d'être correcement
identifié ???

Non, c'est bien sur la machine cliente qu'il fallait générer les clés et
conserver la clé privé.
Je vous rassure, votre problème ne se situe pas au niveau de votre firewall.

Sinon je n'ai pas eu le temps de tester cette solution sur des
machines d'un même réseau sans passer par un firewall.

Vous pouvez toujours les faire vos tests, cela confirmera que le problème ne
se situe pas au niveau réseau. :)

Pour résumer, vérifiez :

- que vos clés ont bien été généré avec le keygen fournit avec le client
ssh que vous utilisez
- que la clé privé (sous forme de fichier) est présente sur votre machine
Windows et utilisé par le client ssh
- que la clé publique est présente sur votre machine Linux, dans le
fichier ~/.ssh/authorized_keys2 (ou peut être ~/.ssh/authorized_keys) donc
ici dans mon exemple dans /root/.halt/.ssh/authorized_keys2 (ou
/root/.halt/.ssh/authorized_keys) et que les droits des répertoires et du
fichier sont corrects.

--
TiChou

Nicolas LS

15/08/2003 à 21:01

sachant que pour 90% des noyaux Linux en production,
on peut passer root avec ~ 30 lignes de code C (sur PC)...
C'est un exploit qui a été découvert récement et qui concerne
tous les noyaux 2.2, tous les 2.4 (sauf le dernier) et tous
les 2.5 quel que soit l'environnement, les libs....

Ah bon :-) Plus sérieusement, c'est un exploit local, il faut avoir un
shell, alors la meilleur sécurité, c'est les retombées s'il pirate...
Sinon, tu parles a plusieurs reprises d'opérations qui ne peuvent etre
faites qu'après etre passé root, si tu es passé root, tu as déja un
accès complet.

Finalement, si tu procèdes comme tu le décris, tu mets ton code en
faisant des "copier/coller" dans chaque binaire pour ne pas utiliser de
librairies, le jour ou ton code a une faille, tu vas devoir corriger
dans tous tes programmes, sans en oublier un... Ca n'est pas l'idéal
non plus.

--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )

Extinction SIMPLISSIME à distance d'un poste linux...depuis une machine windows

8 réponses

Veuillez sélectionner un problème