Bonjour a tous
Merci pour votre aide. Mon intervenant n'a finalement pas eu a intevenir, une mise a jour de ma solution a corriger le probleme. Chose positive, j'ai appris une nouvelle technique :D :D :D Pour conclure, voici la solution que j'ai trouve: - J'ai mis root:orthukyn comme proprietaire sur /home/orthukyn - J'ai cree un repertoire monsite dans /home/orthukyn - J'ai fait un montage bind de /var/www/monsite dans /home/orthukyn/monsite - J'ai ajoute le user orthukyn au groupe www-data (proprietaire des fichiers et repertoires de monsite) - J'ai mis les droits a 775 sur les repertoires et 664 sur les fichiers le temps de l'intervention. Il ne reste plus qu'a demonter le montage, supprimer le chroot, redonner les bons proprietaire et les bons a /monsite et supprimer le user Niveau securite 775 et 664, ca ne doit pas etre top, mais c'etait temporaire Cordialement Hugues Le 26 août 2015 14:12, Hugues MORIN <mor...@gmail.com> a écrit : > 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 <mor...@gmail.com> 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 <sebnewslet...@free.fr> 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 >>> >>> >> >
