To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
L’accès ou le stockage technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou l’internaute.
The technical storage or access that is used exclusively for statistical purposes.
Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Ouf, je n’irais pas en enfer ! 😉
Interessant, surtout pour l’argumentaire!
D’ailleurs, par curiosité, pour quelles raisons déconseilles tu l’utilisation du compte root en SSH?
En fait il faut plus comprendre qu’il ne faut pas autoriser l’accès root par SSH. Ce qui devient logique.
il faut d’abord se connecter en user puis le cas échéant faire une élévation des privilèges via sudo ce qui est encore mieux que passer par su de suite.
Il existe une maxime qui dit:
Il existe 2 sortes d’utilisateurs root : celui qui a déjà fait une connerie et celui qui va en faire une …..
@admin
Je pense bien comprendre le raisonnement général, mais reste dubitatif sur un point.
Pour quelle raison ne faudrait il pas se connecter en tant qu’utilisateur root via SSH pour les taches d’administration necessitant ses droits, si c’est pour utiliser ‘su’ comme première commande une fois connecté ou systematiquement ‘sudo’ qui va autoriser l’administrateur à effectuer autant de bourdes qu’un accès root tout simple?
Tout d’abord il ne suffit pas que protéger l’utilisateur contre lui même mais bel et bien de protéger l’accès vers l’extérieur.
Deuxièmement les probabilités de faire une bourde irréparable via Sudo sont moindres. En effet le fait que sudo demande le mot de passe … fait réfléchir sur ce que l’on fait. De même un rm -rf malencontreux en user n’aura pas d’effet par contre en root …..
Ce ne sont que des exemples mais tirés de faits réel.
N’importe quel sysadmin digne de ce nom te répondrait la même chose.
Pingback: pscoffoni's status on Tuesday, 30-Jun-09 20:25:18 UTC - Identi.ca
Tout d’ailleurs, "sudo" = commande à proscrire si c’est pour obtenir les droits root complet. Pourquoi ? Parce qu’à la place d’un mot de passe pour root, et un différent pour les autres compte, on se retrouve avec un compte standard avec les pouvoirs root … bizarre.
Sudo, c’est bien pour donner des autorisations spéciales, pas des pour devenir root.
Quant à l’argumentaire taper sudo fait réfléchir", c’est du n’importe quoi sorti de la bouche de celui qui l’utilise 2 fois par jour. Quand tu as des tâche d’administration régulière, ou juste ponctuelles et lourdes, le sudo, tu le tape à toutes les commandes sans même te demander si tu en avait besoin.
Genre le "sudo ls /repertoire/visible/que/par/root", c’est très moche ! Et tout le monde finit généralement par un magnifique "sudo su", ou l’utilisation absurde par excellence de sudo. un simple "su" suffirait …
Se connecter à root en SSH, c’est pas bien.
Ah bon ?
Et qu’est ce qui est pire :
– se connecter en utilisateur normal avec un mot de passe
– se connecter en root avec une clé publique/privée
Je dirais bien la première option … parce que bruteforcer un clé asymétrique, c’est dur !
En plus, empêcher le bruteforce, est pas très difficile : aptitude isntall fail2ban
C’était si dur ?
Quand j’ai commencé sous GNU/Linux, j’ai beaucoup lu, pas sur les forums ou les blogs mais des manuels. Je crois que l’un des erreurs principales à éviter est de ne pas lire, je veux dire se documenter (pages man, etc.), de travailler au feeling. C’est très dangereux. Ce qui m’amène à réénoncer un principe que j’ai lu, dès le début, et qui me semble être un très « bon » enseignement : « Ne rien faire que l’on ne peut défaire ! »
2 arguments assez drôles:
C’est vrai que la cosmétique des commandes c’est un argument de sécurité. De plus si sudo est trop long à taper pour toi tu n’as qu’à faire un alias sur sudo comme R par exemple !!
Maintenant pour terminer je répète et j’affirme que l’on doit éviter au maximum de se connecter en root. Si tu dois te connecter en root toute la journée c’est que tu as un problème d’organisation. Je te renvoie donc au manuel du sysadmin (celui que tu voudras d’ailleurs). Je terminerai en disant que tu dois me connaître pour affirmer :
Alors où s’est on rencontré? Je serais ravi d’échanger avec toi sur le sujet.
En effet Christophe un des secrets consiste à se documenter le plus possible.
@admin
Je rejoins Ludo sur plusieurs points :
– il n’est pas évident que de devoir taper quotidiennement un grand nombre de commandes en root forme en soi le signe d’une mauvaise organisation. Cet argument mériterait d’être développé.
– je ne trouve pas dans les fils de discussion ci dessus de description explicite des dangers de la connexion SSH en tant que user root comparée à la connexion en tant qu’utilisateur ayant tous les droits via sudo.
Et concernant la bonne remarque de Christophe, s’il est vrai que de se documenter est primordial, il l’est tout autant de comprendre les raisons qui motivent les « bonnes recommandations », « commandemants », « pêchés capitaux ».
Connexion distante en root => Connexion anonyme.
Imaginons que sur un parc de machines, il y ait plusieurs dizaines de mainteneurs, connaissant tous les mots de passe root.
Quand on regarde qui s’est loggué sur une machine et qu’on voit "root", on est pas très avancé.
Forcé les connexions avec un véritable identifiant, c’est permettre de savoir Qui fait quoi.