Bonjour à tous,

J'utilise SFTP et RSSH pour effectuer mes connexions FTP. J'arrive a me connecter avec un utilisateur normal sans probleme.
Cependant impossible de me connecter avec un utilisateur chrooté, apres avoir saisis le MDP je suis deconecté automatiquement.

J'ai suivi le tuto suivant pour configurer SFTP et RSSH : http://www.trustonme.net/didactels/318.html

lorsque je tape la commande : # sftp -v -v clems@localhost 
[Clement@localhost ~]$ sftp -v clems@localhost
Connecting to localhost...
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/Clement/.ssh/id_rsa type -1
debug1: identity file /home/Clement/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/Clement/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Next authentication method: publickey
debug1: Trying private key: /home/Clement/.ssh/id_rsa
debug1: Trying private key: /home/Clement/.ssh/id_dsa
debug1: Next authentication method: password
clems@localhost's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 127
Connection closed
[Clement@localhost ~]$
voici mon fichier de config /etc/ssh/ssh_config : 
# Host *
#   ForwardAgent no
#   ForwardX11 yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
Host *
    GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
    ForwardX11Trusted yes
# Send locale-related environment variables
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
    SendEnv LC_IDENTIFICATION LC_ALL
Voici mon fichier de config /etc/rssh.conf : 
logfacility = LOG_USER 
allowsftp
umask = 022
chrootpath="/home"
Je suis vraiment perdu, je n'arrive pas a utiliser du tout les utilisateurs chrooté, alors si vous pouviez me donner un coup de main ca serait cool !!
Merci
il n'y aurait pas une option à rajouter genre no_root_squash comme avec NFS? je dis ça comme ça car je connais pas plus que ça.
Désolé si je dis une connerie 🙂
Salut il faut éditer le fichier /etc/ssh/sshd_config et éditer la ligne PermitRootLogin à "yes" .
8 jours plus tard
J'ai le même problème.
Apparemment il se connecte mais se déconnecte juste aussitôt :/

cngo : ta solution fonctionne peut-être, j'ai pas essayé mais pas très « secure », permettre l'auth en root, bof ...

EDIT : après avoir testé, permettre l'auth en root ne résout rien.
3 ans plus tard
Bonjour,
as tu réussi à résoudre le problème? ^^
si oui, ta solution pourrait intéresser du monde (moi y compris)

merci 😃
un an plus tard
bonjour
je poste sur ce vieux poste, car je viens de galerer pour gerer mes droits en accès sftp (erreur de manip sur mes droits de dossier) avec mon serveur en F14 .

Dans mes recherches, j'ai trouvé ce lien qui est bien pour mettre simplement un sftp en chroot en place:
http://linuxfr.org/forums/linuxdebianubuntu/posts/mettre-en-place-un-chroot-sftp-sous-lenny

contrairement à plusieurs doc, je n'ais pas installer rssh.
Et ce n'est pas assez dit (je n'ais pas dis que ce n'était pas marqué) dans les docs, que le repertoire de l'utilisateur en sftp doit avoir root comme proprietaire:

chown root /repertoireutilisateur
chmod 700 /repertoireutilisateur

sinon vous aurez un problème de connexion en sftp.
Le problème qui en découle est l'accès en ecriture sur ceux repertoire. L'utilisateur ne peut ecrire due au chmod 700. Il suffit donc de créer un repertoire avec les droits suffisants pour l'utilisateur, et chrooter vers ce repertoire (ChrootDirectory /repertoiredetravail voir le premier lien en debut de mon post). tous le problème, d'accès viens de ce conflit entre les droits root obligatoire pour la connexion en sftp et l'utilisation que l'on veut donner à l'utilisateur se connectant (message: pas d'accès en lecture sur /).

Je poste sur ce message, car j'aurais aimé que la personne qui avait lancé ce poste réponde si il y était arrivé ou non! Ca m'aurais évité de partir dans toute les directions.
Sinon la doc http://doc.fedora-fr.org/wiki/Utilisation_de_chroot n'est pas la solution la plus simple pour chrooter un système! l'utilisation de ssh, en configurant correctement l'utilisateur et /etc/ssh/sshd_config (voir le premier lien en debut de mon post) est beaucoup plus simple et aussi securiser.
Pour finir je trouve cela dommage qu'aucune sortie n'existe, quand on tape sftp dans la recherche de ce site, pour nous rediriger vers des docs proposant du sftp. Mais j'ai déjà parlé de ce genre de soucis de recherche en général dans la doc de fedora-fr il y a plusieurs années..... doc très fournis (pour cette raison que je reste encore un peu sous fedora) mais moteur de recherche parfois faible!

esperant que ces quelque liens puissent aider.
en quoi à tu besoin de lien symbolique pour du internal sftp?

sinon pour du lien symbolique sur dossier:

ln -Fs ledossiercible lenomduliensymbolique


Perso je ne vois aucun avantage à faire la méthode de copie des repertoires systèmes! Je n'ais pas vu de faille de sécurité dûe à l'utilisation d'internal sftp! si quelqu'un vois une limite à ce genre d'utilisation je serais curieux de la connaitre!?