This is a regression from ntpd in fc33 Installed Packages: ntp-refclock.x86_64 0.4-3.fc34 ntpsec.x86_64 1.2.0-6.fc34 ntpstat.noarch 0.6-4.fc34 ntpd[1173]: IO: Listening on routing socket on fd #23 for interface updates ntpd[1173]: INIT: ntpd was compiled without refclock support. ntpd[1173]: PROTO: 127.127.1.0 unlink local addr 127.0.0.1 -> <null> ntpd[1173]: INIT: ntpd was compiled without refclock support. ntpd[1173]: PROTO: 127.127.20.0 unlink local addr 127.0.0.1 -> <null> ntpd[1173]: CONFIG: Fudge commands not supported: built without refclocks I've found and installed the 'ntp-refclock' package, but it doesn't seem to help. I don't see any obviously correct packages to install, searching for pps nmea gps refclock...
https://fedoraproject.org/wiki/Changes/NtpReplacement makes no mention of how to make things work.
Downgrading to ntp/ntpdate 4.2.8p15-3.fc33 fixes the problem (unsurprisingly), though along the way it deleted my ntp crypto keys and I had to recover them from backups or regenerate them.
Unpacking the source ntpsec tarball finds the following in INSTALL.adoc: == Optional Features == The waf builder accepts `--enable-FEATURE` options to where FEATURE indicates an optional part of the package. Do `waf --help` for a list of options. refclocks are enabled with `--refclock=<n1,n2,n3..>` or `--refclock=all` `waf configure --list` will print a list of available refclocks. --- So adding --refclock=local,nmea to the ntpsec.spec file and rebuilding. (though perhaps it should just be --refclock=all) This seems to produce a closer to functional package. May 02 23:38:24 mini.lan ntpd[29966]: REFCLOCK: refclock_params: kernel PLL (hardpps, RFC 1589) not implemented May 02 23:38:24 mini.lan ntpd[29966]: REFCLOCK: NMEA(0) set PPSAPI params fails which can be fixed (worked around?) by flipping 'flag3 1' to 'flag3 0' though that seems suboptimal. Presumably this is something missing from ntpsec that was present in fc33 ntpd? --- Note: I also have extra selinux config localntp.te: module localntp 1.0; require { type clock_device_t; type ntpd_t; type tty_device_t; class lnk_file read; class chr_file { open read write ioctl }; } #============= ntpd_t ============== allow ntpd_t tty_device_t:lnk_file read; allow ntpd_t tty_device_t:chr_file { open read write ioctl }; allow ntpd_t clock_device_t:lnk_file read; allow ntpd_t clock_device_t:chr_file { open read write ioctl }; which I'm not entirely sure if it is still needed or not. --- Another thing that comes to light is that apparently /usr/bin/ntpkeygen can generate keys which fail to parse. cd /etc/ntp && ntpkeygen && ln -sf ntp.keys keys && systemctl status restart May 03 00:02:15 mini.lan ntpd[30661]: AUTH: authreadkeys: reading /etc/ntp/keys May 03 00:02:15 mini.lan ntpd[30661]: AUTH: CMAC key 8 will be padded 10=>16 May 03 00:02:15 mini.lan ntpd[30661]: AUTH: authreadkeys: added 20 keys This appears to be related to the presence of #'s in the key: 8 AES yaFV<<}Z4x#n^k,# May 03 00:10:14 mini.lan ntpd[30802]: AUTH: authreadkeys: reading /etc/ntp/keys May 03 00:10:14 mini.lan ntpd[30802]: AUTH: CMAC key 10 will be padded 8=>16 May 03 00:10:14 mini.lan ntpd[30802]: AUTH: authreadkeys: added 20 keys 10 AES Nc{2&pyv#C}=,KqN May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: reading /etc/ntp/keys May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: no key for key 9 May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: added 19 keys 9 AES #CeE{.3qv(,:.e.G btw. additionally 'man ntpkeygen' has a tiny typo since it lists [-MV] instead of [-V]
Thanks for the report. I'll make an update enabling the refclock support. I didn't notice it's disabled by default. I'll look into the keygen issue. The hardpps feature requires a special build of the kernel. It didn't work with the old ntpd either. If you find any selinux issues, please file a bug for the selinux-policy component.
FEDORA-2021-3ffc890685 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685
Okay, that seems to fix the refclock missing problem, and the 'man ntpkeygen' showing [-MV] instead of [-V] but trunc issue remains: Jun 07 13:53:14 mini.lan ntpd[9716]: INIT: ntpd ntpsec-1.2.1: Starting Jun 07 13:53:14 mini.lan ntpd[9716]: INIT: Command line: /usr/sbin/ntpd -g -N -u ntp:ntp Jun 07 13:53:14 mini.lan ntpd[9716]: 2021-06-07T13:53:14 ntpd[9716]: INIT: ntpd ntpsec-1.2.1: Starting Jun 07 13:53:14 mini.lan ntpd[9716]: 2021-06-07T13:53:14 ntpd[9716]: INIT: Command line: /usr/sbin/ntpd -g -N -u n> Jun 07 13:53:14 mini.lan ntpd[9717]: INIT: precision = 2.654 usec (-18) Jun 07 13:53:14 mini.lan ntpd[9717]: INIT: successfully locked into RAM Jun 07 13:53:14 mini.lan ntpd[9717]: CONFIG: readconfig: parsing file: /etc/ntp.conf Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: authreadkeys: reading /etc/ntp/crypto/ntp.keys Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 2 will be padded 12=>16 Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 4 will be padded 15=>16 Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 6 will be padded 3=>16 Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: authreadkeys: added 20 keys
Actually the problem appears to have been fixed in 'ntpkeygen' (and not ntpd itself). So if you regenerate the ntp.keys file with ntpkeygen it no longer outputs keys that ntpd cannot parse. I guess that's good enough? Provided people regenerate their keys.
Yes, users need to check their keys and regenerate them (or manually fix) if they contain the hash symbol. The update description mentions this, but I'm not sure how many people actually read those.
Probably no one. I wouldn't even know where to look (nor that there is such a thing for Fedora as opposed to RHEL). Most probably just run 'dnf update' or equivalent.
I guess you are right. Would it make sense to add a script that would check the keyfile and prevent ntpd from starting if it finds a key that includes the hash? Or just emit a warning? I'm not sure if a non-functional service is better than an insecure one, but at least it would bring the attention of the admin.
It could perhaps just sed -i -r '/^ *[0-9]+ AES .*#/d' out the lines (or something like that)... The problem is the location of the file is not exactly well defined, so I guess you'd have to parse the ntpd config file to find it - and possibly includes? I think perhaps the easiest thing is to simply modify ntpd to ignore keys instead of padding them? (or if ignoring is hard, just pad with random bits, which will basically make those keys useless, but not guessable)
FEDORA-2021-3ffc890685 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3ffc890685` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I'd grant it positive karma (since I've installed it locally and it's working fine), but the login server on bodhi isn't working (returns a "500 Internal Server Error Could not convert return value of the view callable function pyramid_fas_openid.view.verify_openid into a response object. The value returned was None. You may have forgotten to return a value from the view callable.").
Don't give it karma if you think the update needs some work. I wish upstream provided some guidance for users and downstream maintainers. I don't see a reliable way to detect the broken keys. '#' just starts a comment and maybe someone used it on purpose, right next to the actual key without any whitespace, e.g. 1 AES &qAt?7^mTooHz9JK#this is a comment How do we detect a real comment? We could check the length of the key, but what would be the threshold? People might be using a shorter key intentionally. A short key is still better than no key at all and we don't want to break a working configuration just because we suspect the key was generated by ntpkeygen, right? Also, I'd rather avoid downstream-specific patches.
Well, I'd give positive karma if I could, because it's already better then the current stable package. :-) Honestly ignoring all truncated keys seems fine to me - I kind of doubt anyone generates them via something besides ntpkeygen - I don't think the format is even documented anywhere - is it?... (and ntpd already logs when it hits truncated keys, so it knows they're 'bad') I assume currently such truncated keys are simply padded with 0s... Though I don't really understand how this apparent base~90-ish encoding of keys works. Seems very very weird. Anyway, it's probably fine as is. NTP crypto is probably used rarely enough as is, and even rarer on bleeding edge Fedora rather than RHEL. I'm using this on a dev box for playing around with some time stuff.
As I understand it, the original format of the key file was just plain text passwords. It was later extended to parse strings longer than 20 characters as HEX-encoded values to better suit SHA1 and stronger hash functions. ntpkeygen generates two sets of 128-bit keys, using both formats. The latter would be recommended for everyone, but some people might still be putting manually written passwords there. I don't know. Only AES keys require padding. The older types like MD5, SHA1, SHA256 are ok with any key length.
Changing the summary to the security issue, now that it's the main point of this bug.
I got a suggestion from the security response team to detect comments that are not separated from the key by the space or tab character. If such a key is detected, ntpd will exit to force the admin to fix the file. False positives are possible, but they should be rare and it is probably better than running with a weak key. This issue was only in Fedora 34. After few releases, we can consider dropping the patch.
*** Bug 1975415 has been marked as a duplicate of this bug. ***
FEDORA-2021-3ffc890685 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.