Description of problem: The server in question has a chroot env with a fake /proc to deny attackers, who gained control, to proceed further and check processid's etc. etc. /opt/root/proc/ └── self └── fd ├── 0 -> /dev/pts/0 ├── 1 -> /dev/pts/0 ├── 2 -> /dev/pts/0 └── 3 ├── 0 -> /dev/null └── 9 -> /dev/null 4 directories, 5 files sshd puts anyone except root in this chroot. A none-root user with ssh as client can log into the system and start bash -> op success A none-root user with sftp as client can not log into the system -> op fail At this point we started sshd manually to use strace to dig into it. As long as sshd is not started with at least one "-d" option, sftp keeps failing. As soon as we start sshd with "-d" option, which means debug level 1, sftp can flawlessly log in and use the server inside the chroot as it should be -> op success Conclusion: something besides the obvious log_print() changes inside openssh-server changes to make sftp work. I can not verify IF this is a Fedora only bug due to the many downstream patches or a common bug in all releases. Version-Release number of selected component (if applicable): Name : openssh-server Version : 8.8p1 Release : 10.fc37 Architecture: x86_64 Install Date: Mo 01 Mai 2023 17:54:23 CEST How reproducible: - create a chroot with minimal system and bash - mkdir /chroot/proc mkdir -p /chroot/proc/self/fd/3 ln -s /dev/pts/0 /chroot/proc/self/fd/0 ln -s /dev/pts/0 /chroot/proc/self/fd/1 ln -s /dev/pts/0 /chroot/proc/self/fd/2 ln -s /dev/null /chroot/proc/self/fd/3/0 ln -s /dev/null /chroot/proc/self/fd/3/9 - mount dev to /chroot/dev change your /etc/ssh/sshd_config and add: ChrootDirectory /opt/root/ Match user root ChrootDirectory none now stop sshd and run it manually i.e. on another port: $(which sshd) -D -p 22 $(which sshd) -D -d -p 22 and try sftp to log into your none-root account ( you may need to copy /etc/passwd etc. into the chroot env ) it will fail. O== Wanted solution working sftp without enabling debug mode and without a /proc filesystem (if you have a better idea than the described above, i'm all ear)
Could you please check it against upstream? I don't recall any sftp patches that could cause such behavior.
whats the best build source?
https://www.openssh.com/portable.html - the last one (9.3p1) from any mirrors.
Server# /usr/src/openssh/openssh/sshd -V -D -p 30 OpenSSH_9.3, OpenSSL 3.0.8 7 Feb 2023 Server# /usr/src/openssh/openssh/sshd -D -p 30 Client# sftp -P 30 user@thatserver Connected to thatserver. sftp> ls -la /proc/ dr-xr-xr-x 3 root root 4096 Apr 25 19:53 . drwxr-xr-x 18 root root 4096 Apr 25 14:31 .. drwxr-xr-x 3 root root 4096 Apr 19 15:03 self sftp> exit So the unpatched native openssh-server version works like a charm on a Fedora 37. My Buildline looks like this: ./configure --with-md5-passwords --with-pam --with-selinux --sysconfdir=/etc/ssh and for my stuff, it seems to work. So... do you finally upgrade to 9.3 or do I need to create a replacement rpm for my Fedora Cluster? :D
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.