| Summary: | net-misc/openssh: no host keys generated on systemd based system | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Konstantin (elxa) <ktrackfd> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, dschridde+gentoobugs, ktrackfd, lxnay, nikoli, steffen.weber, systemd, thev00d00 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=831762 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Konstantin (elxa)
2013-02-13 00:22:36 UTC
How about adding pkg_config() to generate keys? Fedora uses shell script which is invoked in ExecStartPre. We could rip code out of the Gentoo init script to do the same. (In reply to comment #2) > Fedora uses shell script which is invoked in ExecStartPre. We could rip code > out of the Gentoo init script to do the same. We could also do it the proper way and not expect starting services to modify system configuration. (In reply to comment #3) > We could also do it the proper way and not expect starting services to > modify system configuration. You really think the user should be required to explicitly generate keys for this? That's just silly. I just think that the ebuild which does install SSH is responsible for generating keys, not the service manager which starts it. Unfortunately, I don't think the ebuild can do it automatically (pkg_postinst) since openssh is part of the stage3 tarball. We would end up distributing keys in stage3, which would be bad. If we do it via pkg_config, that requires manual user action to be run. I think that generating the keys the first time sshd is started is less confusing. Either way we do it, it seems the code could be greatly simplified by just calling ssh-keygen -A.
-A For each of the key types (rsa1, rsa, dsa and ecdsa) for which
host keys do not exist, generate the host keys with the default
key file path, an empty passphrase, default bits for the key
type, and default comment. This is used by /etc/rc to generate
new host keys.
yes, it doesn't make sense for the ebuild to do it. adding a pkg_config step wouldn't help either. My suggestion would be to add ExecStartPre=/usr/bin/ssh-keygen -A to sshd.service. Any objections? (In reply to comment #9) > My suggestion would be to add ExecStartPre=/usr/bin/ssh-keygen -A to > sshd.service. > > Any objections? I personally think we should split the existing code from the init script and call that from both places, it would be the most consistent way. Sabayon have done something similar already[1], by calling the the split out file "sshd-functions.sh" from both places. 1: https://git.sabayon.org/overlays/for-gentoo.git/diff/?id=886c4b9 (In reply to comment #10) Alternatively, we could replace the gen_keys function in the init script with a simple "ssh-keygen -A" if consistency is a real concern. (In reply to comment #11) > (In reply to comment #10) > > Alternatively, we could replace the gen_keys function in the init script > with a simple "ssh-keygen -A" if consistency is a real concern. So long as its the same method in both places, then I don't see an issue :) ExecStartPre= is the way to go. Whatever is the rest about, I am not that worried. Generating the host key through pkg_config doesn't make sense. + 04 Apr 2013; Mike Gilbert <floppym@gentoo.org> files/sshd.service: + Add ExecStartPre=/usr/bin/ssh-keygen -A to sshd.service. Bug 457026. I leave it to the maintainers to decide if they want to do the same for the init script. (In reply to comment #14) looks like -A is new to 5.9_p1. the init.d logic predates that significantly. the ssh-keygen flag doesn't support an alternative sshd config, but it looks like we're already not really handling that correctly (parsing HostKey out), so maybe it doesn't matter. http://sources.gentoo.org/net-misc/openssh/files/sshd.rc6.4?r1=1.2&r2=1.3 |
