Hi Stephan,
This morning, I am sorry, I cannot reproduce the bug anymore, but I am
pretty sure to have used the same account yesterday.
Since I have modified my ssh server config during the time, I'll try to
reproduce it later, in the same conditions.
Kind regards,
André Rodier.
Login process:
andre@arcadia:~$ sftp -o
PubkeyAuthentication=no user1@transfer.myred2.com
user1@transfer.myred2.com's
password:
Connected to transfer.myred2.com.
sftp> ls
sftp> pwd
Remote working directory: /
Jun 20 08:53:08 transfer sshd[4968]: debug1:
Forked child 4975.
Jun 20 08:53:08 transfer sshd[4975]: debug1: rexec start in 5 out 5
newsock 5 pipe 7 sock 8
Jun 20 08:53:08 transfer sshd[4975]: debug1: inetd sockets after
dupping: 3, 3
Jun 20 08:53:08 transfer sshd[4975]: Connection from 213.107.190.212
port 41913
Jun 20 08:53:08 transfer sshd[4975]: debug1: Client protocol version
2.0; client software version OpenSSH_5.5p1 Debian-4
Jun 20 08:53:08 transfer sshd[4975]: debug1: match: OpenSSH_5.5p1
Debian-4 pat OpenSSH*
Jun 20 08:53:08 transfer sshd[4975]: debug1: Enabling compatibility
mode for protocol 2.0
Jun 20 08:53:08 transfer sshd[4975]: debug1: Local version string
SSH-2.0-OpenSSH_5.1p1 Debian-5
Jun 20 08:53:08 transfer sshd[4975]: debug1: user user1 matched group
list sftponly at line 81
Jun 20 08:53:08 transfer sshd[4975]: Failed none for user1 from
213.107.190.212 port 41913 ssh2
Jun 20 08:53:13 transfer sshd[4975]: Accepted password for user1 from
213.107.190.212 port 41913 ssh2
Jun 20 08:53:13 transfer sshd[4975]: debug1: monitor_child_preauth:
user1 has been authenticated by privileged process
Jun 20 08:53:13 transfer sshd[4977]: debug1: SELinux support disabled
Jun 20 08:53:13 transfer sshd[4975]: User child is on pid 4977
Jun 20 08:54:10 transfer sshd[4975]: debug1: do_cleanup
On 20/06/10 08:32, Stefan Fritsch wrote:
On Saturday 19 June 2010, you wrote:
However, if I use the fish protocol [1] included in midnight
commander, I can see the full filesystem hierarchy, and even
transfer files from the etc folder, etc...
Subsystem sftp internal-sftp
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ForceCommand internal-sftp
fish does not work at all with ForceCommand and it won't work with
ChrootDirectory unless you copy lots of things into the chroot (/lib
/bin ...).
Have you used the same user for your fish and sftp tests? Please
verify in /var/log/auth.log that you really did.
|