Forum Linux.général sécurisation accès ssh sur raspberry pi

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
3
mar.
2018

Bonjour,
Je cherche à accéder à mon réseau local à distance par un accès ssh sur raspberry pi.

J'ai une petite question de débutant :
Avec la commande ssh-copy-id -i /chemin/cle.pub -p port user@ip je peux copier sur le serveur ssh une clé que j'ai généré sur mon ordinateur client. Comment empêcher n'importe quel ordinateur client de copier sa clé sur mon serveur et de s'y connecter?

Merci

  • # Et toi comment fais-tu ?

    Posté par  . Évalué à 4.

    D'abord je suppose que tu veux parler de connexion SSH et non SSL ;)

    Lorsque tu lances cette commande :
    ssh-copy-id -i /chemin/cle.pub -p port user@ip
    le mot de passe de user sur la machine ip t'est demandé. Donc seul celui qui connaît ces identifiants peut le faire. D'autre par c'est ta clé publique que tu dois copier sur le serveur pas celle de l'ordinateur client.

    Note bien qu'une fois que tu auras copié ta clé publique sur le serveur et vérifié que l'accès par clés fonctionne tu pourras éventuellement reconfigurer le serveur pour qu'il n'accepte que les connexions par clés.

    • [^] # Re: Et toi comment fais-tu ?

      Posté par  . Évalué à 1.

      oui SSH pas ssl…
      Oui la commande ssh-copy-id -i /chemin/cle.pub -p port user@ip permet de copier sa clé publique sur le serveur, qui n'est pas à proprement parler celle de l'ordinateur client, mais qui est localisée sur le disque dur de l'ordinateur client.
      A priori le serveur est déjà configuré pour n'accepter que les connexions par clés. Seulement, si cest le cas, est ce que la commande ci-dessus permet encore à un nouvel utilisateur de copier sa clé publique sur le serveur?

      Dans ce cas si je comprend bien, seul le mot de passe de "user" sur le serveur "ip" empecherait que n'importe qui envoie sa clé publique et se connecte par la suite?

      • [^] # Re: Et toi comment fais-tu ?

        Posté par  . Évalué à 3.

        Non, je n'ai pas l'impression que tu aies compris. La commande ssh-copy-id est juste une commande pour faciliter la copie de la clé publique d'un utilisateur dans le fichier authorized_keys d'un utilisateur du serveur. Cela revient à ouvrir une connexion SSH, copier la clé publique dans le dit fichier et fermer la connexion.

        Tu ne peux copier une clé publique sur un serveur que si tu à déjà un accès à ce serveur (par clé ou par mot de passe).

        Si toto veut se connecter au compte de titi en SSH sur un serveur depuis son ordinateur :

        toto@son_ordinateur:~$ ssh titi@serveur_distant
        soit il doit saisir le mot de passe de titi, soit il se connecte automatiquement parce que la clé publique de toto (/home/toto/.ssh/id_rsa.pub pour une clé RSA) est dans le fichier /home/titi/.ssh/authorized_keys sur le serveur.

      • [^] # Re: Et toi comment fais-tu ?

        Posté par  . Évalué à 3.

        seul le mot de passe de "user" sur le serveur "ip" empecherait que n'importe qui envoie sa clé publique et se connecte par la suite?

        À partir du moment où tu connais le mot de passe pour te connecter en SSH, rien ne t’empêche de copier ta clé (avec ssh-copy-id par exemple)

        Donc oui, si quelqu’un connaît le mot de passe de user@server il peut se connecter et donc ajouter sa clé. Je ne crois pas que tu puisses empêcher cela mais je ne suis pas spécialiste de SSH…

  • # Login SSH par clef uniquement

    Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 05/03/18 à 12:37.

    Il y a beaucoup de réponses sur le fonctionnement de ssh et des clefs dont je n'y reviendrai pas.

    Pour répondre à la problèmatique initiale: "Comment empêcher n'importe quel ordinateur client de copier sa clé sur mon serveur et de s'y connecter?" (modulo les erreurs de langage) tu peut une fois les accès par clef activés et validés supprimé sur le serveur la possibilité de s'authentifier par mot de passe en rajoutant/modifiants les directives suivante de /etc/ssh/sshd_config (emplacement debian):

    PermitRootLogin no
    PasswordAuthentication no

    puis en redemarrant le service ssh (service ssh restart)

Suivre le flux des commentaires

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