Bonjour,

Je m'interroge sur les précautions à prendre si je veux rendre disponible un ubuntu server par ssh

Je débute avec ssh, avez-vous des conseils notamment au sujet de ufw ?

j'ai cette config pour l'instant :
$ sudo ufw status numbered 
État : actif

     Vers                       Action      De
     ----                       ------      --
[ 1] 22/tcp                     ALLOW IN    Anywhere                  
[ 2] 80/tcp                     ALLOW OUT   Anywhere                   (out)
[ 3] 53/udp                     ALLOW OUT   Anywhere                   (out)
[ 4] 443/tcp                    ALLOW OUT   Anywhere                   (out)
[ 5] 123                        ALLOW OUT   Anywhere                   (out)
[ 6] 22/tcp (v6)                ALLOW IN    Anywhere (v6)             
[ 7] 80/tcp (v6)                ALLOW OUT   Anywhere (v6)              (out)
[ 8] 53/udp (v6)                ALLOW OUT   Anywhere (v6)              (out)
[ 9] 443/tcp (v6)               ALLOW OUT   Anywhere (v6)              (out)
[10] 123 (v6)                   ALLOW OUT   Anywhere (v6)              (out)
Ce qui serait intéressant, c'est de comparer les ports ouverts avec et sans ufw.
Puis faire de la "vraie" sécurité.
- empêcher une connexion root et des comptes de services
- mettre un vrai mot de passe sur l'utilisateur
- fail2ban pour limiter le nombre d'essais possible (attaque brut-force)
- double authentification OTP
- éventuellement blocage via iptables des pays autre que le sien (+ autoriser quelques IP étrangères)
merci jplemoine pour cette todo list 😉

un ouvrage à me conseiller ?
l'idéal serait de pouvoir limiter les entrées/sorties selon le compte utilisateur :rolleyes:
katian a écritl'idéal serait de pouvoir limiter les entrées/sorties selon le compte utilisateur :rolleyes:
Que veux-tu dire par là ?

Il faut que tu te concentre sur la sécurité du(es) service(s) accessibles publiquement plutôt que d'établir des règles de pare-feu qui sont le plus souvent inutiles et donnent juste un faux sentiment de sécurité.

Tu as besoin d'ouvrir un accès SSH.
Qui a besoin de se connecter, avec quel droits, à partir d'où ?
Pour sécuriser SSH il faut utiliser de préférence l’authentification par clé ou si nécessaire des mots de passe très solides. Ensuite tu peux restreindre l'accès à des utilisateurs, des groupes ou des adresses.
Bloquer la connexion pour l'utilisateur root ou changer le port par défaut n'améliorent pas la sécurité.
bruno a écrit[Bloquer la connexion pour l'utilisateur root ou changer le port par défaut n'améliorent pas la sécurité.
Je ne suis pas d'accord : si on autorise le compte root. Le pirate éventuel n'aura que le mot de passe à trouver.
C'est pour ça que j'ai dit qu'il fallait refuser la connexion ssh de l'utilisateur root et des comptes de service (apache, mysql,...)
avec ce genre de chose ?
PermitRootLogin no
et 
AllowUsers <utilisateurs>
jplemoine a écrit
bruno a écrit[Bloquer la connexion pour l'utilisateur root ou changer le port par défaut n'améliorent pas la sécurité.
Je ne suis pas d'accord : si on autorise le compte root. Le pirate éventuel n'aura que le mot de passe à trouver.
Effectivement, une attaque par force brute devra d'abord trouver le nom d'un utilisateur. Cela ralenti l'attaque mais ne la rend pas impossible.
L'authentification par clés rend toute attaque par force brute vaine.
Personnellement je n'autorise que l’authentification par clé pour root : 
PermitRootLogin prohibit-password
L'accès direct en tant que root est nécessaire pour les tâches de déploiement et d'automatisation.

Si tu utilises AllowUsers ou AllowGroups, seuls les utilisateurs indiqués pourront se connecter.
bruno a écritL'accès direct en tant que root est nécessaire pour les tâches de déploiement et d'automatisation.
L'utilisation de PermitRootLogin prohibit-password qui est plus permissive. Donc, sauf besoin explicite on laisse à no
On peut aussi limiter les IP pour lesquelles la connexion est possible.
bruno a écritSi tu utilises AllowUsers ou AllowGroups, seuls les utilisateurs indiqués pourront se connecter.
Attention : les clés directives sont "inclusives" : il y a un ET entre les 2.

Si on a l'utilisateur toto avec le groupe toto et tata.
AllowUsers toto
AllowGroups titi
ne fonctionnera pas, car seul l’utilisateur toto du groupe titi pourra se connecter.

Il est donc conseiller de n'utiliser qu'une seule des 2 directives

Pour root (si échange de clé) 
AllowUsers monutilisateur root@adresseIP
donc je peux créer un groupe 
ssh_group
pour cette utilisation spécifique
AllowGroups ssh_group
réponse très pertinente est celle-ci:
https://forum.ubuntu-fr.org/viewtopic.php?pid=22224891#p22224891

par contre, sur mon ssh, c'est mot de passe carrément désactivé, obligation de clés pour tous les utilisateurs, dans ces conditions, root peut être autorisé directement par ssh sans risques.

pourquoi interdire root ? si le user doit se connecter à root ensuite...? cela ne change rien..
c'est bien d'accorder en effet que certaines taches spécifiques avec sudo, mais tôt ou tard, on es obligé d'être root pour agencer un serveur.

un parefeu ne sert en effet à rien du tout, puisqu'il devra autoriser les ports des services en écoute...il faut plutôt sécuriser ces services, dont leurs mise à jour..
La question subsidiaire de savoir si il faut activer PermitRootLogin ou non est est-ce qu'il est nécessaire de réaliser des opérations nécessitant les accès super-user. Si ce n'est pas le cas, autant limiter l'accès à des comptes voire des groupes limités créés pour ssh.
Si les accès root sont nécessaires, donc PermitRootLogin à yes ou à des comptes admin, l'usage des clés privées/publiques est un plus.
rogn... a écritSi les accès root sont nécessaires, donc PermitRootLogin à yes ou à des comptes admin, l'usage des clés privées/publiques est un plus.
Non ce n'est pas un plus, c'est indispensable pour root. D'abord parce qu'il faudrait choisir un mot de passe très long pour éviter les attaques par force brute (plusieurs centaines par jour sur n'importe quel serveur), ensuite parce que cela permet d’automatiser les tâches de déploiement et de maintenance à distance sans avoir à saisir (ou mettre dans un script) de mot de passe.

  • [supprimé]

  • Message #14
Si vous voulez un serveur SSH sécurisé en passant par internet, il faut impérativement utiliser un système de clé privé/clé publique et UNIQUEMENT un système de clé (cad vous désactivé les mdp traditionnel).
Avec ceci, aucun risque de brute force : un hacker n'aura même pas la possibilité de faire 1 tentative => la connexion sera rejeté dès le départ puisqu'il n'y aura pas la clé correspondante.
dans ce cas si un utilisateur souhaite un accès ssh il doit me fournir sa clé publique ?
TheSun a écritAvec ceci, aucun risque de brute force : un hacker n'aura même pas la possibilité de faire 1 tentative => la connexion sera rejeté dès le départ puisqu'il n'y aura pas la clé correspondante.
si c'est faisable mais en bruteforce bête il faudrait statistiquement faire tourner un processeur par atome de l'univers observable pendant 2 avec 202 zéros derrière fois la durée qui nous sépare du big bang. ou un truc du genre.

katian a écritdans ce cas si un utilisateur souhaite un accès ssh il doit me fournir sa clé publique ?
c'est ce qui est le plus sécurisé, effectivement. mais si tu dois filer des accès à plein de monde, SSH n'est clairement pas le protocole le plus approprié.

dis nous en plus sur ce que tu cherches à faire.
et sinon pareil que les avis précédents : ufw a peu d'intérêt. mieux vaut jeter un œil sur les processus en écoute et ne rien laisser tourner d'inutile.
krodelabestiole a écritdis nous en plus sur ce que tu cherches à faire.
Je cherche d'abord à apprendre ssh et la sécurité pour le reste rien de précis encore