J'ai 2 serveurs, A et B. J'ai le serveur A qui est en production et le serveur B qui a pour objectif de synchroniser les dossiers du serveur A.
Pour ce faire, j'utilise rsync en connexion ssh. Cependant je remarque quelque chose d'embêtant l'utilisateur rsync n'est pas isolé.
Je souhaiterai savoir s'il était possible de configurer cette utilisateur pour l'autoriser à se connecter en ssh seulement pour pouvoir exécuter la commande rsync ?
je ne sais pas exactement. Une piste peut-être : $username/.ssh/ssh_config dans lequel tu définis la machine cible (Host), et la commande distante (RemoteCommand).
cf. man ssh_config
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
J'ai effectivement fait quelques recherches vers cette solution, mais elle semble n'être utilisé pour n'autoriser que le sftp - d'après ma compréhension (qui peut être fausse), pour faire mon rsync j'utilise le protocole ssh, et pour ce faire, il faut que j'autorise mon utilisateur à utiliser ssh et pas seulement le sftp, et si j'autorise le ssh, il a accès au terminal..? Sinon je n'ai pas bien compris comment configuré le chroot dans le fichier de configuration ssh
hmm, j'ai pris le problème à l'air, on dirait : ce que je suggère exécute une commande (je pensais à rsync en guise de RemoteCommand) sur l'hôte distant lors de l'invocation de la commande ssh.
mais, est-ce que, si, à la place de rsync, on met un simple exit, la connexion sera immédiatement interrompu, et alors la commande rsync (via ssh) continuera de fonctionner ?
- Edité par dantonq 23 décembre 2020 à 14:35:42
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
tout en l'empêchant de pouvoir avoir accès à un terminal ou à un profil utilisateur - le même concept que les utilisateurs sftp sauf qu'au lieu de faire du sftp on fait un rsync... Je ne sais pas si je suis clair ???
Je suis passé en mode expérimental, j'ai alors essayé des tas de choses wtf qui n'ont bien évidemment pas fonctionné, pour la culture voici la liste des essais que j'ai tentés :
- Tenté d'obliger l'utilisateur à ne pouvoir se connecter seulement sur un port différent de celui paramétrer pour ssh (dans l'objectif de le filtrer avec le pare-feu et d'autoriser cet utilisateur seulement depuis l'interface LAN)
- Tenté de faire exécuter un script de commande à l'utilisateur via l'option "ForceCommande" dans la config du SSH (semi fonctionné, je n'ai peut-être pas assez approfondit cette piste)
- Tenté de faire exécuter un script de commande via le sftp
- Tenté de dire à rsync d'utiliser le protocole sftp
- Tenté de dire à ssh qu'rsync était un subsystem et d'obliger l'utilisateur à utiliser la commande "rsync"
Bon, j'ai pas répondu à ma problématique, la communauté non plus d'ailleurs, mais au cas où quelqu'un tombe sur le même questionnement :
J'ai une connexion VPN entre mes deux serveurs, j'ai donc fait un script où root :
1/ sauvegarde le dossier en archive,
2/ c/p le dossier dans le répertoire utilisateur,
3/ donne les droits sur l'archive à l'utilisateur,
4/ l'utilisateur fait un scp fait le serveur cible
5/ 2eme script où root c/p l'archive dans le dossier cible
6/ décompresse l'archive dans le dossier cible
7/ redonne les droits à l'utilisateur du dossier cible
Bon c'est vraiment pas la best solution ever, en terme de sécu on a vu mieux, après le script n'est pas exécutable par l'utilisateur - cependant ça reste une tâche automatisée, si l'utilisateur se fait pété il peut potentiellement altérer les données du backup avant de l'envoyer sur le deuxième serveur, mais bon même là on laisse qu'un droit de lecture et ça devrait pas trop poser de soucis, après on oublie pas le petit calcul risque et chance que le serveur soit attaqué et que cette faille soit exploitée et bien-évidemment, l'étendu de cette faille, on se rend compte qu'il y a toujours des backups et qu'il est peu probable qu'on m'en veuille au point de tout cassé chez moi (puis il faut arriver jusqu'à l'utilisateur aussi) - même si certains pourrait voir ça comme une provocation j'ai quand même mentis sur 2/3 points stratégiques pour vous compliquer la tâche.
Rsync offre la possibilité d'être un démon: https://download.samba.org/pub/rsync/rsyncd.conf.5. Le problème avec ça je crois, c'est que ça ne permet pas de chiffrer les données directement (ce que règle ta connexion VPN).
J'entends la solution, cependant mes serveurs sont géographiquement à 2 endroits différents, du coup, il ne peut pas y avoir de communication non sécurisé entre les deux équipements. Or sur la solution proposé, la communication n'est pas chiffré si j'ai bien compris ?
Je souhaiterai savoir s'il était possible de configurer cette utilisateur pour l'autoriser à se connecter en ssh seulement pour pouvoir exécuter la commande rsync ?
Ou alors, faut répondre à la problématique initiale, étaler mon infra et mes mesures de sécurités au milieu de l'internet n'est pas une action très recommandé dans ma politique de sécurité.
J'ai 2 serveurs, A et B. J'ai le serveur A qui est en production et le serveur B qui a pour objectif de synchroniser les dossiers du serveur A.
Pour ce faire, j'utilise rsync en connexion ssh. Cependant je remarque quelque chose d'embêtant l'utilisateur rsync n'est pas isolé.
Je souhaiterai savoir s'il était possible de configurer cette utilisateur pour l'autoriser à se connecter en ssh seulement pour pouvoir exécuter la commande rsync ?
Je vais être méprisant jusqu'au bout, et faire ce que je pensais qu'un «white hat» proactif avait fait avant d'avoir posté, ou au moins fait pendant ce mois et demi:
man sshd:
command="command"
Specifies that the command is executed whenever this key is used for authentication. The command
supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty;
otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a
pty or should specify no-pty. A quote may be included in the command by quoting it with a back‐
slash.
This option might be useful to restrict certain public keys to perform just a specific operation.
An example might be a key that permits remote backups but nothing else. Note that the client may
specify TCP and/or X11 forwarding unless they are explicitly prohibited, e.g. using the restrict key
option.
The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment
variable. Note that this option applies to shell, command or subsystem execution. Also note that
this command may be superseded by a sshd_config(5) ForceCommand directive.
If a command is specified and a forced-command is embedded in a certificate used for authentication,
then the certificate will be accepted only if the two commands are identical.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique