(re) sftp ne se connecte pas (autres)

Support Debian
#1

j’ai fait comme micp me l’a enseigné dans un autre thread :
daniel@localhost:~$ sftp -v -P 666 jessie@localhost
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [::1] port 666.
debug1: Connection established.
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 08:63:7a:13:7d:93:6a:1a:b1:b5:26:8a:d4:2e:b0:9a
debug1: Host ‘[localhost]:666’ is known and matches the ECDSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/daniel/.ssh/id_rsa
debug1: Trying private key: /home/daniel/.ssh/id_dsa
debug1: Trying private key: /home/daniel/.ssh/id_ecdsa
debug1: Next authentication method: password
jessie@localhost’s password:
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:666).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_CA.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 1864, received 1600 bytes, in 0.0 seconds
Bytes per second: sent 70056.7, received 60134.5
debug1: Exit status 1
Connection closed
poursuivi avec :
daniel@localhost:~$ cat /etc/rssh.conf
logfacility = LOG_USER
allowsftp
umask = 022
rendu ici, je refait les étapes du tuto sur le wiki (car je me suis rendu compte que le cat ci-dessus ne donnait pas le chrootpath :

chmod u+s /usr/lib/rssh/rssh_chroot_helper

Ajouter ligne chrootpath /home/sftp dans rssh.conf

echo ‘chrootpath = “/home/sftp”’ >> /etc/rssh.conf

daniel@localhost:~$ sftp -P 666 thorhyeux@localhost
thorhyeux@localhost’s password:
Connection closed
daniel@localhost:~$ cat /etc/rssh.conf
logfacility = LOG_USER
allowsftp
umask = 022
chrootpath = “/home/sftp”

ensuite :
daniel@localhost:~$ ls -R /home/sftp
/home/sftp:
dev etc lib lib64 usr

/home/sftp/dev:
log null (rem. : log et null??)

/home/sftp/etc:
passwd

/home/sftp/lib:
x86_64-linux-gnu

/home/sftp/lib/x86_64-linux-gnu:
libbsd.so.0 libc.so.6 libnss_files.so.2 libtinfo.so.5

/home/sftp/lib64:
ld-linux-x86-64.so.2

/home/sftp/usr:
bin lib

/home/sftp/usr/bin:
sftp

/home/sftp/usr/lib:
openssh x86_64-linux-gnu

/home/sftp/usr/lib/openssh:
sftp-server

/home/sftp/usr/lib/x86_64-linux-gnu:
libedit.so.2

et ensuite ceci :
daniel@localhost:~$ ls -1 /home/sftp/dev /usr/lib/rssh/rssh_chroot_helper /home/sftp/etc/passwd
/home/sftp/etc/passwd
/usr/lib/rssh/rssh_chroot_helper

/home/sftp/dev:
log
null

j’ai tenté de tout comprendre mais < partir ls -R /home/sftp et ls -s /home/sftp/dev /usr/lib/rssh/rssh_chroot_helper /home/sftp/etc/passwd, les réponses sont trop différentes (ce que je m’explique mal c’est pourquoi ces données auraient changé alors que je n’ai fais aucunes manipulations dessus) bref, cela fonctionnait vendredi mais aujourd’hui c’est le capharnaum
si quelqun pouvait me débrouillé ça j’apprécierais
merci

#2

Bonjour

J’ai relu tous les messages que tu as posté dans ce forum,
et je me suis aperçu que :
tu as parfois utilisé la balise “Quote”,
mais tu n’a encore jamais utilisé la balise “Code” (boutons en haut de la fenêtre d’édition des messages).

Fait un essais en utilisant la balise “Quote” pour reformater ton message précédent,
et utilise le bouton “Aperçu” pour voir ce que ça donne.

Ensuite, relis ce que tu as écrit en essayant de te mettre à la place du lecteur.

En espérant qu’il finisse par être plus facile à lire
et donc peut-être à comprendre.

Dans l’état actuel, ton post est impossible à lire.

Merci

#3

j’ai fait comme micp me l’a enseigné dans un autre thread :

voila ce que ça donne :
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [::1] port 666.
debug1: Connection established.
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 08:63:7a:13:7d:93:6a:1a:b1:b5:26:8a:d4:2e:b0:9a
debug1: Host ‘[localhost]:666’ is known and matches the ECDSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/daniel/.ssh/id_rsa
debug1: Trying private key: /home/daniel/.ssh/id_dsa
debug1: Trying private key: /home/daniel/.ssh/id_ecdsa
debug1: Next authentication method: password
jessie@localhost’s password:
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:666).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_CA.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 1864, received 1600 bytes, in 0.0 seconds
Bytes per second: sent 70056.7, received 60134.5
debug1: Exit status 1
Connection closed

poursuivi avec :

cela donne :
logfacility = LOG_USER
allowsftp
umask = 022

rendu ici, je refait les étapes du tuto sur le wiki (car je me suis rendu compte que le cat ci-dessus ne donnait pas le chrootpath :

[quote]# chmod u+s /usr/lib/rssh/rssh_chroot_helper

Ajouter ligne chrootpath /home/sftp dans rssh.conf

echo ‘chrootpath = “/home/sftp”’ >> /etc/rssh.conf[/quote]

donc je refais un cat pour ètre sur que chroot est dans mon rssh.conf :

daniel@localhost:~$ sftp -P 666 thorhyeux@localhost
thorhyeux@localhost’s password:
Connection closed
daniel@localhost:~$ cat /etc/rssh.conf
logfacility = LOG_USER
allowsftp
umask = 022
chrootpath = “/home/sftp”

ensuite :

donne ceci :

dev etc lib lib64 usr

/home/sftp/dev:
log null

/home/sftp/etc:
passwd

/home/sftp/lib:
x86_64-linux-gnu

/home/sftp/lib/x86_64-linux-gnu:
libbsd.so.0 libc.so.6 libnss_files.so.2 libtinfo.so.5

/home/sftp/lib64:
ld-linux-x86-64.so.2

/home/sftp/usr:
bin lib

/home/sftp/usr/bin:
sftp

/home/sftp/usr/lib:
openssh x86_64-linux-gnu

/home/sftp/usr/lib/openssh:
sftp-server

/home/sftp/usr/lib/x86_64-linux-gnu:
libedit.so.2

et ensuite ceci :

voici ce que ça donne :
/home/sftp/etc/passwd
/usr/lib/rssh/rssh_chroot_helper

/home/sftp/dev:
log
null

j’ai tenté de tout comprendre mais à partir de ls -R /home/sftp et ls -s /home/sftp/dev /usr/lib/rssh/rssh_chroot_helper /home/sftp/etc/passwd, les réponses sont trop différentes (ce que je m’explique mal c’est pourquoi ces données auraient changé alors que je n’ai fais aucunes manipulations dessus) bref, cela fonctionnait vendredi mais aujourd’hui c’est le capharnaum
si quelqun pouvait me débrouillé ça j’apprécierais
merci

p.s. : merci micp pour les balises, je n’y pensais tout simplement pas, est-ce plus clair maintenant?

#4

J’apprécie d’autant plus tes efforts en ce qui concerne la mise en forme, que je n’avais pas été très clair dans ma demande.
J’ai dû déraper à:
… Fait un essais en utilisant la balise “[strike]Quote[/strike]” pour reformater ton message précédent, …
car je pensais plutôt à:
… Fait un essais en utilisant la balise “Code” pour reformater ton message précédent, …

Pour être plus clair, voilà ce que j’attendais:
(sans la ligne de “=” suivante bien sûr).

===============================================
j’ai fait comme micp me l’a enseigné dans un autre thread :

daniel@localhost:~$ sftp -v -P 666 jessie@localhost
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [::1] port 666.
debug1: Connection established.
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 08:63:7a:13:7d:93:6a:1a:b1:b5:26:8a:d4:2e:b0:9a
debug1: Host '[localhost]:666' is known and matches the ECDSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/daniel/.ssh/id_rsa
debug1: Trying private key: /home/daniel/.ssh/id_dsa
debug1: Trying private key: /home/daniel/.ssh/id_ecdsa
debug1: Next authentication method: password
jessie@localhost's password:
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:666).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_CA.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 1864, received 1600 bytes, in 0.0 seconds
Bytes per second: sent 70056.7, received 60134.5
debug1: Exit status 1
Connection closed

poursuivi avec :

daniel@localhost:~$ cat /etc/rssh.conf
logfacility = LOG_USER
allowsftp
umask = 022

rendu ici, je refait les étapes du tuto sur le wiki (car je me suis rendu compte que le cat ci-dessus ne donnait pas le chrootpath :

[quote=“tuto du WiKi”]# chmod u+s /usr/lib/rssh/rssh_chroot_helper

Ajouter ligne chrootpath /home/sftp dans rssh.conf

echo ‘chrootpath = “/home/sftp”’ >> /etc/rssh.conf

[/quote]

daniel@localhost:~$ sftp -P 666 thorhyeux@localhost
thorhyeux@localhost's password:
Connection closed
daniel@localhost:~$ cat /etc/rssh.conf
logfacility = LOG_USER
allowsftp
umask = 022
chrootpath = "/home/sftp"

ensuite :

daniel@localhost:~$ ls -R /home/sftp
/home/sftp:
dev etc lib lib64 usr

/home/sftp/dev:
log null (rem. : log et null??)

/home/sftp/etc:
passwd

/home/sftp/lib:
x86_64-linux-gnu

/home/sftp/lib/x86_64-linux-gnu:
libbsd.so.0 libc.so.6 libnss_files.so.2 libtinfo.so.5

/home/sftp/lib64:
ld-linux-x86-64.so.2

/home/sftp/usr:
bin lib

/home/sftp/usr/bin:
sftp

/home/sftp/usr/lib:
openssh x86_64-linux-gnu

/home/sftp/usr/lib/openssh:
sftp-server

/home/sftp/usr/lib/x86_64-linux-gnu:
libedit.so.2

et ensuite ceci :

daniel@localhost:~$ ls -1 /home/sftp/dev /usr/lib/rssh/rssh_chroot_helper /home/sftp/etc/passwd
/home/sftp/etc/passwd
/usr/lib/rssh/rssh_chroot_helper

/home/sftp/dev:
log
null

j’ai tenté de tout comprendre mais < partir

et

, les réponses sont trop différentes
(ce que je m’explique mal c’est pourquoi ces données auraient changé alors que je n’ai fais aucunes manipulations dessus)

bref, cela fonctionnait vendredi mais aujourd’hui c’est le capharnaum

si quelqun pouvait me débrouillé ça j’apprécierais

merci

#5

Après la citation du “du tuto sur le wiki”, je comprends plus très bien ce qui se passe.
À moins que tu n’ai appliqué le tuto du wiki,
ensuite fait une tentative de connexion infructueuse, (vouée à l’échec étant donné que tu n’avais pas relancé le serveur “sftp” après avoir modifié son fichier de configuration)
puis fait un “cat /etc/rssh.conf”

============================
Ensuite tu fait un
daniel@localhost:~$ ls -R /home/sftp /home/sftp:
Ok mais évite de rajouter “:” à la fin de la ligne de commande quand tu la recopie,
je viens juste de comprendre que tu l’avais rajouté après avoir collé le texte.
Il y a deux fois de suite “/home/sftp” d’ailleurs, ce qui ne corresponds plus au premmier post, ni au retour de la commande qui suit (qui aurait donc dû être deux fois de suite la même sortie).

Tu as sans doute inséré une remarque dans le retour de cette ligne de commande :

[code]daniel@localhost:~$ ls -R /home/sftp
/home/sftp:
dev etc lib lib64 usr

/home/sftp/dev:
log null (rem. : log et null??)
[/code]
J’ai passé un très long moment avant d’être sûr et certain que “(rem. : log et null??)” ne pouvait pas être un extrait du retour de la commande précédente:

mais qu’il devait très certainement s’agir d’une remarque que tu avais ajouté dans le post après le copié/collé du retour de la commande.

Dans ce cas là, il vaut mieux répéter l’extrait à mettre en évidence à la suite de la remarque,
formulée de la façon la plus détaillée et explicite que possible (un ou plusieurs “?”, ça peux “tout” vouloir dire…).
Comme par exemple:
Que font “Log et null” ici ?

... /home/sftp/dev: log null ...
En résumé, il est donc préférable de ne pas “polluer” les retours de commandes en les modifiant pour ajouter une remarque.

======================
De plus, comme tu le constate toi même (vu que tu t’interroge au sujet de “log” et “null”),
avec l’option “-R” de la commande “ls”,
on ne peut pas savoir de quel type de fichier il s’agit,
ni quels sont ces attributs (droits, propriétaire, groupe),
ni ses attributs de date/heure.

En rajoutant l’option “l” (“L” minuscule) nous aurions donc pu obtenir plus d’informations sur tous ces fichiers :

Pour répondre à ton interrogation “(rem. : log et null??)” :
Pour “log”, relis la première ligne qui suit ce lien (rsyslog).
Pour “dev”, tu as, dans le Tuto du WiKi, à “Création du chroot”, l’extrait suivant:

=======================

C’est tout-a fait étrange qu’un fichier ait pu “se” modifier comme ça.
Les dates de création, accès et modifications pourraient apporter des informations intéressantes mais maintenant, ils ont été re-modifiés… donc les dates ne nous diront plus rien.

Voir aussi les fichiers “log” du serveur.

#6

merci
je réinstall à partir de zéro ce seras moin compliqué que de démèleé ce que j’ai fais ou pas :blush: