After update from mga5 to mga6 sftp does not work, machine is not accesible via sftp even after successful login (ssh is working). $ sftp -vvv zzzzz.zzzzz.cz OpenSSH_6.6, OpenSSL 1.0.2k 26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to s1119-calimero.vscht.cz [147.33.228.18] port 22. debug1: Connection established. ... Password: debug3: packet_send2: adding 32 (len 16 padlen 16 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug3: packet_send2: adding 48 (len 6 padlen 10 extra_pad 64) debug1: Authentication succeeded (keyboard-interactive). Authenticated to zzzzzzzzz.zzzzz.cz ([ZZZ.ZZ.ZZZ.ZZ]:22). ... Transferred: sent 2604, received 2852 bytes, in 0.0 seconds Bytes per second: sent 53027.2, received 58077.5 debug1: Exit status 127 Connection closed The error was in /etc/ssh/sshd_config: # override default of no subsystems Subsystem sftp /usr/lib64/ssh/sftp-server I overwrited to: # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server After restart of sshd, sftp works. Steps to Reproduce: 1. Update from fully updated mga5 to mga6 via network. 2. Try to access your machine via sftp from other machines.
The sftp-server file did indeed move between Mga5 and Mga6 versions of openssh-server <marja> :findfile -v5 /usr/lib64/ssh/sftp-server <Sophie> find in (Mga, 5, x86_64) : openssh-server <marja> :findfile -v6 /usr/lib64/ssh/sftp-server <Sophie> Sorry, no file /usr/lib64/ssh/sftp-server found in (Mga, 6, x86_64) <marja> :findfile -v5 /usr/libexec/openssh/sftp-server <Sophie> Sorry, no file /usr/libexec/openssh/sftp-server found in (Mga, 5,.. <marja> :findfile -v6 /usr/libexec/openssh/sftp-server <Sophie> find in (Mga, 6, x86_64) : openssh-server Assigning to our registered openssh maintainer
CC: (none) => marja11Assignee: bugsquad => guillomovitchEver confirmed: 0 => 1Status: UNCONFIRMED => NEWSource RPM: (none) => openssh
I'd say it's not a bug. /etc/ssh/sshd_config is installed as /etc/ssh/sshd_config.rpmnew during upgrade. It's up to the system administrator to diff current conf against the new one and apply changes if needed.
CC: (none) => mageia
That's true. For a case like this, it probably wouldn't hurt to have a install trigger that replaces the old value if it's in your config.
See Also: https://bugs.mageia.org/show_bug.cgi?id=21255
CC: (none) => j.alberto.vc
First, that's not the first time an executable change location between release, especially since we started to use /usr/libexec path. Second, I'm not confortable with the idea of automatically changing content of configuration files after initial installation, even with the best intent, as it seems far most susceptible to cause unexpected troubles for everybody than anything else. Users have been expected to review configuration changes after update since the beginning of the distribution (they are even tools to make this easier), why should we change this assumption now ?
Closing as wontfix.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
WorkArround https://bugs.mageia.org/show_bug.cgi?id=21255#c1
Blocks: (none) => 21340
*** Bug 22340 has been marked as a duplicate of this bug. ***
CC: (none) => zen25000
Added to erratas due bug#22340
Keywords: (none) => IN_ERRATA6