Forum Linux.général SECURITE | ssh et connexion sans mot de passe

Posté par  . Licence CC By‑SA.
Étiquettes :
1
27
mai
2017

Bonjour à tous

J'ai deux serveurs un de prod et un de dev

Pour mes connexions ssh
- j'utilise un mot de passe que je tappe à chaque fois pour le serveurs de prod
- un couple de clef sur le serveur de dev ce qui me permet de ne pas avoir à tapper le mot de passe $ ssh serveurdev

Mais je me demande si ce type de connexion est aussi sécurisé?
Est il de voler la clef sur mon portable pour se connecter depuis un autre ordi?

  • # Connexion par clef chiffrée

    Posté par  . Évalué à 5.

    La méthode de connexion la plus sure est de passer par une paire de clef, comme ce que tu fais pour le dev, il vaudrait mieux le faire également pour la prod. À moins que ton mot de passe ne soit plus long et plus complexe que ta clef évidemment, mais ça devient très difficile à retenir.

    Si ta clef privée est en clair (non chiffrée) sur ton ordi perso alors il est possible à un intrus de la récupérer. Tu peux la protéger en la chiffrant (avec la commande ssh-keygen), ce qui fait que ssh te demandera le mot de passe de la clef à chaque utilisation (pour la déchiffrer), pour limiter cette contrainte tu peux utiliser un agent d'authentification (i.e. : les commandes ssh-agent et ssh-add) qui conservera ta clef déchiffrée pour un certain temps.

    Pour renforcer encore la sécurité de ta machine personnelle il est recommandé de chiffrer le disque.

    Pour augmenter la sécurité de la connexion à ton serveur ssh tu peux changer le port 22 en autre chose. Ça limite les attaques automatiques. Tu peux aussi utiliser un logiciel comme fail2ban. Pour aller plus loin tu peux également mettre en place du port-knocking.

    D'autres informations ici : http://wiki.auto-hebergement.fr/services/acc%C3%A8s_%C3%A0_distance#ssh

    • [^] # Re: Connexion par clef chiffrée

      Posté par  . Évalué à 2.

      Je te remercie,

      je viens de recréer un clef ssh-keygen avec une paraphrase(ma précédente n'en avais pas)
      Plus un ssh-add

      Tu recommande quelle longueur de paraprase'

      Tu recommande de chiffrer tout le disque? ou seulement une partition.
      Il y a t il une impact sur les perf?

    • [^] # Changement de port ssh

      Posté par  . Évalué à 2.

      sur mon serveur j'ai changé le port
      dans /etc/ssh/sshd_config

      # What ports, IPs and protocols we listen for
      Port 1012
      

      redemarré

      Mais du coup je peux me connecter sur les deux port?

      $ ssh User@Serveur -p 1012
      ou
      $ ssh User@Serveur -p 22

      • [^] # Re: Changement de port ssh

        Posté par  . Évalué à 1.

        Je comprends pas

        $ ssh User@server -p 22
        $ sudo netstat -tlnpu
        [sudo] password for User: 
        Connexions Internet actives (seulement serveurs)
        Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat       PID/Program name
        tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      944/mongod      
        tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1290/mysqld     
        tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      1968/memcached  
        tcp        0      0 0.0.0.0:1012            0.0.0.0:*               LISTEN      941/sshd        
        tcp6       0      0 :::80                   :::*                    LISTEN      689/apache2     
        tcp6       0      0 :::21                   :::*                    LISTEN      21181/proftpd: (acc
        tcp6       0      0 :::443                  :::*                    LISTEN      689/apache2     
        tcp6       0      0 :::7134                 :::*                    LISTEN      2008/java       
        tcp6       0      0 :::1012                 :::*                    LISTEN      941/sshd        
        udp        0      0 127.0.0.1:11211         0.0.0.0:*                           1968/memcached  
        udp        0      0 0.0.0.0:15584           0.0.0.0:*                           695/dhclient    
        udp        0      0 127.0.0.1:8135          0.0.0.0:*                           2034/tideways-daemo
        udp        0      0 0.0.0.0:68              0.0.0.0:*                           695/dhclient    
        udp6       0      0 :::19435                :::*                                695/dhclient 
        
    • [^] # Re: Connexion par clef chiffrée

      Posté par  . Évalué à 2.

      Tu peux aussi interdire à root de se connecter en SSH (c'est interdit par défaut, il me semble), et alors tu dois te connecter d'abord avec ton utilisateur, puis faire su.

      L'essentiel des attaques à l'aveugle se concentre sur root, faute de connaître les utilisateurs du système.

      • [^] # Re: Connexion par clef chiffrée

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

        Ou obliger root à utiliser une clé.

        man sshd_config

          PermitRootLogin
                     Specifies whether root can log in using ssh(1).  The argument must be “yes”, “without-password”, “forced-commands-only”, or “no”.  The default is “yes”.
        
                     If this option is set to “without-password”, password authentication is disabled for root.
        
                     If this option is set to “forced-commands-only”, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed).  All other authentication methods are disabled for root.
        
                     If this option is set to “no”, root is not allowed to log in.
        
  • # la configuration c'est important

    Posté par  . Évalué à 2.

    Je ne sais pas si tu l'a déjà lu, mais au cas ou… Un petit article sur la configuration de ssh à lire ici

  • # SSH

    Posté par  . Évalué à 2. Dernière modification le 28 mai 2017 à 14:23.

    Hello

    Selon ta distrib, ton changement de port d'écoute ssh peut être bloqué si, selon ta distrib, tu n'as pas conf le firewall en amont, exemple, sur les OS RedHat, il y a un Firewall natif qui ouvre le port 22 pour ssh car port natif mais ne changera rien sur le Firewall si tu changes le port d'écoute.

    Ceci est une explication parmi tant d'autres et n'est peut être pas à l'origine de ton pb, mais un test via chroot pour reprendre la main et contrôler les règles de Firewall ne coûte rien.

    Sinon un ssh user@serv -vvv pourra peut être t'aider :)

    • [^] # Re: SSH

      Posté par  . Évalué à 1.

      Je te remercie,

      Si ca te dis quelque chose je suis sous ubuntu.

      J'ai dans /etc/ssh/ssh_config
      Host *
      Port 1012

      dans /etc/ssh/sshd_config

      Port 1012
      dans /Home/Moi/.ssh/config

      Host *
      Port 1012
      puis à la connection
      ```
      $ ssh Moi@Serv -vvv
      OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
      debug1: Reading configuration data /home/Moi/.ssh/config
      debug1: Reading configuration data /etc/ssh/ssh_config
      debug1: /etc/ssh/ssh_config line 19: Applying options for *
      debug2: ssh_connect: needpriv 0
      debug1: Connecting to Serv [Serv] port 22.

      ```Alors je comprends pas

  • # SSH

    Posté par  . Évalué à 1. Dernière modification le 30 mai 2017 à 06:09.

    Bonjour,

    Pour la partie serveur, le fichier de configuration important est /etc/ssh/sshd_config

    Le fichier config tout court doit être coté client, il sert à enregistrer les serveurs distants de façon à ne pas entrer la commande ssh complète à chaque connexion.

    Sinon un ssh user@serv -vvv pourra peut être t'aider :) | est un exemple

    Si ton serveur répond au nom dns trololo.exemple, que l'utilisateur bob est autorisé à se connecter et que le port d'écoute ssh sur le serveur est 1012, alors la commande à taper est :

    ssh -p 1012 bob@trololo.exemple

    le -vvv n'est la que pour donner plus de détails en cas de non connexion, de façon à identifier la source du blocage.

    C'est plus clair ?

Suivre le flux des commentaires

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