Yop,

Merde, merde.. et merde

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

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

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

A votre bon coeur

Je sens que bibi va devoir prévoir une excursion jusqu'au serveur en question

(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 )

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é ?

"su root, su root, je m'mets en route" (sur l'air de "I feel good")

philfr> Non, access denied, j'ai bloqué l'accès root en ssh évidemment

Faut pas faire ça

On t'a dit que c'était plus secure ?

Oui

J'attends tes explications pour le contraire...

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

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.



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

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

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

Jusque la on est d'accord.



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).



Non, c'est un compte usuel.



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...

J'irai sur place durant le mois, mais pour mon problème, tu penses que PAM est mort?
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 )

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) ?



Cela va de soi, mais ce n'était pas le sujet.

Desactiver les login par mot de passe dans SSH c'est le bien!
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.

Dr_Dan>

+1, j'ai toujours mon laptop avec moi

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 ?
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é...

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

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..

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.

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

Ici on parle des amis qui te veulent du mal...

Une connexion gprs est suffisante pour une session ssh. et est disponible partout.

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