Bonjour,
Je n'ai jamais mis en place la configuration sur laquelle tu planches, mais je
pense pouvoir intervenir sans dire trop de conneries. Prends quand-même tout ça
avec précaution et n'hésite pas à vérifier avant.
Tout d'abord sur les modifications dans « sshd_config » (sur ce point je suis
sûr de moi) :
- ce qui t'a cassé l'accès est effectivement la directive « AllowUsers ». Tu
n'autorises _que_ ton invité à se connecter, donc tu ne peux plus te
connecter.
- lorsque tu redémarres le serveur SSH (« service ssh restart »), ta
connexion active n'est jamais coupée. Avant toute déconnexion, ouvre un
nouveau terminal et vérifie que tu peux toujours te connecter à ton
serveur. Si tu n'arrives plus à te connecter, profite de la connexion
active pour rétablir.
Vient maintenant la partie de mon intervention que tu devras prendre avec
précaution.
Le lundi 24 août 2015 à 17:38, Hugues MORIN a écrit :
> 1/ mon intervenant doit pourvoir acceder aux fichierx de mon site (dans
> /var/www/monsite)
> Si je cree un repertoire monsite dans /home/orthukyn/
> et que je fais un ln -s /var/www/monsite/ /home/orthukyn/monsite/
> Cela vous semble correct afin qu'il puisse y acceder par son repertoire?
A-priori ça ne fonctionnera pas. Un lien symbolique renvoie vers un autre
endroit du système de fichiers. Or, si tu enfermes ton utilisateur dans
« /home/orthukyn/ », il n'aura pas le droit d'aller dans « /var/www/monsite/ ».
Tu pourrais contourner ce point :
- par un montage « bind » de « /var/www/monsite/ » dans un dossier de
« /home/orthukyn/ »;
- en enfermant ton utilisateur dans « /var/www/monsite/ » (mais
l'utilisateur ne sera pas propriétaire des fichiers et risque de ne pas
pouvoir les modifier).
> 2/ Je suppose qu'il faut que je cree un chroot pour ce user afin de
> l'enfermer dans son repertoire
> Est ce a l'aide de ces lignes a ajouter dans sshd_config que l'on le fait?
> Match user orthukyn
> ChrootDirectory /home/orthukyn/
Ça m'en a bien l'air.
> J'ai pas bien compris a quoi servait:
> ForceCommand internal-sftp
> AllowTCPForwarding no
Je dirais que la première va empêcher l'utilisateur d'accéder à un shell et ne
le laissera faire _que_ du SFTP.
Quant à la seconde, elle lui empêchera de mettre en place des tunnels SSH [1] et
donc d'exploiter son accès SFTP pour attaquer un équipement qui serait sur le
LAN du serveur.
1: http://formation-debian.via.ecp.fr/ssh.html#idp11882304
> Est ce qu'elles sont necessaires?
Oui, sauf confiance dans l'intervenant.
> Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droit
> root:root, c'est bien ca?
A-priori ça ne devrait pas.
> 3/ Avec le meme user/password, mon intervenant peut aussi acceder au shell
> en ssh.
> J'ai pas tres envie qu'il puisse passer des commandes directement dans le
> shell.
Voir ci-dessus.
> Un des tuto parle de la commande chsh (chsh debora95dftp -s /bin/true)
> Est ce la solution pour bloquer l'acces au shell avec ce user/password?
J'ai mis en place une solution comme ça. J'ai un utilisateur dont le shell de
connexion (option « --shell » de la commande « adduser ») pointe vers le script
suivant :
#!/bin/sh
logger -p authpriv.alert "/!\\ Tunnel session opened /!\\"
read -p "Restricted shell, press a key to exit..." DUMMY
exit 0
Lorsque le compte utilisateur est utilisé pour se connecter :
- un message est inscrit dans le « syslog »;
- un message est affiché à l'utilisateur lui indiquant qu'il ne peut rien
faire d'autre que d'appuyer sur une touche pour quitter sa session.
> Pensez vous que ce soit suffisant pour "enfermer" mon intervenant dans son
> repertoire et ne lui permettre une connexion au serveur qu'en SFTP?
Personnellement, je combinerais tout ça (configuration SSH, script limité comme
shell de connexion).
Sébastien