Summary
bssh-server in v2.1.1 incorrectly prepends the user's home directory to absolute paths when receiving files via SCP, causing file creation failures. The same path-handling issue also affects bssh upload (SFTP path).
Environment
- bssh / bssh-server: v2.1.1 (
linux-x86_64-musl build)
- Client: OpenSSH
scp (8.x, stock Ubuntu 22.04 LTS)
- Client:
bssh upload (v2.1.1)
- Server OS: container running Ubuntu 20.04 / 22.04 / 24.04
- Server process is started as
root inside the container; session user is work with home /home/work
Reproduction
-
Generate a host key and start bssh-server:
/tmp/bssh-server gen-host-key --output /tmp/bssh_host_key -t ed25519
/tmp/bssh-server run -b 0.0.0.0 -p 2200 -k /tmp/bssh_host_key -D
-
From a client, upload a file via SCP to an absolute path:
scp -i id_container -P 2200 file.bin work@HOST:/home/work/file.bin
# or
scp -i id_container -P 2200 file.bin work@HOST:/tmp/file.bin
-
The transfer fails with lost connection, and the server log shows the actual failure:
bssh::server::scp: Error receiving file:
Failed to create file: /home/work/home/work/testfile.1010685/testfile_1G
bssh::server::scp: SCP session failed user=work mode=sink
error=Failed to create file: /home/work/home/work/testfile.1010685/testfile_1G
Observed behavior
-
The destination path becomes `$HOME + absolute_destination + source_filename`, e.g. for a client destination `/home/work/testfile.1010685`, the server tries to create `/home/work/home/work/testfile.1010685/testfile_1G`.
-
Two independent issues are visible here:
- The user's home directory is prepended even when the client sent an absolute path.
- The source filename is appended even when the destination was meant to be a file (not a directory).
-
The same destination-path bug happens via SFTP (bssh upload):
SFTP error occured: No such file: No such file: No such file: No such file
Expected behavior
- Absolute destination paths sent by the client (
/tmp/foo, /home/work/foo) should be used verbatim.
- When the client's destination is a file path, the source filename should not be appended to it.
Impact
bssh-server cannot be used as a drop-in replacement for OpenSSH / dropbear in Backend.AI session containers: all standard Backend.AI tooling and the WebUI's "Download SSH key / SCP example" snippet use absolute paths.
- Affects both the legacy SCP protocol and the SFTP subsystem.
Workaround (unverified)
Testing with relative destination paths (e.g. testfile.bin instead of /home/work/testfile.bin) appears to behave differently, but we have not yet confirmed whether the transfer actually succeeds end-to-end.
Additional logs
$ /tmp/bssh-server run -b 0.0.0.0 -p 2200 -k /tmp/bssh_host_key -D
WARN bssh_server: No configuration file found, using defaults
ERROR bssh::server::scp: Error receiving file: Failed to create file: /home/work/home/work/testfile.1010685/testfile_1G
ERROR bssh::server::scp: SCP session failed user=work mode=sink error=Failed to create file: /home/work/home/work/testfile.1010685/testfile_1G
ERROR bssh::server::scp: Error receiving file: Failed to create file: /home/work/home/work/test.bssh/testfile_1G
ERROR bssh::server::scp: SCP session failed user=work mode=sink error=Failed to create file: /home/work/home/work/test.bssh/testfile_1G
ERROR bssh::server: Session error error=early eof
Summary
bssh-serverin v2.1.1 incorrectly prepends the user's home directory to absolute paths when receiving files via SCP, causing file creation failures. The same path-handling issue also affectsbssh upload(SFTP path).Environment
linux-x86_64-muslbuild)scp(8.x, stock Ubuntu 22.04 LTS)bssh upload(v2.1.1)rootinside the container; session user isworkwith home/home/workReproduction
Generate a host key and start
bssh-server:From a client, upload a file via SCP to an absolute path:
scp -i id_container -P 2200 file.bin work@HOST:/home/work/file.bin # or scp -i id_container -P 2200 file.bin work@HOST:/tmp/file.binThe transfer fails with
lost connection, and the server log shows the actual failure:Observed behavior
The destination path becomes `$HOME + absolute_destination + source_filename`, e.g. for a client destination `/home/work/testfile.1010685`, the server tries to create `/home/work/home/work/testfile.1010685/testfile_1G`.
Two independent issues are visible here:
The same destination-path bug happens via SFTP (
bssh upload):Expected behavior
/tmp/foo,/home/work/foo) should be used verbatim.Impact
bssh-servercannot be used as a drop-in replacement for OpenSSH / dropbear in Backend.AI session containers: all standard Backend.AI tooling and the WebUI's "Download SSH key / SCP example" snippet use absolute paths.Workaround (unverified)
Testing with relative destination paths (e.g.
testfile.bininstead of/home/work/testfile.bin) appears to behave differently, but we have not yet confirmed whether the transfer actually succeeds end-to-end.Additional logs