|
Taille: 8055
Commentaire: un peu de sécurisation via rssh et scponly
|
← Version 6 à la date du 2008-08-27 15:36:21 ⇥
Taille: 5142
Commentaire: GVFS, c'est pas si pire
|
| Texte supprimé. | Texte ajouté. |
| Ligne 3: | Ligne 3: |
| Quelques liens pour en savoir plus : * le site de SSHFS : http://fuse.sourceforge.net/sshfs.html * Une documentation sur quelques utilisations possible sur [[http://doc.ubuntu-fr.org/sshfs|Ubuntu-FR]] |
Voir le site de SSHFS : http://fuse.sourceforge.net/sshfs.html |
| Ligne 13: | Ligne 11: |
| * la connexion SSH doit se faire avec une authentification par clé, la clé privée doit être cryptée mais l'utilisateur ne doit pas avoir à entrer de mot de passe de décryptage sans arrêt (utilisation de [[SSH#libpam-ssh|libpam-ssh]]) ; | * la connexion SSH doit se faire avec une authentification par clé, la clé privée doit être cryptée mais l'utilisateur ne doit pas avoir à entrer de mot de passe de décryptage sans arrêt (utilisation du trousseau de clé ''seahorse'') ; |
| Ligne 17: | Ligne 15: |
| ||<#ffaa00> Note bien : '''il ne faut pas ouvrir ce service directement sur Internet.''' On se le permet pour la messagerie car le contenu est réputé plus volatile et les utilisateurs sont censés le savoir aujourd'hui. Pour leurs fichiers, c'est différent, il peut s'agir de projets en cours, de données beaucoup plus confidentielles qu'il ne s'agit surtout pas de se faire pirater ! En outre, le tracé de l'activité de ce service est délicat, on ne pourra pas détecter et prouver une usurpation comme on peut le faire avec la messagerie. Si vous voulez rendre l'accès aux fichiers disponible depuis n'importe quelle machine sur Internet, ajoutez d'abord une couche de connexion au réseau privé, via OpenVPN. || | ||<#ffaa00> Notez bien : '''il ne faut pas ouvrir ce service directement sur Internet.''' On se le permet pour la messagerie car le contenu est réputé plus volatile et les utilisateurs sont censés le savoir aujourd'hui. Pour leurs fichiers, c'est différent, il peut s'agir de projets en cours, de données beaucoup plus confidentielles qu'il ne s'agit surtout pas de se faire pirater ! En outre, le tracé de l'activité de ce service est délicat, on ne pourra pas détecter et prouver une usurpation comme on peut le faire avec la messagerie. Si vous voulez rendre l'accès aux fichiers disponible depuis n'importe quelle machine sur Internet, ajoutez d'abord une couche de connexion au réseau privé, via OpenVPN. || |
| Ligne 21: | Ligne 19: |
| L'utilisateur doit avoir un compte accessible en SSH sur le serveur sur lequel se trouve ses données. L'accès SSH ne doit être possible que par clé (pas d'authentification par mot de passe). Cependant pour éviter que l'utilisateur ne doive entrer le mot de passe de sa clé privée à chaque montage, on la crypte avec le même mot de passe que pour son compte et on utilise ''libpam-ssh''. La clé sera donc disponible dans l'agent SSH dès la connexion de l'utilisateur (voir explications sur [[SSH#libpam-ssh|la page de SSH]]). | L'utilisateur doit avoir un compte accessible en SSH sur le serveur sur lequel se trouve ses données. L'accès SSH ne doit être possible que par clé (pas d'authentification par mot de passe). Cependant pour éviter que l'utilisateur ne doive entrer le mot de passe de sa clé privée à chaque montage, on ajoute la clé ssh de l'utilisateur dans le trousseau ''seahorse'', et on demande à ''seahorse'' de gérer automatiquement les clés lors de l'ouverture de la session. |
| Ligne 23: | Ligne 21: |
| Notes : * Pour un utilisateur paranoïaque, on peut lui proposer un mot de passe différent pour sa clé privée, mais dans la pratique on sait que cela finira par l'ennuyer : il mettra un mot de passe trivial sur la clé, ou n'utilisera plus le service sshfs ; * Lorsque l'utilisateur changera son mot de passe de connexion, il faudra changer celui qui crypte sa clé privée. |
''à faire : quelques copies d'écran pour montrer comment activer seahorse comme il faut'' Pour un utilisateur paranoïaque, on peut lui proposer un mot de passe spécifique pour sa clé privée... mais rappelez-vous que dans la pratique on sait que cela finira par l'ennuyer : il mettra un mot de passe trivial sur la clé, ou n'utilisera plus le service sshfs. |
| Ligne 29: | Ligne 27: |
| 1. Installation : {{{ # aptitude install sshfs }}} 1. SSHFS utilisant FUSE, il faut que l'utilisateur ait accès à FUSE. Sur Ubuntu il suffit de l'ajouter au groupe correspondant (voir [[AuthentificationCentralisée/GestionDesGroupes|ici]] pour le faire de façon générique) : {{{ # adduser utilisateur fuse }}} 1. 1. Test, depuis le compte de l'utilisateur : {{{ $ mkdir serveur $ sshfs bao.sn.auf: serveur <---- on monte le HOME de bao.sn.auf sur le répertoire serveur $ ls serveur <---- doit afficher les fichiers de bao.sn.auf:~ }}} 1. Vérifiez les droits, la navigation dans les fichiers, les liens symboliques, etc... 1. Démontage : {{{ $ fusermount -u serveur }}} |
Depuis Ubuntu Hardy, il n'y a rien à faire. SSHFS est déjà présent et gérable via GVFS. |
| Ligne 52: | Ligne 31: |
| 1. On indique au système le point de montage : {{{ # (... extrait de /etc/fstab ...) sshfs#bao.sn.auf: /sshfs/ServeurBAO fuse user,noauto,sshfs_debug,nonempty,compression=yes,reconnect,BatchMode=yes 0 0 }}} 1. On créée le point de montage : {{{ mkdir -p /sshfs/ServeurBAO chown root:fuse /sshfs/ServeurBAO chmod 770 /sshfs/ServeurBAO }}} |
Depuis Ubuntu Hardy et GVFS, on peut utiliser directement la solution ''Raccourcis / Se connecter à un serveur...'' disponible dans Gnome. On peut alors créer un raccourci que l'utilisateur pourra retrouver facilement, et qui sera visible dans la grande majorité des applications (!OpenOffice.org, Firefox, Thunderbird et toutes les applications GVFS-isées). |
| Ligne 64: | Ligne 33: |
| Et c'est tout ! A partir de là, un système de fichier ServeurBAO sera visible dans Nautilus, mais aussi dans les fenêtres de dialogue de Gnome. De plus, un icône disque ServeurBAO s'affichera sur le bureau lors du montage. '''Note 1''' : pour que les choses soient bien automatiques, idéalement il faut que l'utilisateur ait un login identique sur son poste et sur le serveur. Sinon il faut modifier la ligne du /etc/fstab et la faire commencer par `sshfs#login_sur_serveur@bao.sn.auf:`. Mais dans ce cas, le système ne fonctionnera que pour cet utilisateur donné, c'est un peu moins élégant comme solution. '''Note 2''' : on ne passe pas par la solution ''Se connecter à un serveur...'' disponible dans Gnome. En effet celle-ci se base sur Gnome et les fichiers ne sont alors disponibles que pour les applications Gnome qui utilisent Gnome-VFS. Avec la solution `/etc/fstab`, ''toutes'' les applications pourront accéder au partage ''sshfs''. Pour aider l'utilisateur avec ses applications on peut éventuellement ajouter un lien symbolique sur son répertoire personnel vers `/sshfs/le_repertoire_partagé`. == Ca ne marche pas ? C'est normal ! == Malheureusement, gnome-vfs est un peu buggué au niveau du lancement du montage SSHFS. Pour une [[http://bugzilla.gnome.org/show_bug.cgi?id=397441|sombre histoire de tty]], le montage est effectué... puis tué aussitôt ! Pour corriger cela, on peut mettre en place une solution de '''surcharge de sshfs''' insensible aux signaux HUP : {{{ # !/bin/sh # script à placer dans /usr/local/bin/sshfs (il sera appelé à # la place de /usr/bin/sshfs). Ne pas oublier de lui donner # les droits d'execution : chmod 755 /usr/local/bin/sshfs # Note : un simple "nohup sshfs ..." suffirait, mais j'ai préféré # ajouter une gestion des erreurs qui permette leur affichage dans # Gnome si ça plante... # fichier où l'on stocke les messages de sortie de nohup errlog=`tempfile -p sshfs -s .out` # lancement du montage nohup /usr/bin/sshfs "$@" > $errlog 2>&1 # en cas d'erreur, affichage du probleme ret=$? if [ $ret != 0 ]; then cat $errlog 1>&2 fi rm -f $errlog exit $ret }}} |
Pour les applications non-gnome (non-GVFS), il faut expliquer à l'utilisateur que le montage SSHFS est effectué en réalité dans un endroit un peu caché : `~/.gvfs/nom-du-montage`. Pour aider, on peut créer un lien symbolique quelque part qui pointe vers ce répertoire. |
| Ligne 121: | Ligne 56: |
| = Ca marche enfin, la preuve en photo = {{attachment:nautilus.png}} {{attachment:ouvrir.png}} {{attachment:icone-bureau.png}} |
SSHFS est, comme son nom l'indique, un système de fichier utilisant le protole SSH. En fait, il permet d'accéder à ses fichiers stockés sur un serveur distant via le protocole SSH de façon transparent, via un simple répertoire.
Voir le site de SSHFS : http://fuse.sourceforge.net/sshfs.html
Utilisation dans le cadre AUF
L'idée est de proposer un accès simplifié à leurs fichiers à nos utilisateurs nomades, c'est-à-dire à ceux qui disposent d'un ordinateur portable sur Ubuntu1. Pour les postes fixes, NFS reste nettement plus performant.
Pour que cet accès reste simple et néanmoins bien sécurisé :
- il faut que le montage soit automatique, mais non-permanent. L'utilisateur doit pouvoir monter et démonter le partage de manière simple et bien intégrée à Ubuntu ;
la connexion SSH doit se faire avec une authentification par clé, la clé privée doit être cryptée mais l'utilisateur ne doit pas avoir à entrer de mot de passe de décryptage sans arrêt (utilisation du trousseau de clé seahorse) ;
- l'accès SSH ne sera pas disponible en dehors du réseau privé de l'AUF (RPV), si vous désirez proposer un accès externe il faut utiliser
OpenVPN. Un effet secondaire agréable est qu'OpenVPN solutionne le problème des adresses IP changeantes pour un client sur une liaison type ADSL.
Notez bien : il ne faut pas ouvrir ce service directement sur Internet. On se le permet pour la messagerie car le contenu est réputé plus volatile et les utilisateurs sont censés le savoir aujourd'hui. Pour leurs fichiers, c'est différent, il peut s'agir de projets en cours, de données beaucoup plus confidentielles qu'il ne s'agit surtout pas de se faire pirater ! En outre, le tracé de l'activité de ce service est délicat, on ne pourra pas détecter et prouver une usurpation comme on peut le faire avec la messagerie. Si vous voulez rendre l'accès aux fichiers disponible depuis n'importe quelle machine sur Internet, ajoutez d'abord une couche de connexion au réseau privé, via OpenVPN. |
Préliminaire : configuration au niveau SSH
L'utilisateur doit avoir un compte accessible en SSH sur le serveur sur lequel se trouve ses données. L'accès SSH ne doit être possible que par clé (pas d'authentification par mot de passe). Cependant pour éviter que l'utilisateur ne doive entrer le mot de passe de sa clé privée à chaque montage, on ajoute la clé ssh de l'utilisateur dans le trousseau seahorse, et on demande à seahorse de gérer automatiquement les clés lors de l'ouverture de la session.
à faire : quelques copies d'écran pour montrer comment activer seahorse comme il faut
Pour un utilisateur paranoïaque, on peut lui proposer un mot de passe spécifique pour sa clé privée... mais rappelez-vous que dans la pratique on sait que cela finira par l'ennuyer : il mettra un mot de passe trivial sur la clé, ou n'utilisera plus le service sshfs.
Installation et test de SSHFS
Depuis Ubuntu Hardy, il n'y a rien à faire. SSHFS est déjà présent et gérable via GVFS.
Automatisation du montage
Depuis Ubuntu Hardy et GVFS, on peut utiliser directement la solution Raccourcis / Se connecter à un serveur... disponible dans Gnome. On peut alors créer un raccourci que l'utilisateur pourra retrouver facilement, et qui sera visible dans la grande majorité des applications (OpenOffice.org, Firefox, Thunderbird et toutes les applications GVFS-isées).
Pour les applications non-gnome (non-GVFS), il faut expliquer à l'utilisateur que le montage SSHFS est effectué en réalité dans un endroit un peu caché : ~/.gvfs/nom-du-montage. Pour aider, on peut créer un lien symbolique quelque part qui pointe vers ce répertoire.
Sécurisation : limitation de l'accès ssh
La méthode indiquée ci-dessus demande à ce que l'utilisateur ait un accès ssh classique au serveur, c'est-à-dire un "secure shell". Or il n'est pas forcément nécessaire que ces utilisateurs aient un accès shell au serveur ; cela peut même être dangereux si cet accès tombe entre les mains d'une personne mal intentionnée.
Pour limiter l'accès ssh et le restreindre à la gestion des fichiers (sans accès shell), on peut utiliser deux techniques :
scponly : on attribue le shell /usr/bin/scponly à chaque utilisateur sshfs ;
rssh : on active le mode sftp dans /etc/rssh.conf puis on attribue le shell /usr/bin/rssh à chaque utilisateur sshfs.
Exemple avec scponly :
# aptitude install scponly <--- si ce n'est pas déjà fait # chsh -s /usr/bin/scponly login <--- restreint l'accès ssh pour l'utilisateur "login"
Exemple avec rssh :
# aptitude install rssh <--- si ce n'est pas déjà fait # vi /etc/rssh.conf <--- activer le mode sftp (option allowsftp) # chsh -s /usr/sbin/rssh login <--- restreint l'accès ssh pour l'utilisateur "login"
Notes de bas de page :
ou MacOS X, mais bon. Pour windows, voir winscp et ses amis. (1)