SSH

Générer les clés

ssh-keygen -t dsa 
ssh-keygen -t rsa

Une clé DSA est plus fortement sécurisé qu'une clé RSA; par suite, une clé DSA sera préférée à une clé RSA.

Une clé RSA est indispensable puisque certains serveurs anciens ne connaissent pas la clé DSA. Il en est ainsi du serveur moorea.

Utilisateurs différents

To do :

Dans le cas ou l'utilisateur local est différent de celui du serveur distant, il faut ajouter un fichier "$HOME"/.ssh/config.

Host *
     User utilisateur-distant

Accès serveurs distants/clients

Pour éviter d'avoir à s'identifier par mot de passe, on peut copier notre clé publique sur les serveurs.

A partir du poste client disposant de la clé publique :

user="elopez"
server="moorea" # alias ou IP
ssh-copy-id -i "$user"@"$server"

A partir du serveur :

scp -r greg@192.168.123.2:/home/greg/.ssh/id_*pub .ssh/

Pour mettre en place une prison du compte client dans son dossier $HOME, on pourra suivre la page suivante Chroot users with OpenSSH: An easier way to confine users to their home directories

Pré-requis

L'utilisateur doit avoir un compte sur le serveur. Si ce n'est pas le cas, consulter la page de gestion d'utilisateurs UNIX. Il faut également un groupe auquel s'appliqueront les règles d'emprisonnement, il s'agit généralement de sftp ou sftponly. Vérifier si il existe et ajouter le si besoin :

groupadd sftp

Configuration du serveur SSH

On commentera la gestion par défaut du groupe sftp :

# Subsystem sftp /usr/libexec/openssh/sftp-server

On rajoutera dans /etc/ssh/sshd_config les lignes suivantes, si elles ne sont pas présentes. De façon à emprisonner (ou chrooter) les utilisateurs du groupe sftp qui se connecte en SFTP :

Subsystem     sftp   internal-sftp
Match Group sftp
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Notice :

Sous CentOS/RedHat 5.6 (peut-être même 5.8) le paquet openssh ne supporte pas l'option Match nécessaire au prison. Il faut donc demander une mise à jour au sysadmin pour avoir une version de openssh>=4 .4.

Droits du groupe

Pour que les fichiers créé par l'utilisateur client soit accessible en lecture et écriture au groupe, on modifiera la ligne Subsystem de /etc/ssh/sshd_config <ref>Setting the umask for SFTP transactions</ref> <ref> How to put desired umask with SFTP? http://serverfault.com/questions/70876/how-to-put-desired-umask-with-sftp</ref> comme suit :

Subsystem sftp /bin/sh -c 'umask u=rwx,g=rwx,o=r; /usr/lib/openssh/sftp-server'

Notice :

Si vous obtenez l'erreur :

Status: Connected to jubilo-web
Error: Connection closed by server with exitcode 127
Error: Could not connect to server

le chemin vers l'executable du serveur SFTP est peut-être incorrect, et il est toujours possible de se connecter en SSH.

De la même façon il faut que l'utilisateur ajlsm laisse le droit de lecture et d'écriture aux autres membres du groupe ajlsm. Pour ce faire, on change le umask lorsque l'utilisateur se connecter. Ceci peux se faire en rajouter la commande umask u=rwx,g=rwx,o=r dans le ~/.bashrc de l'utilisateur ajlsm :

echo "umask u=rwx,g=rwx,o=r" >> ~/.bashrc # en tant qu'utilisateur 'ajslm'

Une fois c'est modification effectué, on redémarrera le serveur SSH :

/etc/init.d/sshd restart

Configuration de l'utilisateur pour la prison

Remarques : Sous CentOS, on pourra installé le paquet shadow-utils pour simplifier la gestion des utilisateurs.

On rajoute l'utilisateur au groupe emprisonnable :

usermod -G sftp utilisateur

On désactive son accès au shell :

usermod -s /bin/false utilisateur

Son dossier doit appartenir à root pour pouvoir appliquer la prison :

chown root:root /home/utilisateur
chmod 0755 /home/utilisateur

Accès limités à certains dossiers/fichiers

Notice :

Avant de commencer, on prendra connaissance de la section sur fstab et des contenus nécessaire à y ajouter.

On commencera par créé des dossiers vides, dans le $HOME de l'utilisateur, dans lesquels on montera les dossiers auxquels on veut donner accès :

mkdir ~/cdc ~/ead ~/pdf

Avec la méthode simple

Cette méthode utilise les droits UNIX classique, cela peux être compliqué à gérer.

On monte les fichiers/dossier auquel on veut donner accès dans le dossier $HOME de l'utilisateur. De cette façon ils seront soumis à la prison SSH.

/home/www/UtilisateurXYZ/cdc   /home/UtilisateurXYZ/cdc   none    bind 0 0
/home/www/UtilisateurXYZ/ead   /home/UtilisateurXYZ/ead   none    bind 0 0
/home/www/UtilisateurXYZ/pdf   /home/UtilisateurXYZ/pdf   none    bind 0 0

Il faut adapter les droits des fichiers pour qu'ils soient accessible et éditable par l'utilisateur et l'application (souvent représenté par l'utilisateur et le groupe ajlsm) :

usermod -aG ajlsm Etat-Valais # ajoute l'utilisateur au groupe de l'application
chmod g+rwx -R ./cdc/ ./ead/ ./pdf/ # donne les droits de lecture, écriture, parcours/execution à l'utilisateur emprisonné

Avec la méthode avancée

Remarques : Cette section nécessite le paquet bindfs pour pouvoir fonctionner.

On utilise bindFS pour monter des parties du système de fichier d'un endroit à l'autre, en surchargeant certains droits. Pour cela on configure le montage des fichiers dans /etc/fstab, comme suit :

bindfs#/home/ajlsm/apps/basse-bretagne/exemples/ead/fonds-prives/bretagne  /home/basse-bretagne/ead    fuse  perms=0755,owner=basse-bretagne,group=ajlsm 0 0
bindfs#/home/ajlsm/data/basse-bretagne/pdf                                 /home/basse-bretagne/pdf    fuse  perms=0755,owner=basse-bretagne,group=ajlsm 0 0
bindfs#/home/ajlsm/apps/basse-bretagne/module-eadeac/pages/fr              /home/basse-bretagne/pages  fuse  perms=0755,owner=basse-bretagne,group=ajlsm 0 0

Important :

les droits en question ne sont pas réellement changés, lorsque l'utilisateur cré des fichiers, il lui appartiennent. Cependant, ils apparaîtront tel que décrit dans le /etc/fstab, ce qui peut être trompeur.

Références

<references/>