Ok, merci. Mais cela ne résoud pas mon problème concernant le scp. J'ai bien trouvé un paramètre à configurer, subsytem, dans sshd_config, mais je ne sais pas comment l'utiliser en fait...
>> On ne veut pas que quelqu'un sur B puisse faire un ssh sur A => Soit tu ne met pas de ssh sur A soit tu met un serveur ssh sur A mais tu bloques le port en provenance de B
Le mieux c'est de bloquer la sortie directement de données sur le port 22 à partir de B, non?
J'ai établi quelques règles de pare-feu pour sécuriser ce cas. Les voici:
- laisser entrer depuis A vers B par le port 22
- autoriser uniquement les sorties de B par le port 22
- interdire toute les sorties depuis B
En fait je garde l'entrée et la sortie sur le port 22 pour permettre au tunnel SSH de fonctionner, c'est impératif non?
Si vous ne voulez pas que les utilisateurs transfèrent des fichiers depuis et vers le serveur ssh, vous devez restreindre l'accès au sftp-server et l'accès scp. Vous pouvez restreindre sftp-server en configurant le bon Subsystem dans /etc/ssh/sshd_config. Cependant, pour restreindre l'accès scp, vous devez :
* soit interdire les connexions d'utilisateurs au serveur ssh (comme décrit ci-dessus par le fichier de configuration ou par la configuration PAM),
* soit ne pas donner de shells valides aux utilisateurs qui ne sont pas autorisés à faire des transferts sécurités. Cependant, les shells fournis devraient être des programmes qui justifieraient la connexion au serveur ssh par eux-même, comme des programmes de menus (ala BBS). Sinon, l'option précédente est préférée."
-> Pour bloquer le sftp, je paramètre /etc/sshd_config avec:
Subsystem sftp /path/vers/autre/chose/que/sftp-server
la question est: vers quel programme?
-> par contre pour scp... Dur dur... sauf en interdisant le ssh de B vers A, en indiquant à sshd_config de A un port différent de 22. Ainsi, en bloquant toute sortie autre que par le port 22 depuis B, ça devrait le faire, vu que le client ne peut se connecter que sur le port que lui donne le serveur.
Non?
Ok, merci.
Maintenant une autre colle.
J'ai une 2 stations A & B. Sur les deux est installé SSH. Ainsi, elles sont potentiellement client et serveur SSH. Je veux autoriser la connexion de A à B avec l'export du display. Mais je ne veux pas que lorsqu'un user se loggue en SSH sur la machine B, il puisse ensuite faire un SSH vers A. En fait je ne veux pas qu'il puisse faire de scp de données de B vers A.
Alors selon ce que j'ai compris, je paramètre comme suit:
- machine A, côté client: forwardX11, compression et port
- machine A, côté serveur: je désactive le forwardX11, et je choisi un port
- machine B, côté serveur: x11forwarding, x11display et port
- machine B, côté client: je désactive forwardX11 et je choisi un port autre que pour A serveur.
maintenant, est-ce suffisant? J'ai lu que la priorité dans la prise en compte des options est donnée à la ligne de commande. Donc quelqu'un qui arrive à trouver le port pourra toujours se connecter de B vers A en saisissant -p XXX comme argument, non?
Comment puis-je être sûr de ne pas avoir ce cas de figure, empêchant ainsi les copies distantes?
Oui, mais c'est déjà pas mal. Le serveur X, c'est mon Xorg, c'est ça?
Donc en gros, j'ai un tunnel qui empeche les gens de voir au ce qui passe dedans, et dans ce tunnel, j'ai tout ce que je fais qui passe, n'est-ce pas?
Donc, c'est quand même good ça, niveau sécu, non?
Ok, ok, merci à tous pour vos explications.
Mais alors, la sécurité elle est ou là-dedeans?
- Qu'est ce qui est crypté quand je travaille sur Nedit par SSH?
- Qui c'est qu'est dans le tunnel :? ?
merci mais mon but n'est pas d'avoir un système neuf à chaque démarrage. Je souhaite que le système charge les dossiers /etc, /var et cie que j'aurais sauvegardé sur une autre machine.
Faisable ou non? Et quels risques pour le système?
-----> je n'ai que des petites config, donc elle ne supporteront pas la VM à mon avis
-----> j'ai pas vraiment le temps de me pencher sur la découverte de Xen, VMWare et Cie, je suis aussi étudiant dans cette école :P
-----> je pense que rajouter dans une solution de virtualisation que je ne maitrise pas la gestion des authentifications par le NIS, ainsi que les problèmes que je pourrais rencontrer au niveau des interfaces réseau pour avoir un lien toujours présent avec les serveurs de gestion, ça fait beaucoup pour un petit homme comme moi xD
mais si j'avais le temps, j'aurais bien poussé cette solution qui m'aurait permis au passage d'accéder à la connaissance des systèmes virtualisés.
Ok, merci pour vos réponses qui m'apportent de bonnes pistes de solutions.
Cependant, vous ne m'avez pas répondu sur deux points:
* concernant la possibilité de sauvegarder un /etc/* sur une bécane et de le re-balancer après sur une autre, style un profil itinérant sur Windaube? faisable ou problématique et en quoi?
* De plus si je comprends bien, il est utile, dans mon cas de figure (ou l'utilisateur a des droits d'admin sur la machine sur laquelle il se connecte) de procéder à la sauvegarde de certains dossiers dont voici la liste d'après vous:
- /etc/ --> pour les fichiers de configutration des services, n'est-ce pas?
- /var/ --> pourquoi? si c'est les paramètres précis d'une machine, est-ce que cela ne va pas poser problème dans mon cas?
- /boot/ --> pourquoi le boot? Vu que toutes mes machines sont les mêmes?
[^] # [RESOLU] Application par tunnel SSH
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Ca a été dur mais en fait c'est très simple. Tout est dans l'utilisation de forceCommand dans sshd_config.
Merci à tous pour vos contibutions.
@+
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Le mieux c'est de bloquer la sortie directement de données sur le port 22 à partir de B, non?
J'ai établi quelques règles de pare-feu pour sécuriser ce cas. Les voici:
- laisser entrer depuis A vers B par le port 22
- autoriser uniquement les sorties de B par le port 22
- interdire toute les sorties depuis B
En fait je garde l'entrée et la sortie sur le port 22 pour permettre au tunnel SSH de fonctionner, c'est impératif non?
Sinon, pour bloquer sftp et scp j'ai trouvé ça (à l'adresse http://www.debian.org/doc/manuals/securing-debian-howto/ch-s(...)
"5.1.3 Interdire les transferts de fichiers
Si vous ne voulez pas que les utilisateurs transfèrent des fichiers depuis et vers le serveur ssh, vous devez restreindre l'accès au sftp-server et l'accès scp. Vous pouvez restreindre sftp-server en configurant le bon Subsystem dans /etc/ssh/sshd_config. Cependant, pour restreindre l'accès scp, vous devez :
* soit interdire les connexions d'utilisateurs au serveur ssh (comme décrit ci-dessus par le fichier de configuration ou par la configuration PAM),
* soit ne pas donner de shells valides aux utilisateurs qui ne sont pas autorisés à faire des transferts sécurités. Cependant, les shells fournis devraient être des programmes qui justifieraient la connexion au serveur ssh par eux-même, comme des programmes de menus (ala BBS). Sinon, l'option précédente est préférée."
-> Pour bloquer le sftp, je paramètre /etc/sshd_config avec:
Subsystem sftp /path/vers/autre/chose/que/sftp-server
la question est: vers quel programme?
-> par contre pour scp... Dur dur... sauf en interdisant le ssh de B vers A, en indiquant à sshd_config de A un port différent de 22. Ainsi, en bloquant toute sortie autre que par le port 22 depuis B, ça devrait le faire, vu que le client ne peut se connecter que sur le port que lui donne le serveur.
Non?
C'est bien compliqué ces histoires LOL
Merci en tout cas.
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Maintenant une autre colle.
J'ai une 2 stations A & B. Sur les deux est installé SSH. Ainsi, elles sont potentiellement client et serveur SSH. Je veux autoriser la connexion de A à B avec l'export du display. Mais je ne veux pas que lorsqu'un user se loggue en SSH sur la machine B, il puisse ensuite faire un SSH vers A. En fait je ne veux pas qu'il puisse faire de scp de données de B vers A.
Alors selon ce que j'ai compris, je paramètre comme suit:
- machine A, côté client: forwardX11, compression et port
- machine A, côté serveur: je désactive le forwardX11, et je choisi un port
- machine B, côté serveur: x11forwarding, x11display et port
- machine B, côté client: je désactive forwardX11 et je choisi un port autre que pour A serveur.
maintenant, est-ce suffisant? J'ai lu que la priorité dans la prise en compte des options est donnée à la ligne de commande. Donc quelqu'un qui arrive à trouver le port pourra toujours se connecter de B vers A en saisissant -p XXX comme argument, non?
Comment puis-je être sûr de ne pas avoir ce cas de figure, empêchant ainsi les copies distantes?
Merci de vos contribs.
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Donc en gros, j'ai un tunnel qui empeche les gens de voir au ce qui passe dedans, et dans ce tunnel, j'ai tout ce que je fais qui passe, n'est-ce pas?
Donc, c'est quand même good ça, niveau sécu, non?
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Mais alors, la sécurité elle est ou là-dedeans?
- Qu'est ce qui est crypté quand je travaille sur Nedit par SSH?
- Qui c'est qu'est dans le tunnel :? ?
Merci encore
[^] # Re: Nom de code Linux
Posté par ostead . En réponse au message Documentaires. Évalué à 1.
pourquoi ne pas essayer directement sur les sites de DM, youTube et Cie?
Tu trouveras peut-être ton bonheur.
Bonne chance ;)
[^] # Re: Nom de code Linux
Posté par ostead . En réponse au message Documentaires. Évalué à 1.
http://www.dailymotion.com/video/xx752_documentairenomdecode(...)
# Nom de code Linux
Posté par ostead . En réponse au message Documentaires. Évalué à 1.
http://archives.arte-tv.com/fr/archive_19031.html
@+
[^] # Re: Un peu plus de détails
Posté par ostead . En réponse au message Sauvegarde système en réseau. Évalué à 1.
merci mais mon but n'est pas d'avoir un système neuf à chaque démarrage. Je souhaite que le système charge les dossiers /etc, /var et cie que j'aurais sauvegardé sur une autre machine.
Faisable ou non? Et quels risques pour le système?
[^] # Re: Un peu plus de détails
Posté par ostead . En réponse au message Sauvegarde système en réseau. Évalué à 1.
-----> je n'ai que des petites config, donc elle ne supporteront pas la VM à mon avis
-----> j'ai pas vraiment le temps de me pencher sur la découverte de Xen, VMWare et Cie, je suis aussi étudiant dans cette école :P
-----> je pense que rajouter dans une solution de virtualisation que je ne maitrise pas la gestion des authentifications par le NIS, ainsi que les problèmes que je pourrais rencontrer au niveau des interfaces réseau pour avoir un lien toujours présent avec les serveurs de gestion, ça fait beaucoup pour un petit homme comme moi xD
mais si j'avais le temps, j'aurais bien poussé cette solution qui m'aurait permis au passage d'accéder à la connaissance des systèmes virtualisés.
Merci quand même de ta proposition.
# Un peu plus de détails
Posté par ostead . En réponse au message Sauvegarde système en réseau. Évalué à 1.
Cependant, vous ne m'avez pas répondu sur deux points:
* concernant la possibilité de sauvegarder un /etc/* sur une bécane et de le re-balancer après sur une autre, style un profil itinérant sur Windaube? faisable ou problématique et en quoi?
* De plus si je comprends bien, il est utile, dans mon cas de figure (ou l'utilisateur a des droits d'admin sur la machine sur laquelle il se connecte) de procéder à la sauvegarde de certains dossiers dont voici la liste d'après vous:
- /etc/ --> pour les fichiers de configutration des services, n'est-ce pas?
- /var/ --> pourquoi? si c'est les paramètres précis d'une machine, est-ce que cela ne va pas poser problème dans mon cas?
- /boot/ --> pourquoi le boot? Vu que toutes mes machines sont les mêmes?
Merci
Ostead