Bonjour,
J’ai souvent besoin de me loguer en root localement avec SFTP.
Question : Si je mets PermitRootLogin à yes et AllowUsers root@iplocale, rien que cela devrait suffire pour empêcher les attaquants venant de l’extérieur de se connecter en root ?
Merci,
Franck
pourquoi sftp et pas ssh?Autoriser une connexion avec root n’est jamais une bonne chose.Si vous avez besoin de vous connecter à distance sous root ,faites le d’abord en user et ensuite passez root.Moi je pense que c’est plus sûr.
C’est pour mettre des vidéos et photos sur un serveur/minidlna.
Ce sont des connexions locales. SFTP le fait bien et comme il est déjà installé alors je fais avec…
Pour quelle raison ? Pourquoi ne pas passer directement par le système de fichiers ?
On est bien d’accord, local = la machine elle-même, comme dans localhost = 127.0.0.1 ?
Si c’est depuis une autre machine, ce n’est pas local.
Je ne vois aucune raison valable de faire cela en root. Ce ne sont pas de fichiers système que seul root peut écrire.
Il y a une alternative à [mono]PermitRootLogin yes[/mono] : [mono]PermitRootLogin without-password[/mono] autorise le login root mais avec une clé, pas par mot de passe.
[quote=“Franck_FR”]C’est pour mettre des vidéos et photos sur un serveur/minidlna.
Ce sont des connexions locales. SFTP le fait bien et comme il est déjà installé alors je fais avec…[/quote]
alors vous pouvez vous connecter sur sftp avec un user autre que root,un user que vous créez pour sftp et vous donnez les bons droits sur le répertoire chrooté de sftp pour que votre user puisse avoir les droits en écriture sur ledit répertoire.
Ou comme le dit Pascal vous pouvez monter le système de fichier distant avec ssh et transférer ainsi vos fichiers
Pardon ? Je n’ai rien dit de tel. J’ai dit que si c’est local sftp ne sert à rien, il suffit de passer directement par le système de fichiers local.
Bonjour,
Par local, je voulais dire réseau local. Désolé pour ce manque de précision.
Sur mon LAN, il y a 2 serveurs et 3 stations. les deux serveurs sont des TV box installées avec Debian wheezy et les stations sont deux vieux PC portables sous Jessie.
Je me connecte en root (localement sur le LAN) à partir de mon PC portable en utilisant Filezilla/SFTP ou dolphin/ssh, assez souvent sur les différentes machines pour faire différentes choses. Comme transférer des fichiers multimédia appartenant à l’utilisateur Franck vers un serveur sous lequel le programme minidlna tourne sous l’utilisateur minidlna. Après la copie, je remets les bons attributs par un simple click droit de la souris. Je copie aussi des sauvegardes système appartenant à root, des sauvegardes de développement appartenant à user1, autre choses appartenant user2…etc. Ce n’est pas pratique si je devais me connecter à chaque fois sous le nom d’un user particulier pour faire des copies ou du ménage. C’est pourquoi je me connecte en root pour pouvoir aller partout.
Je me suis soucié de l’aspect sécurité des connexions ssh venant de l’extérieur puisque permitRootLogin = yes.
C’est pourquoi, j’ai posé la question à la fin de mon premier message qui est :
“Question : Si je mets PermitRootLogin à yes et AllowUsers root@iplocale, rien que cela devrait suffire pour empêcher les attaquants venant de l’extérieur de se connecter en root ?”
J’ai fini par faire le test. J’ai vu que les dizaines voir une centaine de tentatives de connexions, durant ces deux derniers jours, venant des attaquants ont toutes échoué. J’en conclu à priori que PermitRootLogin=yes lorsqu’il est utilisé conjointement avec AllowUsers root@192.168.2.0/29 (c’est mon exemple), empêche toute connexion root venant de l’extérieur. Employé de cette manière, je trouve que “PermitRootLogin=yes” n’est pas dangereux, car tout simplement user root not allowed because not listed in AllowUsers, lorsque la connexion ne vient pas des quelques stations autorisées suivant le masque réseau définit.
Voici un extrait de mes logs concernant le sujet.
==> /var/log/auth.log <==
Feb 28 11:29:55 srv-deb sshd[16510]: User root from 183.3.202.113 not allowed because not listed in AllowUsers
Feb 28 11:29:55 srv-deb sshd[16510]: input_userauth_request: invalid user root [preauth]
Feb 28 11:29:55 srv-deb sshd[16510]: error: Could not get shadow information for NOUSER
Feb 28 11:29:55 srv-deb sshd[16510]: Failed password for invalid user root from 183.3.202.113 port 58646 ssh2
Feb 28 11:29:56 srv-deb sshd[16510]: Failed password for invalid user root from 183.3.202.113 port 58646 ssh2
Feb 28 11:29:56 srv-deb sshd[16510]: Failed password for invalid user root from 183.3.202.113 port 58646 ssh2
Feb 28 11:29:57 srv-deb sshd[16510]: Received disconnect from 183.3.202.113: 11: [preauth]
J’utilise fail2ban pour ralentir les attaquants et pour ne pas charger les logs.
A+,
Franck
Bonsoir,
Pas de commentaires particiliers sur le fait que PermitRootLogin=yes lorsqu’il est utilisé conjointement avec AllowUsers root@adresse IP locale, ne soit pas dangereux du point de vue sécurité concernant les attaquants venant du net ?
A+,
Franck
Je n’utiliserai certainement pas root pour effectuer ce genre de routine, mais plus un utilisateur spécifique faisant parti d’un groupe créer pour l’occasion.
Les connexions s’effectueraient par clé SSH afin de se passer des problème de complexité des mots de passe.
Et je ne compterai pas sur le fait que seule les IP local soit autorisé à se connecter (même si c’est déjà bien plus ‘safe’ ) car le jour ou une machine tombe c’est tous qui est accessible.
Après libre à toi d’adapter ou non ton installation.
Merci,
Je vais créer un utilisateur qui aura les droits suffisants de manière à ce qu’il puisse aller partout. Je passe PermitRootLogin without-password comme l’a conseillé PascalHambourg plus haut.
car le jour ou une machine tombe c’est tous qui est accessible.
Dans la config dont je parle, le démon sshd s’éxecute sur la passerelle, alors si elle tombe on panne il n’y aura plus d’accès à Internet. Donc aucun danger venant de l’extérieur.
A+,
Franck
Je pense que Clochette voulait dire “compromise”. Et il ne parlait pas du serveur SSH mais d’une des machines qui ont le droit de s’y connecter en root.
Tout à fait.
Après la gestion des connexions par clé requiert une certaine rigueur et permet assez facilement de gérer les révocations d’accès etc …