[RESOLU] ssh root sans mot de passe : danger ?

[ernie]

Bonjour,

Pour zrep et automatiser cet outil, il faut activer une liaison ssh root sans mot de passe.

Partout est dit que c'est risqué...

Quelles sont les autres alternatives ?

Si je créés un user Toto avec les mêmes droits que root, est ce une solution ? Sauf si la création des clés public/privé se base sur le groupe et pas le user.

Autre idée: si mon adsl box n'a pas de port ouvert vers le port de ssh, il n'y a plus de risque, non ? Ou un port ouvert quelconque vers un autre port (different de ssh) permet aussi de se connecter en ssh ?

J ai trouver aussi cela:
https://www.debian-fr.org/ssh-autoriser ... 37495.html

Merci par avance de vos conseils,

[velivole18]

Bonsoir,

Ne pas mettre de mot de passe au user root est dangereux du fait que root a tous les droits.
Ne pas mettre de mot de passe à un user "normal" non root est dangereux dans la limite des droits accordés à ce user.
Ne pas mettre de mot de passe à un user n'ayant que très peu de droit, voir pas du tout, n'est en général utile que pour des visiteurs occasionnels ou des services sous-jacents extrêmement ciblés et "encadrés" qui ne peuvent rien faire d'autre que ce pour quoi ils sont faits et donc de ce fait cela est peu dangereux.
Une possibilité est de mettre un mot de passe à un user non root, à qui on interdit d'ouvrir une session et pour lequel les droits sont réduits au strict minimum pour ce qu'il a à faire et pour lequel le mot de passe n'est passé que par script. Cela n'est pas une protection absolue car à qui arrive à lire le script ou le fichier contenant le mot de passe pourra l'utiliser. Mais il n'en reste pas moins qu'il y a une "barrière" supplémentaire qui est de récupérer ce mot de passe.

Je ne dis là que des grands principes sans donner de solution à ton problème précis, mais il est toujours bon d'essayer d'appliquer ces principes au maximum. Maintenant il faut voir dans quel environnement et dans quel contexte se situe le problème. Si par exemple il s'agit de test de veille techno sur des machines perso à la maison isolées du reste, pourquoi dépenser de l'énergie à renforcer la sécurité. Par contre lors d'une mise en production sur des machines reliées à internet avec des données sensibles, il faut changer son fusil d'épaule. En conclusion, toujours adapter le niveau de sécurité au niveau de la menace et à la valeur de ce que l'on cherche à protéger.

Cordialement.

[ernie]

En fait j ai 2 nas, dont un back up. Je souhaite donner acces à ma famille repartie sur le territoire français à owncloud (jail TheBrig ).
Donc le port de ma box va être lié avec l' ip:port d'owncloud.
Cela sera le seul port pour le moment.
Donc normalement aucun risque pour ssh ( me corriger étant noob).

De plus dans un futur moyen terme, j activerai l'accès au web gui du nas à distance (port box relié au port du web gui). Normalement pareil pas de lien avec ssh.

In fine si j ouvre pas le port ssh, l acces ssh Root sans mot de passe sera que sur mon réseau local, dont un poste sera relié à internet sur les ports webgui et owncloud.
L acces ssh sera donc isolé, non ?

[ernie]

up

[sleid]

1°) Changer le port SSH (> 5000)
2°) N'autoriser à travers le parefeu de chaque NAS, pour le port SSH, que l'adresse de l'autre Nas + éventuellement sur chaque NAS l'adresse de votre poste de travail servant à les configurer (ceci suppose que votre poste de configuration ne soit ni en root ou en admin et avec un mdp robuste.
Bien entendu tout ce petit monde est en ip fixe.
En bref du root sans mot de passe (!!!!) demande une bonne dose de courage.