Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#44691 - sshd.socket's port isn't updated on sshd_config port change

Attached to Project: Arch Linux
Opened by David John (x89) - Wednesday, 22 April 2015, 16:20 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 22 April 2015, 17:34 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: If you change Port from 22 to something else in /etc/ssh/sshd_config the change isn't reflected in the systemd socket.

Steps to reproduce: Change port in sshd_config, stop sshd.service, start sshd.socket, attempt to connect.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Wednesday, 22 April 2015, 17:34 GMT
Reason for closing:  Not a bug
Comment by Gaetan Bisson (vesath) - Wednesday, 22 April 2015, 16:38 GMT
How do you propose this change be reflected in the socket file?
Comment by David John (x89) - Wednesday, 22 April 2015, 16:50 GMT
I can think of a couple of ways but none of them are very pretty.
It'd be possible on sshd.service start/stop.
Is there a way to add to the sshd.service unit file a dependency update / script call on case of a changed file? I'm not sure if there is?

I'll look more into doing it in a 100% systemd way later on, a bit busy at the moment.
Comment by Gaetan Bisson (vesath) - Wednesday, 22 April 2015, 17:19 GMT
It seems to me that if you modify one of the configuration files (say, sshd_config) you should update others accordingly (say, sshd.socket).

Even if systemd has a way to parse sshd_config and use the resulting Port variable in sshd.socket, how should we handle the case of other configuration settings from sshd_config? I really doubt we want to go down that road.
Comment by David John (x89) - Wednesday, 22 April 2015, 17:28 GMT
Perhaps a comment in the default sshd_config just pointing to the socket might be nice then? It would have saved me a few minutes, might save some others the same.
But yeah I agree it's probably a bad path to go down.
Comment by Gaetan Bisson (vesath) - Wednesday, 22 April 2015, 17:34 GMT
Our sshd_config is straight from upstream. I'd argue that if you enabled sshd.socket yourself then you should be aware of its settings. So it seems to me the best place to document this is the wiki.

Loading...