SCP exits with code 127 with openSUSE Leap 16 on server side

[fwinn]

I just upgraded from Leap 15.6 to 16.0.

I’m now trying to send some files from my PC to my openSUSE Leap 16.0 server.
The SSH connection is established just fine, but the files are not sent. It exits with status 127

This is some of the output of scp -v test.txt finn@example.com:/home/finn on the client:

debug1: Offering public key: /home/finn/.ssh/... explicit
debug1: Server accepts key: /home/finn/.ssh/...
Authenticated to example.com ([]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Remote: /home/finn/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/finn/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending subsystem: sftp
debug1: pledge: fork
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
Transferred: sent 3500, received 3096 bytes, in 0.2 seconds
Bytes per second: sent 16750.0, received 14816.6
debug1: Exit status 127
scp: Connection closed

Output from the server:

sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: active (running) since Fri 2025-12-19 22:16:25 UTC; 1h 9min ago
 Invocation: ...
    Process: 1881 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
    Process: 1965 ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS (code=exited, status=0/SUCCESS)
   Main PID: 2232 (sshd)
      Tasks: 1
        CPU: 17.534s
     CGroup: /system.slice/sshd.service
             └─2232 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

[...]
Dec 19 23:25:49 hostname sshd-session[40878]: Accepted publickey for finn from ... port 60828 ssh2: RSA ...
Dec 19 23:25:49 hostname sshd-session[40878]: pam_unix(sshd:session): session opened for user finn(uid=1000) by finn(uid=0)
Dec 19 23:25:49 hostname sshd-session[40878]: pam_unix(sshd:session): session closed for user finn

I tried it with an Arch Linux and an openSUSE Tumbleweed client, both with OpenSSH version 10.2p1, the result is similar.

The server is running openSSH version 10.0p2

Both sftp and ssh are known commands to the server.

Does anyone have an idea?

[GrandDixence2]

# scp -O -v test.txt finn@example.com:/home/finn/

 -O      Use the legacy SCP protocol for file transfers instead of the SFTP protocol.  Forcing the use of the SCP protocol may be necessary for servers that do not implement SFTP, for backwards-compat-
             ibility for particular filename wildcard patterns and for expanding paths with a ‘~’ prefix for older SFTP servers.

Can connect via SSH - but not via SFTP? Exit status 127

[malcolmlewis]

@fwinn what is the debug for the previous 10 lines from debug1: Offering public key: /home/finn/.ssh/... explicit are you using ED25519?

[rawar]

It is just a guess but it seems to me that the sshd is not able to execute the sftp-server process. The following command executed on the Leap server shows the path of the sftp-server:

# sshd -T|grep sftp
subsystem sftp /usr/libexec/ssh/sftp-server

Check if the sftp-server binary is executable. If you migrated to selinux you might also check with

# ausearch -ts boot -m avc

if there is a selinux related problem.

[fwinn]

This was the solution. The sftp-server executable moved from /usr/lib/ssh/sftp-server to /usr/libexec/ssh/sftp-server so I had to edit the subsystem sftp line accordingly in the server side /etc/ssh/sshd_config.
Thank you!

[rawar]

The sshd default configuration file in Leap 16 is now located in /usr/etc/ssh/sshd_config. The /etc/ssh/ file should only be used for system-specific changes. This is likely the root cause of the problem. If no other modifications have been made to your /etc/ssh/sshd_config file, I recommend simply removing it.