• # Ou est le problème?

    Posté par  (site web personnel) . Évalué à 6.

    Je ne vois pas le problème, c'est lequel?
    (ne me dit pas quand même que tu ne bloquais pas SSH à root dans les premières choses que tu faisais quand tu avais une machine "vierge" ayant encore cette non configuration…)

  • # Notification

    Posté par  . Évalué à 1.

    Quelle distribution ?

    Parce que je suis quasiment certain que lorsque cette mise à jour est arrivée dans ma Debian testing, j'ai eu une notification m'expliquant qu'il fallait que je fasse attention à ce changement.

    • [^] # Re: Notification

      Posté par  . Évalué à 1.

      Oui sous debian testing on te pose maintenant la question lors de la mise à jour de ssh : faut-il appliquer la nouvelle configuration par défaut qui place l'option PermitRootLogin de sshd à no-password.
      A noter qu'avec cette option les clés fonctionnent toujours.
      C'est une très bonne pratique en terme de sécurité de ne pas avoir de login root avec mot de passe car ça limite beaucoup les chances qu'une attaque de type brute force puisse fonctionner.
      Après ajouter un fail2ban de nos jours c'est pas du luxe.

      • [^] # Re: Notification

        Posté par  . Évalué à -10.

        pourquoi pas root + fail2ban ?

        • [^] # Re: Notification

          Posté par  (site web personnel) . Évalué à 2.

          C'est moins sécurisé ! ( cf commentaires du dessus )

          Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

          • [^] # Re: Notification

            Posté par  . Évalué à -7.

            Comment fait-on avec une machine hébergée, par exemple ?

            Il faut un accès physique à la machine.

            • [^] # Re: Notification

              Posté par  (site web personnel) . Évalué à 3.

              Même avec une machine hébergée, tu as la possibilité de transférer ta clef ssh avant de désactiver l'accès par mot de passe.

              De toute façon, en cas de problème, tu as toujours un accès console, même si c'est via une page web (je pense à ovh par exemple).

              • [^] # Re: Notification

                Posté par  (site web personnel) . Évalué à 1.

                Bonjour,
                il me semble que ça fait un bout de temps que OVH à supprimé les vKVM.
                Donc pour OVH il ne reste que le reboot sur un disque virtuel.
                Chez Online on a bien un accès KVM.

                Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

                • [^] # Re: Notification

                  Posté par  (site web personnel) . Évalué à 1.

                  Donc pour OVH il ne reste que le reboot sur un disque virtuel.

                  Sauf si tu payes.
                  http://www.ovh.com/fr/serveurs_dedies/kvm_ip.xml
                  (ils abusent un peu la… surtout, on n'a pas de demande ponctuelle facile, alors que chez Hetzner par exemple hop un ticket et tu as 2 heures gratos de KVM dans les 2 heures)

                  • [^] # Re: Notification

                    Posté par  (site web personnel) . Évalué à 3.

                    De toute façon, si celui de OVH est le même que le vKVM qu'ils avaient il y a deux ans avant de couper le service sans préavis, alors il y aura des problèmes de clavier à cause des encodages etc, c'est à dire une sorte de qwerty mais sans les caractères en dehors de l'alphabet (vécu).

                    Chez Online, c'est un vrai KVM, on peut même détruire la machine si on touche au bios avec et qu'on fait une erreur (mais qui voudrait toucher au bios?).
                    Le KVM de Online est inclus dans le prix de la location du serveur. On l'a quand on veut, avec du Java dans le navigateur quand même. Aucun soucis de clavier.

                    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

            • [^] # Re: Notification

              Posté par  (site web personnel) . Évalué à 1.

              Il faut un accès physique à la machine.

              En plus des réponses déjà apportées, tu peux avoir aussi IPMI, et hop tu vois le BIOS etc de ta machine.
              C'est beau la technologie, sans accès physique à la machine.

              • [^] # Re: Notification

                Posté par  (site web personnel) . Évalué à 1.

                Oui, l'IPMI est beaucoup mieux que les KVM Ip USB… Bien moins de bordel de fils à l'arrière, consommation quasi nulle, très facile à configurer sur un VLAN // en utilisant la même interface eth0.

                Le seul soucis d'IPMI est que la norme évolue peu et que le SOL (console série) ne marche pas partout, que la suppression d’événement non plus (le plus souvent, il faut virer tous les événements) et que je ne vois pas du tout se pointer une standardisation pour avoir par exemple un port VNC dessus.

                C'est un peu dommage car IPMI est clairement ultra pratique et à mon avis, la seule solution déployable à grande échelle.

        • [^] # Re: Notification

          Posté par  (site web personnel) . Évalué à 2.

          Parce que root + fail2ban limite le risque d'une connexion malicieuse en root, mais ne le supprime pas totalement.

          De manière générale, on interdit toute connexion en root (à distance ou localement). On travaille avec un compte non privilégié. Et on utilise sudo pour les actions réclamant plus de droit.
          Cela permet aussi de prendre l'habitude de ne pas travailler avec un compte privilégié pour des actions qui n'en ont pas besoin, ce qui limite le risque d'erreur qui font mal.
          Accessoirement, sur une machine avec plusieurs admin, cela permet de savoir plus facilement qui fait quoi.

          • [^] # Re: Notification

            Posté par  (site web personnel) . Évalué à 3.

            A noter que PermitRootLogin est mal nommé. En fait, il interdit la connexion des utilisateurs ayant l'UID zéro. Il est possible d'avoir un autre utilisateur, avec un shell restreint par exemple et se nomme robot-r2d3, ayant l'uidNumber 0 et le shell rssh et mettre :

            PermitRootLogin without-password
            DenyUsers root
            AllowUsers robot-r2d3@backupserver.example.com
            La directive DenyUsers fonctionne sur le nom 'root' alors que PermitRootLogin fonctionne sur l'uidNumber. C'est un peu piégeant mais difficile à changer… Quoique une nouvelle directive équivalent à PermitRootLogin ne serait pas plus mal.

            L'astuce ci dessus est pratique dans quelque cas où je n'ai pas trouvé d'autre solution. Par ailleurs, elle est globalement très robuste.

            • [^] # Re: Notification

              Posté par  . Évalué à 3.

              Il faut quand même avouer que de manière générale avoir plusieurs utilisateurs avec le même uid est un peu casse-gueule, mais je suis d'accord ça se fait.

              Après le problème que tu soulèves est assez général, il y a nombre de point dans les docs où l'on parle de root pour parler d'utilisateur uid=0. Il y a aussi des programmes (mal codés) qui vérifie que l'utilisateur qui le lance s'appelle root et non qu'il a l'uid=0.

              Il faut s'amuser, au moins une fois dans sa vie, à nomer l'utilisateur uid=0 autrement (j'ai une préférence pour god) et créer un compte nommé root non privilégié. Là on se rend compte que c'est un peu le bordel entre les outils qui lancés avec god disent non tu n'as pas droit de le faire (sans même essayer), et ceux qui lancés avec root disent ok, tu peux le faire mais qui plante lamentablement après.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.