Personnellement, je ne vois pas l’intérêt à part ajouter un risque sécurité. Chimrod a raison d’être prudent. D’autant plus que si je comprends bien le programme, il laisse des connexions ouvertes.
Pour sécuriser mes démons ssh je fais :
changement de port
liste très resteinte d’utilisateur autorisé à se connecter (1 voir 2)
certificat
Avec ça on est déjà à l’abri de pas mal de choses.
Et si on veut aller plus loin, on ajoute du port knocking pour eviter les vulnérabilités liés au démon ssh lui-même.
Je comprend le principe, mais avant de laisser tourner un service sur le port 22, je préfère qu’il soit audité avant ! Aujourd’hui il est tellement facile de glisser une faille exploitable dans un code C, j’assume clairement être incapable de savoir si parmi les 800 lignes de code, il n’y a pas une porte ouverte !
Personnellement, je ne vois pas l’intérêt à part ajouter un risque sécurité. Chimrod a raison d’être prudent. D’autant plus que si je comprends bien le programme, il laisse des connexions ouvertes.
Pour sécuriser mes démons ssh je fais :
Avec ça on est déjà à l’abri de pas mal de choses.
Et si on veut aller plus loin, on ajoute du port knocking pour eviter les vulnérabilités liés au démon ssh lui-même.
Je comprend le principe, mais avant de laisser tourner un service sur le port 22, je préfère qu’il soit audité avant ! Aujourd’hui il est tellement facile de glisser une faille exploitable dans un code C, j’assume clairement être incapable de savoir si parmi les 800 lignes de code, il n’y a pas une porte ouverte !