Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Sécuriser VPS en SSH

Orang utan

Bonjour,
je me fais la main sur un VPS (ubuntu serveur 16.04), et j'essaye de le conserver "safe".
Voulant faire ma sauce, je suis parti vers une solution inadaptée :
- mdp de 18 caractères et fail2ban ect...

En lisant à droite à gauche il ressort qu'il vaut mieux interdire l'utilisation de root par SSH (ce qui n'interdit pas l'utilisation fail2ban).

Je vais donc créer un utilisateur, mais après avoir regardé visudo me vient une question :

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Cette utilisateur, je lui mets les privilèges comme pour root, ou bien je le mets dans le groupe admin ou bien sudo ?

leeroyke

Met ton utilisateur dans le groupe sudo, mais sans éditer le fichier sudoers, tu fait simplement

usermod -a -G sudo utilisateur

Ensuite pour SSH, dans le ficher sshd_config tu met la valeur PermitRootLogin à no

PermitRootLogin no

Et tu te connecte a SSH avec ton utilisateur classique.
Pour securiser un peut plus tu peut mettre la valeur AllowUsers suivit te ton nom d'utilisateur

AllowUsers utilisateur

Cela permet que seul l'utilisateur que tu as mit puisse se connecter a SSH
Quand tu as fait cela regarde aussi du cote de la connection par clé.

pires57

Salut,

Regardes plutôt du coté de l'authentification SSH par clé.

Orang utan

Merci pour vos réponses.
Chose curieuse, fail2ban me kick systématiquement lorsque je change le PermitRootLogin de yes à no ou le contraire.

jean-luc5629

Bonsoir,

@Orang utan

Comme dit pires regardes pour une connexion/clefs, tu y gagneras en sécurité, en tout.... que de t'emmerder avec des tas d'artifices censéments sécuritaires glanés à droite et à gauche dans les forums comme "AllowUsers, le fameux port 22 qu'il faut absolument délocaliser sous peine de...(rien du tout finalement, à part réduire les logs, et encore pas avec clefs exclusives), etc...." ,et j'en passe, et tu pourras même te payer le luxe de te connecter en root et de laisser ton "PermitRootLogin à yes ou à without-password"; et une fois tes clefs testées tu bannis tout simplement la connexion par mot de passe :"PasswordAuthentication no".

Saches qu'une clef 2048 n'a encore jamais été craquée et même si demain elle l'était, ce ne serait pas dans un temps raisonnable (10 ans) et sans des puissances disproportionnées tel que la NSA par exemple, alors si t'es parano t'en mets une de 4096

http://security.stackexchange.com/questions/4518/how-to-estimate-the-time-needed-to-crack-rsa-encryption
http://superuser.com/questions/881063/how-long-would-it-take-to-break-a-1024-bit-openpgp-encrypted-email

A toi de voir...

Orang utan

Comment se passe une connexion avec par exemple nemo dans le cas d'une authentification par clef ?

jean-luc5629

Orang utan a écritComment se passe une connexion avec par exemple nemo dans le cas d'une authentification par clef ?

Quelque soit ce que tu désires faire (sftp via filezilla, ssh en console, etc..), ce sera pareil qu'avec une connexion SSH par mot de passe, il n'y a que la méthode d'authentification qui change, mais une fois connecté ça ne change rien....

Nemo...c'est un gestionnaire de fichiers graphique...sur un ordi de bureau: ok mais sur sur un vps ???; à la limite regarde du côté de webmin ou similaire si le côté graphique tu ne peux pas t'en passer.

Un serveur; ça se gère en ligne de commande via la console et en complément en sftp avec un soft comme filezilla à la limite pour envoyer des fichiers vers ton serveur ou en rapatrier ou aussi via rsync en ssh.

Orang utan

Non, nemo est sur mon portable, et quelques fois je me connecte avec lui au serveur, comme je pourrais le faire avec filezilla.
Mais c'est vraiment rare.

pires57

Avec quel compte essayes tu de te connecter quand le PermitRootLogin est à "No"?
Fail2ban ne devrait pas bloquer la connection avec un compte existant .

Orang utan

Avec un compte simple user (qui n'est pas dans le groupe admin ou sudo), ou un autre, PAF ! En zonzon dés que je relance "service ssh restart" après avoir changer le paramètre PermitRootLogin. Mais tout redevient normal une fois le bantime passé.

pires57

Tu as quoi dans les différents fichiers de log?

Orang utan

Je n'ai pas pensé à regarder. A part /var/log/auth.log, quels autres fichiers faut-il vérifier ?
Là c'est un peu raté, je réinstalle souvent...

sinbad83

Orang utan a écritAvec un compte simple user (qui n'est pas dans le groupe admin ou sudo), ou un autre, PAF ! En zonzon dés que je relance "service ssh restart" après avoir changer le paramètre PermitRootLogin. Mais tout redevient normal une fois le bantime passé.

Il me semblait que la commande était

sudo service sshd restart

Orang utan

Pas d'une console root.

sinbad83

Orang utan a écritPas d'une console root.

Je parlais du service sshd.

ps -A|grep ssh
  813 ?        00:00:00 sshd

sinbad83

Orang utan a écritPas d'une console root.

Je parlais du service sshd.

ps -A|grep ssh
  813 ?        00:00:00 sshd

Orang utan

Bon bah epic fail
je lance la commande ssh-keygen
tout ce passe bien, il me dit qu'il a créé les clés dans .ssh
Mais elles n'y sont pas...
Si je relance ssh-keygen, avec le même nom de fichier, il me dit que le fichier existe déjà.
Pourtant impossible de mettre la main dessus.
Elles se trouvent bien normalement dans ~/.ssh non ?

sinbad83

Dans .ssh, il y a le fichier knownhosts qui est chiffré.
Les configurations des clés sont dans le dossier /etc/ssh avec clés publiques et privées.

Orang utan

Je les ai trouvés. Je cherchais partout un répertoire .ssh qui m'aurait échappé, et je m'obstinais dans cette recherche.
Alors qu'une simple recherche sur le nom du fichier m'a donnée la réponse : ils étaient dans mon home... :rolleyes:
Pourtant la commande précise bien qu'ils sont créés dans .ssh ...