| Summary: | net-misc/openssh: init script lacks "need root" when SSH host keys are missing (error "Read-only file system") | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sebastian Pipping <sping> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Add "need root" if SSH host keys are missing | ||
Created attachment 406722 [details, diff]
Add "need root" if SSH host keys are missing
PS: There is a "!" missing before the call to ls in comment #1. The patch has it, though. Any news? The patch is hungry for review :) Comment on attachment 406722 [details, diff]
Add "need root" if SSH host keys are missing
the exact key path is determined by the active SSHD_CONFIG, so we don't really want to hardcode these paths.
depend phases are supposed to notify the cache manager which paths it cares about, but that might not be feasible here. iow, it means the cache will hold onto "need root" after the keys have been generated but until the next time the cache is regenerated. maybe that window isn't big enough to care about.
style wise, the two redirects aren't needed -- use 2>&1 instead for the 2nd one.
(In reply to SpanKY from comment #4) > the exact key path is determined by the active SSHD_CONFIG, so we don't > really want to hardcode these paths. It's not really hardcoding, since it's on-demand. Does the patch do any harm? > depend phases are supposed to notify the cache manager which paths it cares > about, but that might not be feasible here. iow, it means the cache will > hold onto "need root" after the keys have been generated but until the next > time the cache is regenerated. I suppoe the cache is re-generated on each boot? If root is not going away, how is the cache keeping root for a dependency of sshd a problem? > style wise, the two redirects aren't needed -- use 2>&1 instead for the 2nd > one. Do you want me to post a new patch? (In reply to Sebastian Pipping from comment #5) of course you're hardcoding paths. you're assuming the user always uses the default settings in the sshd config file. there's no reason they couldn't configure one instance of sshd and have it point the keys to a different location. in which case the cache logic will always depend on root because those hardcoded paths will never be created. openrc does not regenerate the cache at boot ... that'd completely defeat the point of having the cache in the first place ;). it gets regenerated for a number of reasons, but most frequently when init scripts or conf.d files get updated. (In reply to SpanKY from comment #6) > you're assuming the user always uses the > default settings in the sshd config file. there's no reason they couldn't > configure one instance of sshd and have it point the keys to a different > location. Good point. > in which case the cache logic will always depend on root because > those hardcoded paths will never be created. > > openrc does not regenerate the cache at boot ... that'd completely defeat > the point of having the cache in the first place ;). it gets regenerated > for a number of reasons, but most frequently when init scripts or conf.d > files get updated. Is my understanding correct then that we have to pick from never and always depending on root? Do you see any downsides of always? (In reply to Sebastian Pipping from comment #7) ideally, we should be able to leverage ssh-keygen to have it tell us the full list of keys it would generate for a given config file. we could then use that to figure out when we need root. that would require updating ssh-keygen a bit and getting it merged upstream, but i don't think that'd be *too* difficult to pull off. a few stop gap measures might be feasible: (1) add a parser like the current depend function does to walk SSHD_CONFIG and extract the list of keys. if none are found, assume the default set, and use that to test if root is needed. (2) add a default rc_need="root" to the conf.d/sshd file ... depending on that stage wouldn't be a big deal for the majority of cases i think, and for the few that do care (rescue?), they can easily disable it. (3) add some state file in like /var/lib/misc/ -- if it doesn't exist yet, depend on root. at the end of the start function, touch the file. this way you know the server has all of its keys because it started correctly. to be clear, i'm saying the depend logic as written is not ideal, and it probably would be overly pessimistic as to when it wants root, but eventually it should converge to not needing it (even if that meant we had to wait for an incidental cache update which happens semi-often). |
Hi! I noticed that with no host keys present (e.g. in case of a distributed image without keys) the sshd init script is generating SSH host keys (through "ssh-keygen -A" in checkconfig). That fails with "Read-only file system" if the root file system is not mounted read-write yet. The current init script lacks such a dependency. I have tried adding if [ ! -e /etc/ssh/ssh_host_*_key ]; then need root fi but once the keys exist that would fail with [: too many arguments which is why I use ls, instead: if ls /etc/ssh/ssh_host_*_key 1>/dev/null 2>/dev/null; then need root fi That seems to work as expected. It would rock to have it fixed this week. Many thanks for your consideration.