[sweazzy]

Merci beaucoup pour toutes ces infos !

[SD90078-OVH]

[HS] il y a aussi parfois (souvent ces derniers temps) besoin de rebooter pour prendre en compte de nouvelles librairies (la glibc il y a un mois par ex) [/HS]

[nowwhat]

Si tu souhaite installer fail2ban uniquement pour protéger ta porte "22", épargne-toi tes efforts, et focus sur l’application d'une authentification par clés publique/privé.
Quand c'est la sécurité que tu cherche, c'est ça, la route à suivre.

Un tuto qui va t'expliquer le manip à suivre est dispo ici http://forum.kimsufi.com/showthread....ans-le-manager
Là, t'aura quelque chose de bien.

En suite, il est sympa de s’amuser avec fail2ban, j'adore, car il me fabrique des jolie stats comme : http://www.test-domaine.fr/munin/pap.../fail2ban.html

Explication - bonus:
Ton sujet "Problème connexion SSH après reboot" est erroné
Il te manque une astuce !
La méthode est:
Ouvre une session (fenêtre) SSH vers ton serveur - nous le nommons "session-1".
Ouvre une session (fenêtre) SSH vers ton serveur - nous le nommons "session-2".

Dans session-1, trafique un max avec i.e. /etc/ssh/sshd_config
Pense à ajouter ceci:

LogLevel INFO

Puis, redémarre le service ssh:
service ssh restart
Ne ferme SURTOUT pas session-1 - garde session-2 comme réserve - exécute dans session-2 éventuellement ceci:
tail -f /var/log/auth.log - extrêmement utile pour voir ce qui se passe.

Ouvre une nouvelle (troisième !) session, avec les nouvelles paramètres (nouveau mot de passe, nouvelle porte ou autre truc à la ouf).
Ça passe ? Tu entre ? Ok, t'es bon.
Ça ne passe pas, no soucis, t'as session-1 encore ouvrir pour retenter les edits, modification, revenir en arrière.

Redémarrer un serveur, ça se fait rarement (deux, trois fois par an ? moins !?
( Mon serveur http://www.test-domaine.fr/munin/pap...rg/uptime.html == 11 fois depuis 12 mois, mais sache que je dev au niveau kernel (noyau), je n'ai donc pas le choix )

[sweazzy]

Je vous remercie pour ses explications.

Vous me recommandez donc de laisser mon SSH sur le port 22 et de configurer comme il faut un fail2ban ?

[nowwhat]

+1
@janus57: merci pour cette explication.

[janus57]

Bonjour,

à propos du port SSH sur le 22 vous devriez lire ça : https://www.adayinthelifeof.nl/2012/...2-is-bad-idea/

Ce qu'il faut principalement retenir :

But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE. You have no way of knowing if you are talking to the real SSH server or not. This reason, and this reason alone makes it that you should NEVER EVER use a non-privileged port for running your SSH server.

Je vous laisse faire la traduction et voir l’article en entier, en gros y a potentiellement plus de risquer à mettre SSH sur un port supérieur à 1024 que de le laisser sur le 22 et de mettre un fail2ban, snort ou tout autre logiciel derrière.

Cordialement, janus57

[nicobilaine]

Changer le port ne sert à rien, il faut mettre en place un système de clé SSH, qui est le moyen le plus sécurisé actuellement, et désactiver la connexion par mot de passe.
Le serveur est bien démarré? (ping, serveur web, ...)
Pour pouvoir faire des modifications, il faut passer en mode rescue, monter les partitions et modifier le fichier de configuration.

[nowwhat]

....
Pouvez-vous m'éclairer à ce sujet ?

Bien sur.
Sache que nous savons encore moins que toi : c'est toi qui a édité ton /etc/ssh/sshd_config pour modifier quelques paramètres du serveur sshd.
Il est probable que tu te trompé d'un espace, point, ou autre truc très petit, mais ça ne pardonne pas. Le serveur sshd plante => toi plus accès.

Mais, heureusement, c'est un soucis très banal, ainsi que la solution.

Ce qui va te sauver, c'est la manip qui est encore plus important que "la sauvegarde" : je te présente le mode rescue de ton serveur.
Regarde ici http://forum.kimsufi.com/forumdispla...w-To-Tutoriels (tous indispensable) : dernier article: [TUTO] Mode rescue.
PS: changer la porte SSH, ça le fait pour que tu te protège contre les tentatives discutables de mon fils (il a 8 an), mais pour les autres, ça n'ajoute pas vraiment un barrière de sécurité.
Un truc valable avec les portes est le système port knocking.

Mieux encore: le top ultra nec, en vogue depuis les années '80 (ils n'ont pas trouvé mieux depuis) : VIRE le mot de passe SSH.
Ajoute des clés publiques ......., et le problème est réglé.
L'accès par mot de passe est uniquement activé par OVH/KS pour que tu prends possession de ton serveur. Change la méthode d'accès dès que tu peux.

[sweazzy]

Bonjour,

Suite au configuration effectué sur mon serveur (changement du port SSH, autorisation de connexion pour un unique groupe que j'ai nommé "sshusers"), bref les pré-requis de sécurité pour un serveur.

Cependant, après reboot il m'est impossible de prendre la main sur mon serveur.

J'ai un refus de connexion que ce soit sur le port par défaut 22 ou bien le port que j'ai configuré.

Avant de reboot, j'ai juste redémarrer le service SSH et tester la fonctionnalité de la config qui est ok.

Pouvez-vous m'éclairer à ce sujet ?

Je suis sur un KS2 avec Fedora Core 21 Server.