La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: Solidus le 15 avril 2020 à 00:39:35
-
Bonswar LaFibre,
Je me suis pris un VPS Ubuntu Bidouille, comme son nom l'indique, c'est pour me familiariser avec Ubuntu.
J'ai donc commencé par suivre quelques tutos de noob pour bien sécuriser sa vm et avoir les bons reflexes et pour pratiquer Ubuntu.
https://docs.ovh.com/fr/vps/conseils-securisation-vps/
1erement, changer le port ssh par défaut, J'ai donc bien changé le port SSH qui est par défaut 22, je reboot mes services, quand je vais dans le fichier de conf (vim /etc/ssh/ssh_config) je vois bien que mon port a été changé, je me déconnecte donc de ma vm, puis je retest toujours en ssh sur le port 22 pour voir si c'est bien bloqué.....Et le problème c'est que j'arrive toujours à me connecter en SSH sur le port 22 alors que sur le fichier de conf je l'ai bien changé.
Idem pour la securisation des droits root
Désactiver l’accès au serveur via l’utilisateur root >> je l'ai fait, mais quand je suis sur ma VM, quand je fais sudo - s >> je passe direct en root, sans demande de mdp ou autre...
Une ame charitable pour m'aider à bien demarrer sr ubuntu, merci beaucoup.
-
Bonsoir Solidus :)
Est-ce bien le fichier /etc/ssh/sshd_config que tu as modifié et non ssh_config comme tu l’as écrit ? Ensuite il te faudra redémarrer le service sshd
Sur quelle version de Ubuntu es-tu ?
Fais également attention si tu as un firewall activé a bien avoir autorisé le nouveau port ;)
-
Hello,
Pour le port SSH, modifie plutôt /etc/ssh/sshd_config, puis un petit service ssh restart. Dans ce même fichier, tu désactives la connexion SSH en root.
Si tu veux désactiver l'accès root sans mot de passe (avec sudo su), il faudra après avoir défini un nouveau mot de passe root (passwd root) supprimer ce fichier : /etc/sudoers.d/<ton user>
-
Bonjour, pas mieux.
...quand je vais dans le fichier de conf (vim /etc/ssh/ssh_config) ...
plutôt sudo nano /etc/ssh/sshd_config (j'utilise nano par habitude, à chacun son truc)
Tu dé-commente la ligne et change le port. Profites en aussi par trouver et changer
#Décommenter et mettre
MaxAuthTries 4
MaxSessions 5
A toi de voir ;)
voir cette page si besoin (http://www.delafond.org/traducmanfr/man/man5/sshd_config.5.html) et celle là (https://doc.ubuntu-fr.org/ssh#configuration_du_serveur_ssh)
Et à ta place je laisserais tombé l'histoire du root pour l'instant et me concentrerai sur les règles du pare feu ainsi que fail2ban. Tu y reviendra lorsque tu aura tout configuré sans erreur.
Perso je commence toujours par un do-release-upgrade pour avoir la dernière version (LTS ou pas, à toi de voir), j'édite le fichier /etc/apt/sources.list afin d'y mettre tous les dépots qui me sont utiles et je passe les paquets backports au même niveau que les autres ( voir https://doc.ubuntu-fr.org/depots#backports)
(la dernière ligne est à ne pas faire sans de bonnes raisons et sans connaitre les bénéfices/risques)
-
Backporter des paquets sans avoir une bonne raison de le faire est plutôt une mauvaise pratique.
-
C'est vrai. Même si j'ai jamais eu de gros soucis. En même temps, mon serveur peut péter demain, il me sert juste pour quelques sauvegarde, me faire la main sur le déploiement de site perso (pas de trafic dessus)... Bref plutôt pour tester des trucs et des services. J'admets que je ne le faisais pas avant mais j'étais sous debian et avait une utilisation communautaire (mumble, bdd, et forum assez fournis par les joueurs).
-
Ton serveur peut péter demain, mais c'est pas forcément la chose à recommander a un débutant justement ;-)
-
C'est vrai , je vais éditer mon message ;)
-
le tuto OVH est un peu obsolete par endroit:
/etc/init.d/ssh restart
De nos jours toutes les grandes distrib Linux sont sous Systemd. Si y'a donc un truc a apprendre de nos jours c'est bien cela. Je vois trop de gens meme en pro faire encore des manips a l'ancienne (cron, init.d, configs aux mauvais endroits, etc).
la version moderne c'est:
systemctl restart sshd(avec sudo si pas root)
qui fonctionnera quasi partout alors que sur pas mal de distrib, init.d n'existe plus du tout.
Scaleway a fait une petite intro a systemd: https://www.scaleway.com/en/docs/learn-systemd-essentials/
-
systemctl restart sshd(avec sudo si pas root)
qui fonctionnera quasi partout alors que sur pas mal de distrib, init.d n'existe plus du tout.
Il est toujours bon de s'adapter aux évolutions, mais ceci dit :
service sshd restart
...fonctionnera assez souvent à la fois sur les anciens et les nouveaux (remappé en systemctl restart).
RHEL-like 6- :
# service sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]
RHEL-like 7+ :
# service sshd restart
Redirecting to /bin/systemctl restart sshd.service
-
Tuto pour supprimer l'utilisateur root :
Étape N°1 : Connecté avec l'utilisateur root crée par OVH, commencez par créer votre utilisateur VOTRE_LOGIN :
sudo adduser VOTRE_LOGIN
sudo usermod -a -G sudo VOTRE_LOGIN
Regarder les groupes dont root :
group
Rajouter ces mêmes groupes à votre utilisateur :
usermod -a -G adm,cdrom,dip,plugdev,lpadmin,sambashare VOTRE_LOGIN
Étape N°2 : Vérifier que tout est OK avant de supprimer root :
Il faut maintenant se déconnecter de root et tester les droit root de l'utilisateur créer (exemple la commande sudo -s doit permettre d'avoir les droits super-utilisateur).
Étape N°3 : Supprimer root :
sudo usermod -L root
pour plus de sécurité, supprimez l'autorisation de se connecter en root depuis ssh :
nano /etc/ssh/sshd_config
Chercher la ligne "PermitRootLogin" et la metre à "no" : PermitRootLogin no
-
[pour plus de sécurité, supprimez l'autorisation de se connecter en root depuis ssh :
Je suis toujours sceptique sur la validité actuelle de cette recommandation en matière de sécurité.
A l'époque des mots de passe limités à 8 caractères, ça pouvait faire sens en étendant le champ des attaques brute-forces (il fallait deviner le nom+le mot de passe au lieu du mot de passe uniquement).
Mais de nos jours, d'un point de vue combinatoire / attaque brute-force, utiliser un user lamba (longueur X caractères)+ mot de passe (N caractères) ne sera pas plus sécurisé que d'allonger le mot de passe root de X caractères.
De ce point de vue, interdire l'accès SSH root ne sécurise guère plus que rallonger le mot de passe root.
(On peux aussi choisir une autre approche et n'autoriser que les connexions par clés SSH).
Après, on peut vouloir interdire l'accès root direct dans une optique de traçabilité des accès root (si on donne l'autorisation sudo à plusieurs utilisateurs), mais c'est une autre problématique plus liée à l'audit qu'à la sécurisation.
-
Il est toujours bon de s'adapter aux évolutions, mais ceci dit :
service sshd restart
...fonctionnera assez souvent à la fois sur les anciens et les nouveaux (remappé en systemctl restart).
oui mais par exemple ni service ni init.d n'existe sur Arch Linux.
Ces remapping sont la pour la rétro-compatibilité de certains scripts et logiciels. Je ne recommanderais a un débutant de les utiliser.
-
oui mais par exemple ni service ni init.d n'existe sur Arch Linux.
Ces remapping sont la pour la rétro-compatibilité de certains scripts et logiciels. Je ne recommanderais a un débutant de les utiliser.
"assez souvent" ne veut pas dire partout.
Quelle que soit la commande que tu donnes, il y aura toujours des contre-exemple : il existe aussi des distributions Linux sans systemd, où la commande systemctl ne fonctionnera pas non plus.
-
Quelle que soit la commande que tu donnes, il y aura toujours des contre-exemple : il existe aussi des distributions Linux sans systemd, où la commande systemctl ne fonctionnera pas non plus.
Slackware Linux :D
-
Pas mal de réponse, merci beaucoups
Je suis sous Ubuntu 18.04.4
Je vous confirme que je suis bien dans /etc/ssh/sshd_config
Je fais donc un vim /etc/ssh/sshd_config
(https://pix.milkywan.fr/I1mWpUKS.PNG)
i pour inserer, je change le port 22 par mon port, je fais :wq pour save et quitter
Puis je reboot le service comme préconisé
sudo /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.
Mais toujours pareil, je peux me co en SSH via le port par défaut...
-
Oula, supprimer root, quelle étrange idée, on va ptet éviter, surtout que chez MilkyWan (coucou c'est une vm chez nous) le login pass root est déjà désactivé.
sinon "service sshd restart" plutot ?
-
Je verrais plus tard pour desactiver l'user root, là déja je veux comprendre pourquoi j'arrive tjr à me co sur le port 22.
Concernant le root, c'est pas sécure apparement de laisser un compte root si j'ai bien compris ?
-
Oula, supprimer root, quelle étrange idée, on va ptet éviter, surtout que chez MilkyWan (coucou c'est une vm chez nous) le login pass root est déjà désactivé.
sinon "service sshd restart" plutot ?
Coucou
Voilà
service sshd restart
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'ssh.service'.
On me demande le mdp root...
J'ai testé sudo service sshd restart, la commande est bien passée, mais aucune confirmation, comme si je faisais juste entrée sur le clavier, et je passe à la ligne du dessous (ché pas si je suis clair)
-
c'est bien sudo service qu'il fallait faire, c'est normal de ne pas avoir de confirmation.
Mais sinon, tu as commenté la ligne du port (le petit # devant) donc le paramètre est inactif, sshd utilise le paramètre par défaut, donc le port 22.
(sinon changer le port ça ne sert a rien, la vraie sécurité c'est de faire de l'auth par clé et d'interdire les accès par mdp)
-
c'est bien sudo service qu'il fallait faire, c'est normal de ne pas avoir de confirmation.
Mais sinon, tu as commenté la ligne du port (le petit # devant) donc le paramètre est inactif, sshd utilise le paramètre par défaut, donc le port 22.
Okay ! le # permet de mettre des commentaires effectivement, et dans des codes en general, au temps pour moi
Donc j'ai changé le mauvais paramètre, merci, je check ca et je vous fais un retour.
Oui changer de port ne change pas grand chose mais je veux déja manipuler, ensuite je ferais une auth par clé oui
-
Est-ce que je peux, sur mon VPS Ubuntu, avoir une Vm pour pouvoir utiliser un OS classique (Windows) ou pas ?
Distinct de mon réseau Lan bien sur, c'est l’intérêt. C'est pour du teletravail en fait que je demande
-
Je vous explique;
j'utilise mon pc perso pour le télétravail et je suis CO en vpn de l'entreprise.
Je souhaite donc pouvoir passer sous les radars du vpn entreprise. Je peux utiliser une vm depuis mon vps ou pas ? Est ce que c'est clair ou pas ? Merci
Car je veux séparer le coté "taff" du coté "privée" de ma machine.
-
Ca dépend de plusieurs choses. Je crois que @Hugues utilise Proxmox, donc:
- Ton VPS c'est un container LXC ou une VM QEMU ?
- Si c'est une VM QEMU, est-ce que Nested KVM est activé dans proxmox ? (par défaut ce n'est pas le cas)
Pour faire tourner une VM dans ton VPS, il faut ce celui-ci soit une VM QEMU et que Nested KVM soit activé.