Hop hop hop,
je profite très rapidement de l'ouverture de cette séction "sécurité"
pour vous soumettre une petite question:
Sur mon réseau local, placé derrière IPCOP,
j'autorise les connexions ssh, mais en raison des trop nombreuses attaques "au dictionnaire" dont j'était victime
(vous êtes tous déja probablement passé par les logs de sécurité interminables ...),
j'ai choisi de restreindre encore les accès en mettant en place l'authentification par clef publique/privée,
bloquant toute connection externe de machine n'appartenant pas (pour expimer les choses simplement)
à mon "carnet d'adresse",
la liste des machines autorisées et leur clef publique d'authentifiaction,
étant inscrit dans /etc/ssh_known_hosts ...
ce point d'interprétation (personnel) est il correct ?
Cette dernière mesure, certe beaucoup plus restrictive (trop diront certains) est également de loin bien plus éfficace.
Mais malgré une diminution considérable de la taille de mes logs de sécurité,
je récupère toujours quelques attaques, c'est à dire des tentatives de connection et test de loggin
qui échouent pour password incorrect, or je supposait sans faire partit de mon "carnet d'adresse"
il était même impossible de pouvoir entrer un mot de passe la connection étant immédiatement rejeté.
De plus à ma surprise j'ai constaté pouvoir me logger
sans soucis d'une machine n'appartenant pas à mon "carnet d'addresse" ...
l'un de vous pourrait-il m'aiguiller sur les voix impénétrable de la sshagesse ...
Je ne joue jamais avec les "host keys", mais y'a pas un truc a activer dans la conf du daemon pour devenir restrictif ? T'as songe au firewall sinon ? :p
Sinon une solution simple et très rapide.
tu change le port ssh ( ex : 8080 ou autres) tout simplement 🙂
1) Pas de problème avec le firewall le port 22 est redirigé c'est tout,
2) Pas de problème avec la config de sshd, je l'ai modifié et j'ai relancé sshd.

3) Le cas de figure serai identique si je changeait de port 22 -> ????
en effet il faudrait rediriger ce port depuis mon firewall
et comme de bien entendu les personnes qui essayent de se connecter ne testent pas que le port 22 ...
certe j'aurai probablement encore moins d'attaques ...
Bonjour,

dans /etc/ssh/sshd_config
PasswordAuthentication no

Résultat ?
Slookeur a écrit:
la liste des machines autorisées et leur clef publique d'authentifiaction,
étant inscrit dans /etc/ssh_known_hosts ...
ce point d'interprétation (personnel) est il correct ?
Je crois qu'il s'agit du fichier ~/.ssh/known_hosts créé dans le home de chaque utilisateur appelé à se connecter.
Slookeur a écrit:
1) Pas de problème avec le firewall le port 22 est redirigé c'est tout,
2) Pas de problème avec la config de sshd, je l'ai modifié et j'ai relancé sshd.

3) Le cas de figure serai identique si je changeait de port 22 -> ????
en effet il faudrait rediriger ce port depuis mon firewall
et comme de bien entendu les personnes qui essayent de se connecter ne testent pas que le port 22 ...
certe j'aurai probablement encore moins d'attaques ...
En gébéral ces tentatives de brute ssh se font via des logiciels qui test le port 22 et qui balance le dictionnaire, en changeant de port cela suffit parfois à éliminer ces genre de tentative.

ps : tu te trompe sur l'utilité du fichier ~/.ssh/known_hosts
Un grand merci Tapioca !!
Il faut effectivement modifier l'option "PasswordAuthentication yes" en "PasswordAuthentication no"
si on laisse "yes" en fait cela maintient la possiblité de s'indentifier par password donc de façon classique.
En mettant "no" je n'accepte plus que les authentifications par clefs.
D'autre part toi aussi TitaX, m'as aidé, en effet les clefs publiques ne doivent pas être placées
dans "~/.ssh/known_hosts", mais dans "~/.ssh/authorized_keys"

Toutes ces informations impliquent que la baisse de la taille de mes logs était jusqu'a maintenant due au hasard.
Puisse-que les connexion par password restaient activées ...
Enfin là cela va fonctionner correctement.

Merci à tout deux.
Je trouve que les pages man ssh_config et sshd_config sont particulièrement difficiles d'accès : il faut vraiment s'accrocher pour faire la part des choses.
C'est dommage pour un sujet aussi sensible.
Je partage entièrement ton point de vue,
et je trouve également cela bien regrétable,
mettre en place un protocole de communication sécurisé,
quelque en soit l'utilité personnelle ou professionnelle,
demande une maîtrise et une compréhension approfondie de ce
protocole ce qui n'est pas permis par les pages de manuels
ssh et sshd ...