Synology Accès SSH sans être admin

[Freeman5962]

Bonjour,

Je sais que ça fait longtemps que les Synology refusent les accès SSH aux comptes non administrateurs.
Je souhaite passer au delà de cette interdiction (c'est mon NAS, je fais ce que je veux ;p ).
Mon besoin précis : Je souhaite avoir un utilisateur qui ne fait QUE du SSH ET qui ne doit PAS être administrateur.

J'ai une idée :

- Je crée un compte utilisateur que je met dans le groupe Administrateurs (pour l'instant).
- Dans la configuration de l'utilisateur, je refuse explicitement son accès à toutes les ressources et applications.

Pour l'instant ça fonctionne : Mon "NouveauCompte" a un accès SSH MAIS ne parvient pas se connecter à DSM, ni aucune application, ni même le partage Samba : Très BON début !

Sauf que depuis SSH en tant que Administrateur, ce nouveau compte peut lancer un "sudo -i" et avoir accès à tout !

Je regarde le contenu du fichier /etc/passwd :
nouveaucompte:1002:100::/var/services/homes/nouveaucompte:/bin/sh
Il a bien un paramétrage d'accès à "/bin/sh" (NORMAL).

Je regarde le contenu du fichier /etc/group:
administrators:x:101:xxx,nouveaucompte
Il est bien dans le groupe "administrators:" (Jusque là, NORMAL).

Mon idée est la suivante :
Si je retire manuellement de cette ligne /etc/group, mon compte "NouveauCompte".
Mais je ne touche pas à /etc/passwd.

Résultat théorique :​

Mon "NouveauCompte" n'est plus administrateur par contre, il conserve les droits d'accès à la console via SSH.

Votre avis ?
Je suis conscient que ce sont des mises à jour manuelles, probablement non supportées par Synology mais...
Qu'en pense les plus expérimentés d'entre-vous ?
Y a-t-il un risque ?
Y a-t-il une limite ?
Est-ce une bonne idée ?

Merci beaucoup !

 

[cooper]

Si le but de la manœuvre est d'interdire à <nouveaucompte> d'utiliser sudo(8), alors il faut paramétrer une interdiction au niveau de sudo(8) (les versions d'openssh de Synology obligent les utilisateurs se connectant via ssh(1) qu'ils fassent partie du groupe "administrators").

Dans un shell root sur ton Nas, créer un fichier (le nom importe peu) dans /etc/sudoers.d/ (par exemple : /etc/sudoers/01_<nom_utilisateur>) avec le contenu suivant :

nom_utilisateur ALL=(ALL) !ALL

Cela empêchera <nom_utilisateur> d'utiliser sudo(8)

 

[Freeman5962]

Bonsoir Cooper,

Je n'avais pas imaginé cela possible mais cela répond très bien à mon besoin et... ça marche ! MERCI !
Sorry, user XXX is not allowed to execute '/bin/ash' as root on SYNOLOGY.
J'ai cru au début qu'il fallait redémarrer un service car ça n'avais pas marché instantanément (je parvenais encore à me loguer en root).

J'en profite pour aller plus loin dans ma demande si tu le permets
Comme expliqué, je n'avais pas besoin d'un compte administrateur. J'ai créé un admin uniquement pour le besoin d'accès au shell.

Ne serait-il pas possible de créer un simple utilisateur avec un accès SH ? (qui m'éviterait cette astuce que tu viens de me donner).
Je ne sais pas si on peux rajouter à la mano dans etc/passwd et si cela peut créer un clonflit avec le Synology.... ?

Encore merci à toi.

 

[cooper]

Bonsoir Cooper,

Hello @Freeman5962,

J'en profite pour aller plus loin dans ma demande si tu le permets
Comme expliqué, je n'avais pas besoin d'un compte administrateur. J'ai créé un admin uniquement pour le besoin d'accès au shell.

Ne serait-il pas possible de créer un simple utilisateur avec un accès SH ? (qui m'éviterait cette astuce que tu viens de me donner).
Je ne sais pas si on peux rajouter à la mano dans etc/passwd et si cela peut créer un clonflit avec le Synology.... ?

Encore merci à toi.

A moins de mettre le nez dans les modules PAM avec le risque que les modifications soient supprimées avec une mise à jour de DSM, pas de grande chance de faire ça simplement.

Certains se sont lancés dans l'aventure de compiler et d'installer openssh (qui inclus sshd) mais c'est fastidieux.

Une autre solution qui est possible sur des openssh de base qui ne sont pas modifiés comme celui de Synlogy, c'est la directive "AllowGroups" qui permet de spécifiquer quel(s) groupe(s) est/sont autorisé(s) à se connecter via ssh (sous couvert que l'utilisateur ait un shell de connexion défini et utilisable dans la base des utilisateurs) mais je n'ai pas testé cette option.

Si tu ne veux pas te lancer dans ces modifications, assures-toi d'enlever avec chmod(1) les permissions (ou via les bordéliques et inutiles ACLs avec synoacltool) unix sur les répertoires à interdire à/aux utilisateur(s) se connectant via ssh.

 

[Freeman5962]

Hello Cooper,

Ok, je ne vais pas me risquer d'aller dans des configurations aussi avancé pour un avantage assez faible...

Est-ce que l'on peut conclure que mon nouvel utilisateur qui est pourtant dans le groupe Admin à qui j'interdit tout (Permissions & applications) y compris le sudo -i, n'est finalement qu'un utilisateur parmi d'autres ?


Autrement dit, est-ce que le groupe Admin lui confère d'autres droits auxquels je n'ai pas encore pensé ?

 

[cooper]

Hello Cooper,

Ok, je ne vais pas me risquer d'aller dans des configurations aussi avancé pour un avantage assez faible...

C'est clair, cela reviendrait à utiliser un marteau sur une punaise

Est-ce que l'on peut conclure que mon nouvel utilisateur qui est pourtant dans le groupe Admin à qui j'interdit tout (Permissions & applications) y compris le sudo -i, n'est finalement qu'un utilisateur parmi d'autres ?

En empêchant cet utilisateur d'utiliser sudo(8), tu es certain qu'il ne pourra pas se balader dans la hiérarchie où il n'est pas autorisé ou lancer des commandes impactant tout le système.

Autrement dit, est-ce que le groupe Admin lui confère d'autres droits auxquels je n'ai pas encore pensé ?

De part ses groupes d'appartenance, il aura accès aux dossiers/fichiers (et sous-dossiers) si un de ses groupes a ces permissions.

Ensuite il faut également veiller à ce que des ACLs ne lui permettent pas d'accéder à des ressources interdites (raison pour laquelle je conchie les ACLs qui n'apportent rien de plus à mon avis comparativement à la gestion classique des droits Unix) si ce n'est une complexité ajoutée et superflue sur de petites infrastructures.

Le problème avec la modification des permissions depuis DSM est qu'elle modifie les permissions Unix (en collant joyeusement un 0777) et règle les permissions uniquement au niveau des ACLs. Pour le vieux schnouk que je suis en utilisant des Unices depuis plus de 30 ans, c'est inique et complètement stupide si par exemple on exporte des partages NFS en "squashant" mal le mapping uid local.