Bug 208254
| Summary: | rc.d/sshd failes to generate all referenced ssh host keys. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Peter Wemm <peter> | ||||||
| Component: | conf | Assignee: | Dag-Erling Smørgrav <des> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Many People | CC: | amutu, bdrewery, des, emaste, re | ||||||
| Priority: | --- | Flags: | des:
mfc-stable11+
|
||||||
| Version: | CURRENT | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Created attachment 168616 [details]
Check whether each key file exists before adding it
Please test the attached patch.
This appears to work as I would expect, at least noise-wise. FWIW, the approach in general feels a little odd to me. eg: with no ssh_host_dsa_key family, a "sshd -T -f /etc/ssh/sshd_config" still shows "ssh-dss" for pub keys, and you can still log in with ssh-dsa keys. It feels a little odd to disable dsa for host keys, but leave it enabled for authentication. peter@overcee[ 1:05AM]~/.ssh-1017> ssh -v -i id_dsa tiny.nyi ... debug1: Server host key: ecdsa-sha2-nistp256 SHA256:OrntpV5eSy6jIYRMZ1e84yjuQHd0DJAhMaOp8Vz5obQ ... debug1: Offering DSA public key: id_dsa debug1: Server accepts key: pkalg ssh-dss blen 433 Enter passphrase for key 'id_dsa': debug1: Authentication succeeded (publickey). Authenticated to tiny.nyi ([2610:1c1:1:610b::16:1]:22). ... peter@tiny.nyi:~ % ls -l /etc/ssh/ssh_host_dsa* ls: No match. Looking at rc.d/sshd: : ${sshd_rsa1_enable:="no"} : ${sshd_rsa_enable:="yes"} : ${sshd_dsa_enable:="no"} : ${sshd_ecdsa_enable:="yes"} : ${sshd_ed25519_enable:="yes"} It kind of implies that dsa is turned off. It seems surprising to me that DSA keys are still quite fine for authentication. Is this really intended? (In reply to Peter Wemm from comment #2) > FWIW, the approach in general feels a little odd to me. eg: with no > ssh_host_dsa_key family, a "sshd -T -f /etc/ssh/sshd_config" still shows > "ssh-dss" for pub keys, and you can still log in with ssh-dsa keys. It feels a > little odd to disable dsa for host keys, but leave it enabled for > authentication. Those are two completely separate things in the protocol and configuration (HostKeyAlgorithms vs PubkeyAcceptedKeyTypes). > It kind of implies that dsa is turned off. It seems surprising to me > that DSA keys are still quite fine for authentication. Is this really > intended? Yes. *** Bug 207366 has been marked as a duplicate of this bug. *** A commit references this bug: Author: des Date: Fri Aug 5 15:32:36 UTC 2016 New revision: 303770 URL: https://svnweb.freebsd.org/changeset/base/303770 Log: MFH (r303716, r303719): drop SSH1 support, disable DSA by default PR: 208254 Approved by: re (gjb) Relnotes: yes Changes: _U stable/11/ stable/11/crypto/openssh/FREEBSD-upgrade stable/11/crypto/openssh/config.h stable/11/crypto/openssh/configure.ac stable/11/crypto/openssh/myproposal.h stable/11/crypto/openssh/servconf.c stable/11/crypto/openssh/ssh_config.5 stable/11/crypto/openssh/sshd_config.5 stable/11/etc/rc.d/sshd The console spam has been MFC'ed to 11 now too! Please commit the fix! DES, could you please commit the patch included above? (In reply to Glen Barber from comment #7) > DES, could you please commit the patch included above? Sorry, I need to investigate. The actual bug is that it shouldn't try to load the DSA key at all. I thought I had reverted all DSA-related changes, but apparently I missed one. Looks like lines 217-218 of servconf.c need to be removed. I'm starting this month's cluster refresh with the rc.d change backed out, so that sshd_dsa_enable:="yes". This generates a massive amount of error message spam for us due to the unexpected output from sshd config file test mode as in the original report from 4 months ago. Created attachment 173396 [details]
Check whether each key file exists before adding it
Updated patch
A commit references this bug: Author: des Date: Mon Aug 8 10:46:18 UTC 2016 New revision: 303832 URL: https://svnweb.freebsd.org/changeset/base/303832 Log: Try to check whether each key file exists before adding it, and bail out if we didn't find any of them. This reduces log spam about key files for deprecated algorithms, which we look for but don't generate. PR: 208254 MFC after: 3 days Changes: head/crypto/openssh/servconf.c There is also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202153 which avoids modifying the SSH source. We could still generate the key but not enable the algorithm. I don't see much harm in generating the key. A commit references this bug: Author: des Date: Thu Aug 11 08:29:16 UTC 2016 New revision: 303952 URL: https://svnweb.freebsd.org/changeset/base/303952 Log: MFH (r303832): check whether each key file exists before adding it PR: 208254 Approved by: re (kib) Changes: _U stable/11/ stable/11/crypto/openssh/servconf.c |
By default, sshd expects /etc/ssh/ssh_host_dsa_key to exist. /etc/rc.d/sshd no longer generates it by default. This leads to a lot of console noise for every.. single.. incoming.. connection. $ grep dsa etc/rc.d/sshd ... : ${sshd_dsa_enable:="no"} ... (Test the default built-in configuration) # sshd -t -f /dev/null Could not load host key: /etc/ssh/ssh_host_dsa_key (Test the default freebsd-11 configuration) # sshd -t -f /etc/ssh/sshd_config Could not load host key: /etc/ssh/ssh_host_dsa_key The logical fix is to re-enable the host key generation until sshd is smarter about this. It can't spam this on the console for every connection.