Bonjour
A force de recherche j'ai trouve la solution :D La reponse etait dans auth.log: Aug 26 11:51:51 monserveur sshd[4191]: Accepted password for orthukyn from monip port 36458 ssh2 Aug 26 11:51:51 monserveur sshd[4191]: pam_unix(sshd:session): session opened for user orthukyn by (uid=0) Aug 26 11:51:51 monserveur sshd[4204]: fatal: bad ownership or modes for chroot directory "/home/orthukyn" Aug 26 11:51:51 monserveur sshd[4191]: pam_unix(sshd:session): session closed for user orthukyn Juste un probleme de proprietaire, il faut que ce soit root le proprietaire du repertoire /home/orthukyn Le chroot et le sftp fonctionne Maintenant il faut que je trouve une solution pour que mon intervenant puisse aceder aux fichiers Je vais explorer la solution du montage bind Cordialement Hugues Le 25 août 2015 14:48, Hugues MORIN <[email protected]> a écrit : > Bonjour > > > Merci pour votre aide et vos conseils. > > J'utilise deja le systeme de clef publique/prive pour me connecter a mon > serveur. > Malheureusement je crains que mon intervenant n'est pas la competence (ou > ne veuille pas) pour le mettre en oeuvre... > De plus, je ne maitrise pas bien non plus donc ce sera aussi pour moi > assez complique. > > J'ai aussi essaye d'installer ProFTP mais apres quelques heures je ne suis > pas arrive a le faire fonctionner. > Quand a iptable, malheureusement il reste encore tres obscur pour moi. > Je n'ai pas encore compris comment cela fonctionne (surement du a mes > lacunes en matiere de reseau :( > > Je garde le mysecureshell et le script qui bloque le shell sous le coude ;) > > > Sinon je viens de tenter le chroot mais ca n'a pas l'air de fonctionner ni > en ssh ni en sftp > J'ai ajoute a sshd_config: > > #AllowUsers > AllowUsers root monuser orthukyn > > et > > # Chroot orthukyn > Match user orthukyn > ChrootDirectory /home/orthukyn/ > ForceCommand internal-sftp > AllowTCPForwarding no > > > Ensuite j'ai redemarre et teste > > root@monserver:/etc/ssh# /etc/init.d/ssh restart > > hugues@localhost:~$ ssh orthukyn@monserver > orthukyn@monserver's password: > Connection to monserver closed by remote host. > Connection to monserver closed. > > hugues@localhost:~$ sftp orthukyn@monserver > orthukyn@monserver's password: > Connection to monserver closed by remote host. > Couldn't read packet: Connection reset by peer > > > Il n'y a aucun probleme sur les autres utilisateurs. > > J'ai tente de passer /home/orthukyn/ en proprietaire root:root mais c'est > toujurs un echec. > > J'ai du rate une information ou mal comprendre quelque chose :-/ > > > Cordialement > Hugues > > > Le 24 août 2015 18:21, Sébastien NOBILI <[email protected]> a écrit : > >> 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 >> >> >
