Besoin explications pour installer SFTP

Le
Hugues MORIN
--001a11c269c2200fce051e0efc14
Content-Type: text/plain; charset=UTF-8

Bonjour a tous



J'ai un serveur dedie sur lequel j'heberge des sites.
Je ne maitrise pas bien les problemes lies a la securite des serveurs donc
je n'ai pas voulu installer de serveur FTP sur ce serveur.
J'accede au shell en ssh et j'ai monte en local le systeme de fichier afin
d'avoir un acces plus "facile" pour les modifications.
Je n'ai que 2 utilisateurs qui peuvent acceder en ssh sur cette machine:
root et "myuser"

J'ai sur un des sites un probleme technique qui necessite l'intervention
d'un technicien.
J'ai donc tente d'installe un SFTP (puisque je dispose deja de
openssh-server) afin que cet intervenant puisse acceder au dossier qui le
concerne sur le serveur.
Malheureusement ca etait un echec, je me suis bloque l'acces a mon server
et j'ai du demander l'intervention de hebergeur.

Je me suis inspire des 2 tuto suivant pour installer le SFTP:
https://debian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server
http://www.ced-info.com/administration-reseaux/installer-facilement-un-serveur-sftp

J'ai dans un premier temps creer un nouveau user avec son groupe et son
repertoire:
passwd => orthukyn:x:1001:1001:Intervenant
Exterieur,,,:/home/orthukyn:/bin/bash
group => orthukyn:x:1001:
repertoire => /home/orthukyn/


Dans sshd_config (qui n'a jamais ete modifie), j'ai ajoute:

1/ #AllowUsers
AllowUsers orthukyn

2/ apres UsePAM yes
Match user orthukyn
ChrootDirectory /home/orthukyn/
ForceCommand internal-sftp
AllowTCPForwarding no

J'ai redemarrer ssh et apres le redemarrage, impossible de se reconnecter.

Je ne vois pas ou peut etre mon erreur, surtout que quand on lit les tuto
ca a l'air assez simple.
Le seul truc sur lequel je doute c'est le AllowUsers.
Est ce que je dois y rajouter root et "myuser" pour que ca fonctionne?



Cordialement
Hugues

--001a11c269c2200fce051e0efc14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div>Bonjour a tous<br><br><br><br></div>J&#39;a=
i un serveur dedie sur lequel j&#39;heberge des sites.<br></div>Je ne maitr=
ise pas bien les problemes lies a la securite des serveurs donc je n&#39;ai=
pas voulu installer de serveur FTP sur ce serveur.<br></div><div>J&#39;acc=
ede au shell en ssh et j&#39;ai monte en local le systeme de fichier afin d=
&#39;avoir un acces plus &quot;facile&quot; pour les modifications.<br></di=
v><div>Je n&#39;ai que 2 utilisateurs qui peuvent acceder en ssh sur cette =
machine: root et &quot;myuser&quot;<br></div><div><br></div><div>J&#39;ai s=
ur un des sites un probleme technique qui necessite l&#39;intervention d&#3=
9;un technicien.<br></div><div>J&#39;ai donc tente d&#39;installe un SFTP (=
puisque je dispose deja de openssh-server) afin que cet intervenant puisse =
acceder au dossier qui le concerne sur le serveur. <br></div><div>Malheureu=
sement ca etait un echec, je me suis bloque l&#39;acces a mon server et j&#=
39;ai du demander l&#39;intervention de hebergeur.<br><br></div><div>Je me =
suis inspire des 2 tuto suivant pour installer le SFTP:<br><a href="https=
://debian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server">https://deb=
ian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server</a><br><a href="=
http://www.ced-info.com/administration-reseaux/installer-facilement-un-serv=
eur-sftp">http://www.ced-info.com/administration-reseaux/installer-facileme=
nt-un-serveur-sftp</a><br><br></div><div>J&#39;ai dans un premier temps cre=
er un nouveau user avec son groupe et son repertoire:<br>passwd =&gt; ort=
hukyn:x:1001:1001:Intervenant Exterieur,,,:/home/orthukyn:/bin/bash<br></di=
v><div>group =&gt; orthukyn:x:1001:<br></div><div>repertoire =&gt; /hom=
e/orthukyn/<br><br><br></div><div>Dans sshd_config (qui n&#39;a jamais ete =
modifie), j&#39;ai ajoute:<br><br>1/ #AllowUsers<br>AllowUsers orthukyn<br>=
<br></div><div>2/ apres UsePAM yes<br></div><div>Match user orthukyn<br>Â=
 Â Â Â Â Â  ChrootDirectory /home/orthukyn/<br> =
      ForceCommand internal-sftp<br>  =
     AllowTCPForwarding no<br><br></div><div>J&#39;ai r=
edemarrer ssh et apres le redemarrage, impossible de se reconnecter.<br><br=
></div><div>Je ne vois pas ou peut etre mon erreur, surtout que quand on li=
t les tuto ca a l&#39;air assez simple.<br></div><div>Le seul truc sur lequ=
el je doute c&#39;est le AllowUsers. <br></div><div>Est ce que je dois y ra=
jouter root et &quot;myuser&quot; pour que ca fonctionne?<br><br><br><br></=
div><div>Cordialement<br></div><div>Hugues<br><br><br></div><div><br></div>=
</div>

--001a11c269c2200fce051e0efc14--
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
honeyshell
Le #26364338
Typiquement si tu te connectes à ton serveur via ssh avec la commande :
ssh -p 22
pour sftp, ce sera:
sftp -P 22

(P majuscule)
Hugues MORIN
Le #26364343
--001a11353d861d5a58051e106acd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

ah ... ok O_o
J'ai du rate la ligne ou c'etait ecrit.

Merci Jeremy :D


Questions subsidiaires:
Comment faire pour assurer la securite de ce "user/password" qui va etre
fournie a un intervenant?

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?

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/

J'ai pas bien compris a quoi servait:
ForceCommand internal-sftp
AllowTCPForwarding no

Est ce qu'elles sont necessaires?

Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droit
root:root, c'est bien ca?


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.

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?



Pensez vous que ce soit suffisant pour "enfermer" mon intervenant dans son
repertoire et ne lui permettre une connexion au serveur qu'en SFTP?

Desole pour toutes ces questions (peut etre un peu neuneu ;-) mais c'est la
1ere fois que je fais cette operation.
Et comme je suis sur un serveur en production, il faut que je sois tres
prudent (je sais ca ne se fait pas..... mais j'ai pas le choix)

Merci :D

Cordialement
Hugues


Le 24 août 2015 15:58, Prego Jérémy
bonjour,

l'accès sftp fonctionne par défault ... rien besoin de rajouter null part.

jerem

Le 24/08/2015 15:56, Hugues MORIN a écrit :

Bonjour a tous



J'ai un serveur dedie sur lequel j'heberge des sites.
Je ne maitrise pas bien les problemes lies a la securite des serveurs don c
je n'ai pas voulu installer de serveur FTP sur ce serveur.
J'accede au shell en ssh et j'ai monte en local le systeme de fichier afi n
d'avoir un acces plus "facile" pour les modifications.
Je n'ai que 2 utilisateurs qui peuvent acceder en ssh sur cette machine:
root et "myuser"

J'ai sur un des sites un probleme technique qui necessite l'intervention
d'un technicien.
J'ai donc tente d'installe un SFTP (puisque je dispose deja de
openssh-server) afin que cet intervenant puisse acceder au dossier qui le
concerne sur le serveur.
Malheureusement ca etait un echec, je me suis bloque l'acces a mon server
et j'ai du demander l'intervention de hebergeur.

Je me suis inspire des 2 tuto suivant pour installer le SFTP:
https://debian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server

http://www.ced-info.com/administration-reseaux/installer-facilement-un-se rveur-sftp

J'ai dans un premier temps creer un nouveau user avec son groupe et son
repertoire:
passwd => orthukyn:x:1001:1001:Intervenant
Exterieur,,,:/home/orthukyn:/bin/bash
group => orthukyn:x:1001:
repertoire => /home/orthukyn/


Dans sshd_config (qui n'a jamais ete modifie), j'ai ajoute:

1/ #AllowUsers
AllowUsers orthukyn

2/ apres UsePAM yes
Match user orthukyn
ChrootDirectory /home/orthukyn/
ForceCommand internal-sftp
AllowTCPForwarding no

J'ai redemarrer ssh et apres le redemarrage, impossible de se reconnecter .

Je ne vois pas ou peut etre mon erreur, surtout que quand on lit les tuto
ca a l'air assez simple.
Le seul truc sur lequel je doute c'est le AllowUsers.
Est ce que je dois y rajouter root et "myuser" pour que ca fonctionne?



Cordialement
Hugues








--001a11353d861d5a58051e106acd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




<div bgcolor="#FFFFFF" text="#000000">
bonjour,<br>
<br>
l&#39;accès sftp fonctionne par défault ... rien besoin de ra jouter null
part.<br>
<br>
jerem<div><div><br>
<div>Le 24/08/2015 15:56, Hugues MORIN a
écrit :<br>
</div>
<blockquote type="cite">

<div dir="ltr">
<div>
<div>
<div>Bonjour a tous<br>
<br>
<br>
<br>
</div>
J&#39;ai un serveur dedie sur lequel j&#39;heberge des sites.<b r>
</div>
Je ne maitrise pas bien les problemes lies a la securite des
serveurs donc je n&#39;ai pas voulu installer de serveur FTP sur
ce serveur.<br>
</div>
<div>J&#39;accede au shell en ssh et j&#39;ai monte en local le sys teme
de fichier afin d&#39;avoir un acces plus &quot;facile&quot; pour les
modifications.<br>
</div>
<div>Je n&#39;ai que 2 utilisateurs qui peuvent acceder en ssh sur
cette machine: root et &quot;myuser&quot;<br>
</div>
<div><br>
</div>
<div>J&#39;ai sur un des sites un probleme technique qui necessite
l&#39;intervention d&#39;un technicien.<br>
</div>
<div>J&#39;ai donc tente d&#39;installe un SFTP (puisque je dispose deja
de openssh-server) afin que cet intervenant puisse acceder au
dossier qui le concerne sur le serveur. <br>
</div>
<div>Malheureusement ca etait un echec, je me suis bloque
l&#39;acces a mon server et j&#39;ai du demander l&#39;interventi on de
hebergeur.<br>
<br>
</div>
<div>Je me suis inspire des 2 tuto suivant pour installer le
SFTP:<br>
<br>
</div>
<div>J&#39;ai dans un premier temps creer un nouveau user avec son
groupe et son repertoire:<br>
passwd =&gt; orthukyn:x:1001:1001:Intervenant
Exterieur,,,:/home/orthukyn:/bin/bash<br>
</div>
<div>group =&gt; orthukyn:x:1001:<br>
</div>
<div>repertoire =&gt; /home/orthukyn/<br>
<br>
<br>
</div>
<div>Dans sshd_config (qui n&#39;a jamais ete modifie), j&#39;ai aj oute:<br>
<br>
1/ #AllowUsers<br>
AllowUsers orthukyn<br>
<br>
</div>
<div>2/ apres UsePAM yes<br>
</div>
<div>Match user orthukyn<br>
       ChrootDirectory /home/orthuk yn/<br>
       ForceCommand internal-sftp<b r>
       AllowTCPForwarding no<br>
<br>
</div>
<div>J&#39;ai redemarrer ssh et apres le redemarrage, impossible de
se reconnecter.<br>
<br>
</div>
<div>Je ne vois pas ou peut etre mon erreur, surtout que quand
on lit les tuto ca a l&#39;air assez simple.<br>
</div>
</div>
<div>Est ce que je dois y rajouter root et &quot;myuser&quot; pour que ca
fonctionne?<br>
<br>
<br>
<br>
</div>
<div>Cordialement<br>
</div>
<div>Hugues<br>
<br>
<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
</div></div></div>

</blockquote></div><br></div></div></div></div></div>

--001a11353d861d5a58051e106acd--
Sébastien NOBILI
Le #26364347
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
Philippe Gras
Le #26364348
Le 24 août 2015 à 15:56, Hugues MORIN
Bonjour a tous



J'ai un serveur dedie sur lequel j'heberge des sites.
Je ne maitrise pas bien les problemes lies a la securite des serveurs donc je n'ai pas voulu installer de serveur FTP sur ce serveur.
J'accede au shell en ssh et j'ai monte en local le systeme de fichier afin d'avoir un acces plus "facile" pour les modifications.
Je n'ai que 2 utilisateurs qui peuvent acceder en ssh sur cette machine: root et "myuser"

J'ai sur un des sites un probleme technique qui necessite l'intervention d'un technicien.
J'ai donc tente d'installe un SFTP (puisque je dispose deja de openssh-server) afin que cet intervenant puisse acceder au dossier qui le concerne sur le serveur.



IPtables-Netfilter est une bonne solution pour gérer efficacement les accès au serveur.

Ça évite aussi de se poser plein de questions et d'installer des trucs exprès pour 1 fois.

Personnellement, j'utilise un service FTP (ProFTP je crois), mais seule ma plage IP y a

accès sur le port correspondant.

Si je veux donner un accès à quelqu'un d'autre, je peux le faire aussi de la même façon,

j'ai juste une ligne de commande à écrire.




andre_debian
Le #26364353
Hello,

Pour une connexion vraiment sécurisée avec ssh / sftp,
* ne jamais utiliser le mot de passe *, mais avec des clés,
publique (sur le serveur) et privée (sur le client).

Google t'indiquera moults tutos en tapant : "créer clés ssh".

Sur le client, la clé se situe dans /home/<user>/.ssh/
Sur le serveur dans /home/<user>/.ssh/authorized_key
souvent /home/root/.ssh/authorized_key

Un rootkit sur ton ordinateur peut capter un mot de passe
et l'envoyer à tierce personne...

Hope it helps :-)

André

On Monday 24 August 2015 17:38:52 Hugues MORIN wrote:
Questions subsidiaires:
Comment faire pour assurer la securite de ce "user/password" qui va etre
fournie a un intervenant?

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?

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/

J'ai pas bien compris a quoi servait:
ForceCommand internal-sftp
AllowTCPForwarding no

Est ce qu'elles sont necessaires?

Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droit
root:root, c'est bien ca?


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.

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?



Pensez vous que ce soit suffisant pour "enfermer" mon intervenant dans son
repertoire et ne lui permettre une connexion au serveur qu'en SFTP?

Desole pour toutes ces questions (peut etre un peu neuneu ;-) mais c'est la
1ere fois que je fais cette operation.
Et comme je suis sur un serveur en production, il faut que je sois tres
prudent (je sais ca ne se fait pas..... mais j'ai pas le choix)

Merci :D

Cordialement
Hugues

Le 24 août 2015 15:58, Prego Jérémy > bonjour,
>
> l'accès sftp fonctionne par défault ... rien besoin de rajouter null
> part.
>
> jerem
>
> Le 24/08/2015 15:56, Hugues MORIN a écrit :
>
> Bonjour a tous
>
>
>
> J'ai un serveur dedie sur lequel j'heberge des sites.
> Je ne maitrise pas bien les problemes lies a la securite des serveurs
> donc je n'ai pas voulu installer de serveur FTP sur ce serveur.
> J'accede au shell en ssh et j'ai monte en local le systeme de fichier
> afin d'avoir un acces plus "facile" pour les modifications.
> Je n'ai que 2 utilisateurs qui peuvent acceder en ssh sur cette machine:
> root et "myuser"
>
> J'ai sur un des sites un probleme technique qui necessite l'intervention
> d'un technicien.
> J'ai donc tente d'installe un SFTP (puisque je dispose deja de
> openssh-server) afin que cet intervenant puisse acceder au dossier qui le
> concerne sur le serveur.
> Malheureusement ca etait un echec, je me suis bloque l'acces a mon serv er
> et j'ai du demander l'intervention de hebergeur.
>
> Je me suis inspire des 2 tuto suivant pour installer le SFTP:
> https://debian-facile.org/doc:reseau:ssh:tp-sftp-via-openssh-server
>
> http://www.ced-info.com/administration-reseaux/installer-facilement-un- se
>rveur-sftp
>
> J'ai dans un premier temps creer un nouveau user avec son groupe et son
> repertoire:
> passwd => orthukyn:x:1001:1001:Intervenant
> Exterieur,,,:/home/orthukyn:/bin/bash
> group => orthukyn:x:1001:
> repertoire => /home/orthukyn/
>
>
> Dans sshd_config (qui n'a jamais ete modifie), j'ai ajoute:
>
> 1/ #AllowUsers
> AllowUsers orthukyn
>
> 2/ apres UsePAM yes
> Match user orthukyn
> ChrootDirectory /home/orthukyn/
> ForceCommand internal-sftp
> AllowTCPForwarding no
>
> J'ai redemarrer ssh et apres le redemarrage, impossible de se
> reconnecter.
>
> Je ne vois pas ou peut etre mon erreur, surtout que quand on lit les tu to
> ca a l'air assez simple.
> Le seul truc sur lequel je doute c'est le AllowUsers.
> Est ce que je dois y rajouter root et "myuser" pour que ca fonctionne?
>
>
>
> Cordialement
> Hugues
Hugues MORIN
Le #26364406
--001a11353d8630d761051e222556
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

:/etc/ssh# /etc/init.d/ssh restart

:~$ ssh
's password:
Connection to monserver closed by remote host.
Connection to monserver closed.

:~$ sftp
'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
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 p eux plus te
connecter.
- lorsque tu redémarres le serveur SSH (« service ssh resta rt »), ta
connexion active n'est jamais coupée. Avant toute déconne xion, 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 co nnexion
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 d ans
« /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 t unnels 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'i l 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 l imité
comme
shell de connexion).

Sébastien





--001a11353d8630d761051e222556
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>
Je n&#39;ai jamais mis en place la configuration sur laquelle tu planches, mais je<br>
pense pouvoir intervenir sans dire trop de conneries. Prends quand-mêm e tout ça<br>
avec précaution et n&#39;hésite pas à vérifier avant.<b r>
<br>
Tout d&#39;abord sur les modifications dans « sshd_config  » (sur ce point je suis<br>
sûr de moi) :<br>
    - ce qui t&#39;a cassé l&#39;accès est effectivemen t la directive « AllowUsers ». Tu<br>
      n&#39;autorises _que_ ton invité à se connec ter, donc tu ne peux plus te<br>
      connecter.<br>
    - lorsque tu redémarres le serveur SSH (« serv ice ssh restart »), ta<br>
      connexion active n&#39;est jamais coupée. Avant t oute déconnexion, ouvre un<br>
      nouveau terminal et vérifie que tu peux toujours te connecter à ton<br>
      serveur. Si tu n&#39;arrives plus à te connecter, profite de la connexion<br>
      active pour rétablir.<br>
<br>
Vient maintenant la partie de mon intervention que tu devras prendre avec<b r>
précaution.<br>
<span class=""><br>
Le lundi 24 août 2015 à 17:38, Hugues MORIN a écrit :<br>
&gt; 1/ mon intervenant doit pourvoir acceder aux fichierx de mon site (dan s<br>
&gt; /var/www/monsite)<br>
&gt; Si je cree un repertoire monsite dans /home/orthukyn/<br>
&gt; et que je fais un ln -s /var/www/monsite/ /home/orthukyn/monsite/<br>
&gt; Cela vous semble correct afin qu&#39;il puisse y acceder par son reper toire?<br>
<br>
endroit du système de fichiers. Or, si tu enfermes ton utilisateur dan s<br>
« /home/orthukyn/ », il n&#39;aura pas le droit d&#39;a ller dans « /var/www/monsite/ ».<br>
<br>
Tu pourrais contourner ce point :<br>
    - par un montage « bind » de «  /var/www/monsite/ » dans un dossier de<br>
      « /home/orthukyn/ »;<br>
    - en enfermant ton utilisateur dans « /var/www/mons ite/ » (mais<br>
      l&#39;utilisateur ne sera pas propriétaire des fi chiers et risque de ne pas<br>
      pouvoir les modifier).<br>
<span class=""><br>
&gt; 2/ Je suppose qu&#39;il faut que je cree un chroot pour ce user afin d e<br>
&gt; l&#39;enfermer dans son repertoire<br>
&gt; Est ce a l&#39;aide de ces lignes a ajouter dans sshd_config que l&#39 ;on le fait?<br>
&gt; Match user orthukyn<br>
&gt;        ChrootDirectory /home/orthukyn/<br>
<br>
<span class=""><br>
&gt; J&#39;ai pas bien compris a quoi servait:<br>
&gt;        ForceCommand internal-sftp<br>
&gt;        AllowTCPForwarding no<br>
<br>
</span>Je dirais que la première va empêcher l&#39;utilisateur d& #39;accéder à un shell et ne<br>
le laissera faire _que_ du SFTP.<br>
<br>
Quant à la seconde, elle lui empêchera de mettre en place des tun nels SSH [1] et<br>
donc d&#39;exploiter son accès SFTP pour attaquer un équipement q ui serait sur le<br>
LAN du serveur.<br>
<br>
    1: <span class=""><br>
&gt; Est ce qu&#39;elles sont necessaires?<br>
<br>
<span class=""><br>
&gt; Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droi t<br>
&gt; root:root, c&#39;est bien ca?<br>
<br>
<span class=""><br>
&gt; 3/ Avec le meme user/password, mon intervenant peut aussi acceder au s hell<br>
&gt; en ssh.<br>
&gt; J&#39;ai pas tres envie qu&#39;il puisse passer des commandes directem ent dans le<br>
&gt; shell.<br>
<br>
<span class=""><br>
&gt; Un des tuto parle de la commande chsh (chsh debora95dftp -s /bin/true) <br>
&gt; Est ce la solution pour bloquer l&#39;acces au shell avec ce user/pass word?<br>
<br>
connexion (option « --shell » de la commande «  adduser ») pointe vers le script<br>
suivant :<br>
<br>
    #!/bin/sh<br>
<br>
    logger -p authpriv.alert &quot;/!\ Tunnel session opened /! &quot;<br>
    read -p &quot;Restricted shell, press a key to exit...&quot; DUMMY<br>
    exit 0<br>
<br>
Lorsque le compte utilisateur est utilisé pour se connecter :<br>
    - un message est inscrit dans le « syslog  »;<br>
    - un message est affiché à l&#39;utilisateur lui in diquant qu&#39;il ne peut rien<br>
      faire d&#39;autre que d&#39;appuyer sur une touche pou r quitter sa session.<br>
<span class=""><br>
&gt; Pensez vous que ce soit suffisant pour &quot;enfermer&quot; mon interv enant dans son<br>
&gt; repertoire et ne lui permettre une connexion au serveur qu&#39;en SFTP ?<br>
<br>
</span>Personnellement, je combinerais tout ça (configuration SSH, scr ipt limité comme<br>
shell de connexion).<br>
<span class="HOEnZb"><font color="#888888"><br>
Sébastien<br>
<br>
</font></span></blockquote></div><br></div>

--001a11353d8630d761051e222556--
andre_debian
Le #26364427
On Tuesday 25 August 2015 14:48:05 Hugues MORIN wrote:
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 ass ez
compliqué.



SSH/SFTP :
Toujours priviléger les connexions SANS mot de passe.

Il n'est jamais trop tard pour apprendre à utiliser les clés.

Éviter les autres serveurs FTP, car connexions avec mot de passe.

André
juke
Le #26364485
--gubR/AMv6tbKMdmr
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Un rootkit sur ton ordinateur peut capter un mot de passe
et l'envoyer à tierce personne...



Y'a le meme probleme avec un certif non ? Pour ma part c'est surtout pour
limiter le bruteforce.


--gubR/AMv6tbKMdmr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJV3V/yAAoJECtyNpI1DWnpHq8P+gJZLxAqPMR2gYsDCl3jnTIF
xBgOSUTraIGeMvZmeFaZPUEwJoG0rDZsjgdpWgRmNSPj8NG8RG/1ZlaqXtvg4rl8
CF8ZbrkQ0T3UU1lAw0RvdS9mG973z57ZcNlMoSzp8YrqzgbqxEGm1DjiT1fsdHM+
XPN4MDyLHkPkVl9QBrrFF090Xgf+1NuBZ8GJ2JgWf3IpTlyDBahh9n4OXWIoIm2r
r7vwBBS4PsxH+GukkgqNDXHoa3D3H0Xvd2qZ9m29fi+376pbV2xaDjwS5bhDvvop
ndRpipCJg/wgkHpwsGxKDFPpTxXTLpeooLn10wjsvHWWfGGxOR44XK6HBpkG1yJ7
/ENKcv26ltRV++M+NvYcGy4kbU9LsDB2AXCQeB1PMtuwjybrCVKHaQmXbUfXa8tE
CFSg1gS4pWcj8C2WOLU/M3zYzq6AbGws1c+vsdzcXymiFO00p15rE0nWBO9Mpd6c
bZYzF3+ar3jsmQZV++XVUNTwfT3th/Y2k7hUGbtM9w6gXESr08MsCBS16azRranx
Ts3KUwyd+ee0my8WSTyKwFSsnX9eGXMTh2HVRfGHpfk5nf6ECTd/FUulhBJu64AT
lw2F3tosbt3rUM002EOCq5O/xNUureYAsUKIjvz2GQox9EFPgJ/Onk6/Z2pZdw6a
0MF9v3o9iiQkzsii+aJL
=/NH4
-----END PGP SIGNATURE-----

--gubR/AMv6tbKMdmr--
Hugues MORIN
Le #26364520
--047d7bea423e899c47051e35c21d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
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 sui s
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 n i
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

:/etc/ssh# /etc/init.d/ssh restart

:~$ ssh
's password:
Connection to monserver closed by remote host.
Connection to monserver closed.

:~$ sftp
'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
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 c e 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 rest art »), ta
connexion active n'est jamais coupée. Avant toute déconn exion,
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 ave c
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 (dan s
> /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 repertoir e?

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 qu i 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 droi t
> 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 l e
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








--047d7bea423e899c47051e35c21d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>
Je n&#39;ai jamais mis en place la configuration sur laquelle tu planches, mais je<br>
pense pouvoir intervenir sans dire trop de conneries. Prends quand-mêm e tout ça<br>
avec précaution et n&#39;hésite pas à vérifier avant.<b r>
<br>
Tout d&#39;abord sur les modifications dans « sshd_config  » (sur ce point je suis<br>
sûr de moi) :<br>
    - ce qui t&#39;a cassé l&#39;accès est effectivemen t la directive « AllowUsers ». Tu<br>
      n&#39;autorises _que_ ton invité à se connec ter, donc tu ne peux plus te<br>
      connecter.<br>
    - lorsque tu redémarres le serveur SSH (« serv ice ssh restart »), ta<br>
      connexion active n&#39;est jamais coupée. Avant t oute déconnexion, ouvre un<br>
      nouveau terminal et vérifie que tu peux toujours te connecter à ton<br>
      serveur. Si tu n&#39;arrives plus à te connecter, profite de la connexion<br>
      active pour rétablir.<br>
<br>
Vient maintenant la partie de mon intervention que tu devras prendre avec<b r>
précaution.<br>
<span><br>
Le lundi 24 août 2015 à 17:38, Hugues MORIN a écrit :<br>
&gt; 1/ mon intervenant doit pourvoir acceder aux fichierx de mon site (dan s<br>
&gt; /var/www/monsite)<br>
&gt; Si je cree un repertoire monsite dans /home/orthukyn/<br>
&gt; et que je fais un ln -s /var/www/monsite/ /home/orthukyn/monsite/<br>
&gt; Cela vous semble correct afin qu&#39;il puisse y acceder par son reper toire?<br>
<br>
endroit du système de fichiers. Or, si tu enfermes ton utilisateur dan s<br>
« /home/orthukyn/ », il n&#39;aura pas le droit d&#39;a ller dans « /var/www/monsite/ ».<br>
<br>
Tu pourrais contourner ce point :<br>
    - par un montage « bind » de «  /var/www/monsite/ » dans un dossier de<br>
      « /home/orthukyn/ »;<br>
    - en enfermant ton utilisateur dans « /var/www/mons ite/ » (mais<br>
      l&#39;utilisateur ne sera pas propriétaire des fi chiers et risque de ne pas<br>
      pouvoir les modifier).<br>
<span><br>
&gt; 2/ Je suppose qu&#39;il faut que je cree un chroot pour ce user afin d e<br>
&gt; l&#39;enfermer dans son repertoire<br>
&gt; Est ce a l&#39;aide de ces lignes a ajouter dans sshd_config que l&#39 ;on le fait?<br>
&gt; Match user orthukyn<br>
&gt;        ChrootDirectory /home/orthukyn/<br>
<br>
<span><br>
&gt; J&#39;ai pas bien compris a quoi servait:<br>
&gt;        ForceCommand internal-sftp<br>
&gt;        AllowTCPForwarding no<br>
<br>
</span>Je dirais que la première va empêcher l&#39;utilisateur d& #39;accéder à un shell et ne<br>
le laissera faire _que_ du SFTP.<br>
<br>
Quant à la seconde, elle lui empêchera de mettre en place des tun nels SSH [1] et<br>
donc d&#39;exploiter son accès SFTP pour attaquer un équipement q ui serait sur le<br>
LAN du serveur.<br>
<br>
    1: <span><br>
&gt; Est ce qu&#39;elles sont necessaires?<br>
<br>
<span><br>
&gt; Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droi t<br>
&gt; root:root, c&#39;est bien ca?<br>
<br>
<span><br>
&gt; 3/ Avec le meme user/password, mon intervenant peut aussi acceder au s hell<br>
&gt; en ssh.<br>
&gt; J&#39;ai pas tres envie qu&#39;il puisse passer des commandes directem ent dans le<br>
&gt; shell.<br>
<br>
<span><br>
&gt; Un des tuto parle de la commande chsh (chsh debora95dftp -s /bin/true) <br>
&gt; Est ce la solution pour bloquer l&#39;acces au shell avec ce user/pass word?<br>
<br>
connexion (option « --shell » de la commande «  adduser ») pointe vers le script<br>
suivant :<br>
<br>
    #!/bin/sh<br>
<br>
    logger -p authpriv.alert &quot;/!\ Tunnel session opened /! &quot;<br>
    read -p &quot;Restricted shell, press a key to exit...&quot; DUMMY<br>
    exit 0<br>
<br>
Lorsque le compte utilisateur est utilisé pour se connecter :<br>
    - un message est inscrit dans le « syslog  »;<br>
    - un message est affiché à l&#39;utilisateur lui in diquant qu&#39;il ne peut rien<br>
      faire d&#39;autre que d&#39;appuyer sur une touche pou r quitter sa session.<br>
<span><br>
&gt; Pensez vous que ce soit suffisant pour &quot;enfermer&quot; mon interv enant dans son<br>
&gt; repertoire et ne lui permettre une connexion au serveur qu&#39;en SFTP ?<br>
<br>
</span>Personnellement, je combinerais tout ça (configuration SSH, scr ipt limité comme<br>
shell de connexion).<br>
<span><font color="#888888"><br>
Sébastien<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7bea423e899c47051e35c21d--
Hugues MORIN
Le #26364652
--001a11353d86559698051e5f038f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 temporair e

Cordialement
Hugues



Le 26 août 2015 14:12, Hugues MORIN
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 fro m
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
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 (o u
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

:/etc/ssh# /etc/init.d/ssh restart

:~$ ssh
's password:
Connection to monserver closed by remote host.
Connection to monserver closed.

:~$ sftp
'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'es t
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
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 res tart »), ta
connexion active n'est jamais coupée. Avant toute décon nexion,
ouvre un
nouveau terminal et vérifie que tu peux toujours te connecte r à 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 av ec
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 (da ns
> /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 u n 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 risqu e 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 q ui 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 dro it
> 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 dan s
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/passwor d?

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 sessio n.

> Pensez vous que ce soit suffisant pour "enfermer" mon intervenant dan s
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











--001a11353d86559698051e5f038f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>
Je n&#39;ai jamais mis en place la configuration sur laquelle tu planches, mais je<br>
pense pouvoir intervenir sans dire trop de conneries. Prends quand-mêm e tout ça<br>
avec précaution et n&#39;hésite pas à vérifier avant.<b r>
<br>
Tout d&#39;abord sur les modifications dans « sshd_config  » (sur ce point je suis<br>
sûr de moi) :<br>
    - ce qui t&#39;a cassé l&#39;accès est effectivemen t la directive « AllowUsers ». Tu<br>
      n&#39;autorises _que_ ton invité à se connec ter, donc tu ne peux plus te<br>
      connecter.<br>
    - lorsque tu redémarres le serveur SSH (« serv ice ssh restart »), ta<br>
      connexion active n&#39;est jamais coupée. Avant t oute déconnexion, ouvre un<br>
      nouveau terminal et vérifie que tu peux toujours te connecter à ton<br>
      serveur. Si tu n&#39;arrives plus à te connecter, profite de la connexion<br>
      active pour rétablir.<br>
<br>
Vient maintenant la partie de mon intervention que tu devras prendre avec<b r>
précaution.<br>
<span><br>
Le lundi 24 août 2015 à 17:38, Hugues MORIN a écrit :<br>
&gt; 1/ mon intervenant doit pourvoir acceder aux fichierx de mon site (dan s<br>
&gt; /var/www/monsite)<br>
&gt; Si je cree un repertoire monsite dans /home/orthukyn/<br>
&gt; et que je fais un ln -s /var/www/monsite/ /home/orthukyn/monsite/<br>
&gt; Cela vous semble correct afin qu&#39;il puisse y acceder par son reper toire?<br>
<br>
endroit du système de fichiers. Or, si tu enfermes ton utilisateur dan s<br>
« /home/orthukyn/ », il n&#39;aura pas le droit d&#39;a ller dans « /var/www/monsite/ ».<br>
<br>
Tu pourrais contourner ce point :<br>
    - par un montage « bind » de «  /var/www/monsite/ » dans un dossier de<br>
      « /home/orthukyn/ »;<br>
    - en enfermant ton utilisateur dans « /var/www/mons ite/ » (mais<br>
      l&#39;utilisateur ne sera pas propriétaire des fi chiers et risque de ne pas<br>
      pouvoir les modifier).<br>
<span><br>
&gt; 2/ Je suppose qu&#39;il faut que je cree un chroot pour ce user afin d e<br>
&gt; l&#39;enfermer dans son repertoire<br>
&gt; Est ce a l&#39;aide de ces lignes a ajouter dans sshd_config que l&#39 ;on le fait?<br>
&gt; Match user orthukyn<br>
&gt;        ChrootDirectory /home/orthukyn/<br>
<br>
<span><br>
&gt; J&#39;ai pas bien compris a quoi servait:<br>
&gt;        ForceCommand internal-sftp<br>
&gt;        AllowTCPForwarding no<br>
<br>
</span>Je dirais que la première va empêcher l&#39;utilisateur d& #39;accéder à un shell et ne<br>
le laissera faire _que_ du SFTP.<br>
<br>
Quant à la seconde, elle lui empêchera de mettre en place des tun nels SSH [1] et<br>
donc d&#39;exploiter son accès SFTP pour attaquer un équipement q ui serait sur le<br>
LAN du serveur.<br>
<br>
    1: <span><br>
&gt; Est ce qu&#39;elles sont necessaires?<br>
<br>
<span><br>
&gt; Afin que le chroot fonctionne il faut que /home/orthukyn/ est les droi t<br>
&gt; root:root, c&#39;est bien ca?<br>
<br>
<span><br>
&gt; 3/ Avec le meme user/password, mon intervenant peut aussi acceder au s hell<br>
&gt; en ssh.<br>
&gt; J&#39;ai pas tres envie qu&#39;il puisse passer des commandes directem ent dans le<br>
&gt; shell.<br>
<br>
<span><br>
&gt; Un des tuto parle de la commande chsh (chsh debora95dftp -s /bin/true) <br>
&gt; Est ce la solution pour bloquer l&#39;acces au shell avec ce user/pass word?<br>
<br>
connexion (option « --shell » de la commande «  adduser ») pointe vers le script<br>
suivant :<br>
<br>
    #!/bin/sh<br>
<br>
    logger -p authpriv.alert &quot;/!\ Tunnel session opened /! &quot;<br>
    read -p &quot;Restricted shell, press a key to exit...&quot; DUMMY<br>
    exit 0<br>
<br>
Lorsque le compte utilisateur est utilisé pour se connecter :<br>
    - un message est inscrit dans le « syslog  »;<br>
    - un message est affiché à l&#39;utilisateur lui in diquant qu&#39;il ne peut rien<br>
      faire d&#39;autre que d&#39;appuyer sur une touche pou r quitter sa session.<br>
<span><br>
&gt; Pensez vous que ce soit suffisant pour &quot;enfermer&quot; mon interv enant dans son<br>
&gt; repertoire et ne lui permettre une connexion au serveur qu&#39;en SFTP ?<br>
<br>
</span>Personnellement, je combinerais tout ça (configuration SSH, scr ipt limité comme<br>
shell de connexion).<br>
<span><font color="#888888"><br>
Sébastien<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a11353d86559698051e5f038f--
Publicité
Poster une réponse
Anonyme