Bonjour;
@vger
Des tutos pour générer des clefs, t’en trouveras plein sur le net; moi je fais ainsi pour générer à la fois une clef privée compatible linux et une autre compatible windows :
login user
sudo apt-get install -y putty-tools ###nécessaire que si l'on veut générer une clef privée pour la connexion depuis un poste sous windows avec putty
mkdir -p ~/.ssh
ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 4096 -N 'ma-passephrase_compliquée_mais_mémorisable'
puttygen ~/.ssh/id_rsa -O private -o ~/.ssh/user.ppk ##saisir 'ma-passephrase_compliquée_mais_mémorisable'.si clef pour windows
cat ~/ssh/id_rsa.pub >> ~/.ssh/authorized_keys
mv ~/.ssh/id_rsa vers ma clef usb par exemple ###Pour me connecter depuis un poste linux...à mettre dans le dossier .ssh de l'user distant devant se connecter (chmod 600); ou via "ssh-copy-id -i ~/.ssh/id_dsa.pub userdist@serveurdist.fr"
mv ~/.ssh/user.ppk vers ma clef usb par exemple ###pour me connecter depuis un poste windows avec putty ou pageant
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Ne garder dans le dossier .ssh que le fichier “authorized_keys” (seul nécessaire),voir id_rsa.pub; mais enlever dans tous les cas “id_rsa” et “user.ppk”, mais les conserver précieusement…ce sont les clefs du sésame; et passer “PasswordAuthentication no” une fois les clefs testées pour chaque user.
A partir de là, ça ne t’apportera rien de réserver l’accès à certaines ip avec des règles iptables ou un “AllowUsers user@ip” …etc…; c’est souvent beaucoup de contraintes pour un bénéfice nul si tu te connectes exclusivement par clef, car pour pouvoir se connecter, il faut disposer à la fois de la clef privée qui a elle toute seule est quasi inviolable et de sa passphrase qui sert de double sécurité pour en protéger son accès…autant dire que tout le reste à côté ce ne sont que des gadgets…
On pense au départ que l’on va se connecter toujours à partir des mêmes ip; mais un jour tu te retrouves chez quelqu’un par exemple, et que tu voudrais lui monter un truc présent sur ton serveur, eh bien, tu te retrouves comme un con, car l’ip de ton collègue ne sera pas acceptée…ça m’est déjà arrivé…ben oui, j’ai testé aussi ce type de gadgets…
J’ai toujours une clef usb avec mes clefs, + un autre exemplaire sur un cloud au cas ou je n’ai pas ma clef usb avec moi: il suffit que je m’y connecte pour récupérer les clefs ssh, et au moins je peux me connecter de n’importe ou, au cas ou ça arrive.
Idem pour fail2ban; à quoi ça sert de bannir une ip qui de toute façon ne pourra pas rentrer ??? suffit de se poser les bonnes questions pour s’en rendre compte de l’inutilité pour le ssh si connexions exclusives par clefs !!!
il y en a qui poussent même la parano à rendre les ip bannies persistantes, en les rechargeant à chaque redémarrage de fail2ban, et au bout de quelques mois se retrouvent avec des milliers d’ip qui sont à charger…bonjour les ressources…pour un bénéfice encore une fois nul!!!
Après, chacun fait ce qu’il veut, mais vaut mieux se poser les bonnes questions sur la réelle utilité de tous ces gadgets, et sur la contre-partie des contraintes qu’ils engendrent.
@PascalHambourg
Pour les ports fermés par défaut…un petit coup ne netstat régulièrement (et surtout après chaque update upgrade ou installation) pour voir si tout est légitime suffit à mes yeux, a chaque fois que je regarde, je ne vois jamais rien de nouveau; et de plus généralement un serveur une fois installé à part les maj, on n’y touche pas beaucoup…et je pense qu’en cas de compromission, de toute façon même si les ports inutilisés sont fermés avec iptables, cette compromission se servira tout simplement d’un ports déjà ouvert sur le serveur, et comme on ne peut pas tous les fermer au risque de ne plus jouir des services, je ne suis pas franchement convaincu…
), et tu connecte comment finalement pour administrer ?