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
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
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
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?
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?
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?
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.
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.
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.
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 a écrit :
> 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
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 <jeremy@prego-network.net> a écrit :
> 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
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 a écrit :
> 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
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
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
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
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é.
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é.
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é.
Un rootkit sur ton ordinateur peut capter un mot de passe
et l'envoyer à tierce personne...
Un rootkit sur ton ordinateur peut capter un mot de passe
et l'envoyer à tierce personne...
Un rootkit sur ton ordinateur peut capter un mot de passe
et l'envoyer à tierce personne...
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 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 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
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
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 <sebnewsletter@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 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
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 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 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
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 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 (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 > 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 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
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 <morinh@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 (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
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'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 <sebnewsletter@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 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
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 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 (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 > 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 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