Sujet: su root... incorrect password
15/10/2007 @ 18:12:27: zion: su root... incorrect password
Yop,

Merde, merde.. et merde :petrus:

J'ai fait une mise à jour assez importante de SSH, openssl et cie sur un serveur il y a une dizaine de jours et pas de bol, je devais faire une mise à jour de PAM aussi. Bref, SSH fonctionnait toujours après la mise à jour, je me disais "youpiiie".

Pas de chance, voila que je me reconnecte maintenant et... y a une couille dans le ventilo :tinostar:

Quand je fais un:

su root
je me prends sans avoir de prompt un:
su: incorrect password


Ce qui est pas sympa vu que j'ai pas eu l'occasion de le taper :tinostar:

La question étant maintenant comment récupérer la situation à distance alors que je n'ai pas d'accès root mais simple user :dawa:
(mais le simple user a quelques droits, mais clairement pas admin :oh: )

A votre bon coeur :tinostar:
15/10/2007 @ 18:22:21: zion: su root... incorrect password
Je sens que bibi va devoir prévoir une excursion jusqu'au serveur en question :petrus:

(Non je vous rassure, c'est pas celui-ci, et comme il tourne très bien, y a pas de panique... mais bon c'est moins pratique :kiki: )
15/10/2007 @ 18:33:26: philfr: su root... incorrect password
Tu ne peux pas faire un ssh direct en root plutôt que d'utiliser su ?

Edit: relu, et vu que non...

Reedit: pas si sûr, tu as essayé ?
15/10/2007 @ 18:36:26: didix: su root... incorrect password
"su root, su root, je m'mets en route" (sur l'air de "I feel good") :discotinostar:

:dehors:
15/10/2007 @ 18:39:57: zion: su root... incorrect password
philfr> Non, access denied, j'ai bloqué l'accès root en ssh évidemment :tinostar:
15/10/2007 @ 18:42:09: philfr: su root... incorrect password
Faut pas faire ça :oh:

On t'a dit que c'était plus secure ?
15/10/2007 @ 18:53:58: zion: su root... incorrect password
Oui :oh:

J'attends tes explications pour le contraire... :grin:

(Mais cela ne résoudra pas encore le problème immédiat, je suppose que j'aurai un :"faut aller sur place en console" :cry: )
15/10/2007 @ 19:49:00: philfr: su root... incorrect password
J'attends tes explications pour le contraire... :grin:


sshd tourne forcément en root sur le serveur, puisqu'il doit pouvoir te donner n'importe quelle identité. S'il y a une vulnérabilité dans sshd, le fait d'avoir empêché le login root ne changera rien.
Une analyse des paquets TCP lorsque tu tapes un password dans ssh (que ce soit pour un login ssh ou pour un su) donne des informations (écart entre les pression de touches) et affaiblit ton password.
Être obligé de créer un compte supplémentaire pour te loguer est une faille supplémentaire (si ce compte ne sert qu'à çà) en soi.

La bonne solution: accès root immédiat dans ssh avec clé DSA.

(Mais cela ne résoudra pas encore le problème immédiat, je suppose que j'aurai un :"faut aller sur place en console" :cry: )


Si t'as pas l'accès root, tu ne pourras jamais corriger un problème d'accès root :spamafote:

La leçon: après un upgrade, avant de quitter la session root qui a permis de faire l'upgrade, tenter d'ouvrir une nouvelle session root... Me suis déjà fait avoir aussi :petrus:
15/10/2007 @ 20:02:47: ovh: su root... incorrect password
philfr je ne suis pas trop d'accord avec toi... Interdire l'accès root direct est une bonne pratique qui limite le danger des attaques par brute force quand même !
Sinon bien sûr l'accès par clé c'est le bien, même si n'autoriser que ça n'est pas toujours la solution quand tu dois pouvoir avoir accès au serveur de n'importe où, même d'une machine qui n'est pas la tienne (et où donc tu n'aurais pas tes clés avec toi). Et le changement de port du service est une nécessité mais ça tombe sous le sens :wink:
15/10/2007 @ 20:04:49: zion: su root... incorrect password
sshd tourne forcément en root sur le serveur, puisqu'il doit pouvoir te donner n'importe quelle identité. S'il y a une vulnérabilité dans sshd, le fait d'avoir empêché le login root ne changera rien.


Jusque la on est d'accord.


Une analyse des paquets TCP lorsque tu tapes un password dans ssh (que ce soit pour un login ssh ou pour un su) donne des informations (écart entre les pression de touches) et affaiblit ton password.


La non, no way qu'on espionne mes touches SSH vu que je suis dans 99% des cas sur un réseau privé et que je n'utilise pas mon compte SSH ailleurs sauf urgence. (en gros c'est arrivé 2 fois cette année).


Être obligé de créer un compte supplémentaire pour te loguer est une faille supplémentaire (si ce compte ne sert qu'à çà) en soi.


Non, c'est un compte usuel.


La bonne solution: accès root immédiat dans ssh avec clé DSA.


Oui, mais du coup je dois me trimballer toujours avec la clé sur moi, pas question en vitesse dans un cyber de me connecter alors que je vois que lighttpd est down... :kiki:

J'irai sur place durant le mois, mais pour mon problème, tu penses que PAM est mort? :joce:
T'as une idée quelconque? J'ai pas envie de rester 3 ans sur place à chercher un truc sans succès (j'y ai déjà passé une nuit, c'est pénible :oh: )
15/10/2007 @ 20:22:39: philfr: su root... incorrect password
philfr je ne suis pas trop d'accord avec toi... Interdire l'accès root direct est une bonne pratique qui limite le danger des attaques par brute force quand même !
Sinon bien sûr l'accès par clé c'est le bien, même si n'autoriser que ça n'est pas toujours la solution quand tu dois pouvoir avoir accès au serveur de n'importe où, même d'une machine qui n'est pas la tienne (et où donc tu n'aurais pas tes clés avec toi).


Un accès user peut tout aussi bien être craqué par brute force. Et en accès local, le nombre de vulnérabilités potentielles pour un privilege escalation est multiplié -> c'est donc un faux sentiment de sécurité.
Si c'est vraiment nécessaire, un password root absurdement long que tu as sur toi dans un bloc notes ou un PDA peut faire l'affaire. Et le brute force peut alors se lever tôt.
Mais qui n'a plus un stick usb comme porte-clé (dans tous les sens du terme dans ce cas-ci) ?

Et le changement de port du service est une nécessité mais ça tombe sous le sens :wink:


Cela va de soi, mais ce n'était pas le sujet.
15/10/2007 @ 20:22:49: Dr_Dan: su root... incorrect password
philfr je ne suis pas trop d'accord avec toi... Interdire l'accès root direct est une bonne pratique qui limite le danger des attaques par brute force quand même !
Sinon bien sûr l'accès par clé c'est le bien, même si n'autoriser que ça n'est pas toujours la solution quand tu dois pouvoir avoir accès au serveur de n'importe où, même d'une machine qui n'est pas la tienne (et où donc tu n'aurais pas tes clés avec toi). Et le changement de port du service est une nécessité mais ça tombe sous le sens :wink:



Desactiver les login par mot de passe dans SSH c'est le bien! :grin:
J'ai toujours mes clef privées sur une clef usb que j'emporte avec moi.
Et puis je ne me connecterai jamais sur un serveur sensible à partir d'une machine que je ne connais pas. :oh:
15/10/2007 @ 20:30:05: philfr: su root... incorrect password
Dr_Dan> :jap:
:wink:
15/10/2007 @ 20:37:48: Altar: su root... incorrect password

Desactiver les login par mot de passe dans SSH c'est le bien! :grin:
J'ai toujours mes clef privées sur une clef usb que j'emporte avec moi.
Et puis je ne me connecterai jamais sur un serveur sensible à partir d'une machine que je ne connais pas. :oh:


+1, j'ai toujours mon laptop avec moi :oh:
15/10/2007 @ 20:40:53: ovh: su root... incorrect password
Un accès user peut tout aussi bien être craqué par brute force. Et en accès local, le nombre de vulnérabilités potentielles pour un privilege escalation est multiplié -> c'est donc un faux sentiment de sécurité.

M'enfin ! Je veux bien qu'il existe des exploits, mais en user on est quand même plus limité qu'en root, sinon à quoi ça servirait de faire différents niveaux ? :heink:
Et puis tout attaquant n'a pas nécessairement sous la main directement les exploits qui-vont-bien... Un mec qui a juste tenté un brute force sur un compte root peut faire des dégâts irrémédiables d'une simple commande shell, ce qui sera moins aisé en simple user...
Désolé mais j'ai vraiment du mal à avaler qu'autoriser un accès administrateur à distance ne nuit en rien à la sécurité... :wam:

Pour les autres avec les clés> tous les cyber n'autorisent pas l'usage de clés usb et encore moins la connexion de laptops personnels sur leur réseau... Et non il n'y a pas de wifi disponible partout :itm:
15/10/2007 @ 20:49:19: cauet: su root... incorrect password
J'suis assez partagé avec ovh..
Si l'user root est refusé ca permet déjà pas mal d'arret du brut force..
99% des bots vont tester avec le login "root".. il peux toujours chercher le mot de passe dans ce cas.. :joce:
15/10/2007 @ 20:49:48: philfr: su root... incorrect password
ovh> Si le user peut faire su pour passer root, deux brute force au lieu d'un feront l'affaire. Mais si tu suis un peu les security advisories, tu verras que pour chaque exploit remote il y a des dizaines d'exploits locaux. Donc un accès user est faussement rassurant. Et un accès remote par password est idéalement à bannir.
15/10/2007 @ 20:50:55: philfr: su root... incorrect password
99% des bots vont tester avec le login "root".. il peux toujours chercher le mot de passe dans ce cas.. :joce:


100% des bots essaient sur le port 22. Nous ne sommes pas concernés :oh:

Ici on parle des amis qui te veulent du mal...
15/10/2007 @ 21:07:06: Dr_Dan: su root... incorrect password

Pour les autres avec les clés> tous les cyber n'autorisent pas l'usage de clés usb et encore moins la connexion de laptops personnels sur leur réseau... Et non il n'y a pas de wifi disponible partout :itm:


Une connexion gprs est suffisante pour une session ssh. et est disponible partout. :tongue:
15/10/2007 @ 22:24:59: ovh: su root... incorrect password
Une connexion gprs est suffisante pour une session ssh. et est disponible partout. :tongue:

Mouarf, de 1 c'est ultra cher, de 2 à ce que j'ai entendu de ce type de connexion c'est presqu'inutilisable :rofl:
Retour