Droit root sur serveur Debian

Bonsoir,

J’ai un utilisateur sur mon serveur Debian, nommé nox42 ^^
Je les rajouter dans le fichier sudoers, ainsi qu’administrateur dans l’administration utilisateur.
Mais pourtant il m’est impossible d’utiliser certaine commande, comme apt-get pour installer un nouveau logiciel.

Savez vous comment faire pour donner les droits d’administration à mon utilisateur ?
Merci d’avance de votre aide.

Bon… on va essayer d’être constructif… (on est pas encore 'dredi, même si ça y ressemble… :unamused: :016 :unamused: )

Alors, un administrateur sur un système GNU/Linux, il n’y en a qu’un… son login c’est “root” (pas la peine d’essayer de te connecter via une interface graphique avec ce compte, c’est “interdit” par défaut sous Debian)…

Tu peux avoir un "super-utilisateur’ avec “sudo” (si tu l’as installé bien entendu…) qui a plus ou moins de pouvoirs quand il utilise la commande “sudo”… Tu tapes bien tes commandes avec “sudo” devant?

Se mettre dans le groupe “adm” (si c’est autre chose, je vois pas, faudra être plus précis là… :unamused: ) ne permet qu’une chose: avoir accès à certains fichiers (en lecture uniquement) qui sont d’habitude “interdits” à l’utilisateur “normal” (principalement les fichiers de log…). Être dans le groupe “adm” ne permet pas d’avoir des droits d’administration, ça permet juste de “vérifier”…

:006

C’est qu’il est dit partout qu’on pas pas utiliser le compte root en ssh par sécurité, mais comme je pouvais rien faire avec les autres.
Et la commande sudo m’était refusé.
Mais j’avais oublié de tester avec sudo devant après m’etre mis dans sudoers.
Ca fonctionne avec sudo devant --’

Merci ^^ Au moins ce fut rapide :stuck_out_tongue:
J’ai l’habitude d’avoir tout les droits :smiley:

[quote=“nox42”]C’est qu’il est dit partout qu’on pas pas utiliser le compte root en ssh par sécurité, mais comme je pouvais rien faire avec les autres.
Et la commande sudo m’était refusé.
Mais j’avais oublié de tester avec sudo devant après m’etre mis dans sudoers.
Ca fonctionne avec sudo devant --’

Merci ^^ Au moins ce fut rapide :stuck_out_tongue:
J’ai l’habitude d’avoir tout les droits :smiley:[/quote]

Se connecter en ssh sur un serveur sur un autre compte que root c’est bien pour la sécurité, mais ensuite donner à ce compte les droits sudo c’est pas bien du tout car toute la sécurité est alors entamée car dès qu’il est logué l’utilsateur peut tout faire : tu as enlevé la barrière de root.

La gestion en root sur un serveur en ssh se fait en se connectant en tant qu’utilisateur puis ensuite on se log en root en tapant su dans le terminal, on donne le pass root et alors on peut faire toutes les opérations d’administration que l’on veut . Quand on a fini on se delog de root en tapant exit et l’on se retrouve sur le compte utilisateur.

Supprimes ces droits sudo que tu as donné à l’utilisateur si tu veux retrouver la sécurité de root.

[quote=“figaro”]
Se connecter en ssh sur un serveur sur un autre compte que root c’est bien pour la sécurité, mais ensuite donner à ce compte les droits sudo c’est pas bien du tout car toute la sécurité est alors entamée car dès qu’il est logué l’utilsateur peut tout faire : tu as enlevé la barrière de root.

La gestion en root sur un serveur en ssh se fait en se connectant en tant qu’utilisateur puis ensuite on se log en root en tapant su dans le terminal, on donne le pass root et alors on peut faire toutes les opérations d’administration que l’on veut . Quand on a fini on se delog de root en tapant exit et l’on se retrouve sur le compte utilisateur.

Supprimes ces droits sudo que tu as donné à l’utilisateur si tu veux retrouver la sécurité de root.[/quote]

Tous dépends de la gestion à faire pour seulement quelques commandes mieux vaudrait les autorisé et seulement celle-ci par sudo et réservé l’utilisation de su pour autres choses de plus contraignant.

Mieux vaut avoir deux pass successifs et différents pour l’administration surtout pour un serveur ouvert sur l’extérieur.

Mais se compliquer la vie avec un sudo limité à certaines fonctions, je ne vois pas l’intérêt surtout qu’il faudra de toute façon donner le code …

Maintenant on fait bien ce que l’on veut, mais sudo est une très mauvaise habitude mise à la mode par Ubuntu pour simplifier la vie soi-disant.

[quote=“Clochette”]
Tous dépends de la gestion à faire pour seulement quelques commandes mieux vaudrait les autorisé et seulement celle-ci par sudo et réservé l’utilisation de su pour autres choses de plus contraignant.[/quote]
Oui, je le fais ponctuellement quand j’ai des fréquents tests sur apache, par exemple. ainsi, ça m’évite de rester longtemps avec ‘root’ branché et de plus, le pass de ricardo est plus simple (quoi que …) que celui de root.
Sitôt mes tests terminés, je commente la ligne dans sudoers et plus personne n’est autorisé à employer ‘sudo’.

[quote=“nox42”]C’est qu’il est dit partout qu’on pas pas utiliser le compte root en ssh par sécurité, mais comme je pouvais rien faire avec les autres.
Et la commande sudo m’était refusé.
Mais j’avais oublié de tester avec sudo devant après m’etre mis dans sudoers.
Ca fonctionne avec sudo devant --’

Merci ^^ Au moins ce fut rapide :stuck_out_tongue:
J’ai l’habitude d’avoir tout les droits :smiley:[/quote]

Bien sur qu’il y a quand même quelque risque avec le ssh mais le tout est de prendre les bonne dispositions pour sécuriser son interface.

  • dés la connection un premier mdp pour te connecter a ton compte utilisateur

  • ensuite par la commande su tu rentre ton mdp root
    Donc deja parametrer ton ssh pour que tu ne rentre pas direct avec le mdp root

  • ensuite il faut changer le port proposé par defaut (qui est le 22). Bien sur ne pas choisir un port type 80 par exemple qui est un port http.
    donc eviter de lui donner ces ports la:

    • 21, pour l’échange de fichiers via FTP
    • 22, pour l’accès à un shell sécurisé Secure SHell, également utilisé pour l’échange de fichiers sécurisés SFTP
    • 23, pour le port telnet
    • 25, pour l’envoi d’un courrier électronique via un serveur dédié SMTP
    • 53, pour la résolution de noms de domaine en adresses IP : DNS
    • 67/68, pour la connexion au DHCP
    • 80, pour la consultation d’un serveur HTTP par le biais d’un Navigateur web
    • 110, pour la récupération de son courrier électronique via POP
    • 143, pour la récupération de son courrier électronique via IMAP
    • 389, pour la connexion à un LDAP
    • 443, pour les connexions HTTP utilisant une surcouche de sécurité de type SSL : HTTPS
    • 500, port utilisé pour le canal d’échange de clés IPsec
    • 636, pour l’utilisation d’une connexion à un LDAP sécurisé par une couche SSL/TLS
    • 1723, pour l’utilisation du protocole de VPN PPTP
    • 3389, pour le RCP de microsoft (Remote connection protocol)
    • 6667, pour la connexion aux serveurs IRC

C’est vrai que ça freine le port autre que le 22, c’est très compliqué pour trouver le port utilisé :unamused:

voila une partie de ma config

Si par hasard il trouve le port, il y a derriere MaxAuthTries qui limite le nombre de tentative pour entrer le mdp et LoginGraceTime qui, en secondes, bloque l’accés au ssh pendant la durée indiquée si le nombre de tentatives dépasse la valeur MaxAuthTries.

Je pense que niveau securité du ssh, c’est blindé.

Je n’ai jamais dit le contraire, je ne faisais allusion qu’au port différent de 22.

Je sais, j’ai compris que ce n’était qu’une remarque :wink:

[quote=“figaro”]Se connecter en ssh sur un serveur sur un autre compte que root c’est bien pour la sécurité, mais ensuite donner à ce compte les droits sudo c’est pas bien du tout car toute la sécurité est alors entamée car dès qu’il est logué l’utilsateur peut tout faire : tu as enlevé la barrière de root.

La gestion en root sur un serveur en ssh se fait en se connectant en tant qu’utilisateur puis ensuite on se log en root en tapant su dans le terminal, on donne le pass root et alors on peut faire toutes les opérations d’administration que l’on veut . Quand on a fini on se delog de root en tapant exit et l’on se retrouve sur le compte utilisateur.

Supprimes ces droits sudo que tu as donné à l’utilisateur si tu veux retrouver la sécurité de root.[/quote]

C’est noté. Merci
Je comprend mieux la logique de sécurité maintenant.

Et merci Minus pour la précision des ports =)