Description of problem: Following update today, remote users can no longer connect. # systemctl restart sshd.service Job for sshd.service failed because the control process exited with error code. See "systemctl status sshd.service" and "journalctl -xeu sshd.service" for details. # systemctl status sshd.service ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Tue 2024-07-02 21:55:06 EDT; 40s ago Docs: man:sshd(8) man:sshd_config(5) Process: 272545 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255/EXCEPTION) Main PID: 272545 (code=exited, status=255/EXCEPTION) CPU: 2ms # journalctl -xeu sshd.service [...] sshd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS [...] /etc/crypto-policies/back-ends/opensshserver.config: line 3: Bad configuration option: GSSAPIKexAlgorithms /etc/crypto-policies/back-ends/opensshserver.config: terminating, 1 bad configuration options sshd.service: Main process exited, code=exited, status=255/EXCEPTION [...] Version-Release number of selected component (if applicable): openssh-server-9.8p1-2.mga10.x86_64 openssh-9.8p1-2.mga10.x86_64 How reproducible: always Steps to Reproduce: 1. apply sshd updates 2. 3.
See https://ml.mageia.org/l/arc/dev/2024-07/msg00001.html
Assignee: bugsquad => pkg-bugsCC: (none) => fri
Assignee: pkg-bugs => mageiaCC: (none) => mageia
Thanks. Maybe we patch crypto-policies, or we patch openssh. We have to decide which way to go.
From discuss mailing list: On Tue, 02 Jul 2024 23:29:50 -0400 Liam R E Quin wrote: >On Tue, 2024-07-02 at 22:25 -0400, Pierre Fortin wrote: >> >> /etc/crypto-policies/back-ends/opensshserver.config: line 3: Bad >> configuration option: GSSAPIKexAlgorithms > >This suggests that openssh was built without a patch to support >GSSAPIKexAlgorithms > >You could delete that line from that file, or comment it out with a # >probably. Commenting did the trick... THANKS!!! MUCH appreciated. Pierre >liam (ankh/demib0y)
(In reply to Marc Krämer from comment #2) > Thanks. Maybe we patch crypto-policies, or we patch openssh. > We have to decide which way to go. I have created a patch for crypto-policies to drop GSSAPI. I can push it with latest crypto-policies. I think it's easiest way ATM.
CC: (none) => jani.valimaa
ok. why not, if U agree, we really don't need them. What is my outcome of it, that would make packaging openssh much easier (I think it is ~6 patches concerning GSSAPI).
I don't think that I can say what is the correct way, but at least new crypto-policies makes possible to run ssh server with openssh-9.8p1-1.mga10 and newer. And if someone complains about missing GSSAPI support it can be readded.
So, please test crypto-policies-20240628-1.mga10 with openssh-9.8p1-2.mga10.
For updates we must ensure crypto-policies gets updated before openssh-server or otherwise update will cause non-working ssh server.
CC: (none) => cooker
atm openssh does not require crypto-policies. The only way to ensure this, would be setting a (temporary requirement) for the newer policy
I think openssh-client and openssh-server should require crypto-policies anyway if we want to ensure that our crypto policies are followed. In update case requirement should be probably also Requires(post). Smooth updates needs (local) testing.
Moved Requires(post) in openssh-9.8p1-4.mga10 to openssh-client and openssh-server for better pkg ordering when updating. Added also requires for crypto-policies to same pkgs. At least in my local tests update from mga9 to current Cauldron with ssh server installed and running went smoothly (if we don't count the known RPM signing key issue).
Source RPM: openssh-server-9.8p1-2.mga10.x86_64 openssh-9.8p1-2.mga10.x86_64 => openssh-9.8p1-1.mga10.src.rpm
Applied the updates; now, I have an additional issue... /etc/ssh/ssh_config and /etc/ssh/sshd_config changes at least gave me the option NOT to be updated. On closer examination, the *.rpmnew files are from the July 2 updates that triggered this report. So the update process' request to update these files was denied on July 2; but a new update on July 8 asked again for permission to use the July 2 rpmnew files... These should be removed if denied; not left to bite the user later. The reason for not using the rpmnew files (especially the sshd) is that I would have lost the special handling for a particular user; and X11Forwarding. Not nice! The attempted changes were: /etc/ssh/ssh_config: (diff) 20c20 < Host * --- > # Host * /etc/ssh/sshd_config: (diff) 91c91 < X11Forwarding yes --- > #X11Forwarding no 93c93 < X11UseLocalhost no --- > #X11UseLocalhost yes 113,115c113 < Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO < < PasswordAuthentication yes # 20240117 --- > Subsystem sftp /usr/libexec/openssh/sftp-server 123,130d120 < PubkeyAuthentication yes < < Match Group ncdt User !user < PasswordAuthentication yes < Match User user < PasswordAuthentication yes < < PermitRootLogin without-password
Please open a separate bug report if there is something else. There are always two sides. Some other people might especially want to keep the .rpmnew files for later usage. The recommended way is to use /etc/ssh/ssh_config.d/ and /etc/ssh/sshd_config.d/ snippets to alter the defaults. Then the distro provided configs will always stay untouched, and no .rpmnew files are created. However sysadmin needs to be then aware of possible changes in configs when new version gets installed.
closing as fixed
Resolution: (none) => FIXEDStatus: NEW => RESOLVED