Bug 738607 - sshd doesn't work
sshd doesn't work
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-09-15 07:19 EDT by Kamil Páral
Modified: 2013-02-04 13:56 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-04 13:56:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kamil Páral 2011-09-15 07:19:37 EDT
Description of problem:
sshd doesn't work when started manually.
$ service sshd status
reports "failed". When I run the binary:
$ /usr/sbin/sshd -D
/etc/ssh/sshd_config: No such file or directory

There is really no such file. There is just /etc/ssh/sshd_config.anaconda.

Version-Release number of selected component (if applicable):
Fedora 16 Beta TC2
anaconda 16.17
Comment 1 Kamil Páral 2011-09-15 07:20:04 EDT
Proposing as F16 Final NTH.
Comment 2 Kamil Páral 2011-09-15 07:20:50 EDT
I tested on an i686 DVD.
Comment 3 Kamil Páral 2011-09-15 07:50:24 EDT
Renaming /etc/ssh/sshd_config.anaconda to /etc/ssh/sshd_config helped, sshd is now running. But I can't connect to it (that might be my fault as well, but iptables seem to be not installed and netstat is not installed, further debugging is ongoing).
Comment 4 Kamil Páral 2011-09-15 07:53:07 EDT
So, in /tmp/syslog I found these errors when I try to connect:

sshd: error: Could not load host key: /etc/ssh/ssh_host_key
sshd: error: Could not load host key: /etc/ssh/ssh_host_rsa_key
sshd: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
Comment 5 Kamil Páral 2011-09-15 07:58:51 EDT
When I boot anaconda with "sshd" option, everything works as expected:

Maybe anaconda could support starting sshd also manually? Because when you need to debug something remotely, it's too late (you already booted without that option). And fixing up sshd from scratch may be too hard for many people (simply because they don't know it is a feature).
Comment 6 Martin Gracik 2011-09-15 08:11:54 EDT
You can run sshd manually, but you have to specify the /etc/ssh/sshd_config.anaconda file with the -f parameter. And generate the ssh keys before that.

Is this very inconvenient?
Comment 7 Kamil Páral 2011-09-15 09:10:07 EDT
I don't know exactly how to generate server keys, but I presume I can find that out quickly. It is not very inconvenient now that I know that. But I work as Fedora QA for two years and I know it only now. How about all the other guys in the word that don't know about that procedure? I can only assume that if anaconda crashes for them (or any other reason) and they want to examine it remotely, they won't have any idea that this procedure is needed. They'll probably think the same way as me - service sshd start -> fail -> something's wrong with anaconda environment.

I don't say this is a bug, because you have "sshd" option documented. But if you could ensure that it is possible to start the service in a usual manner when needed (it could generate the keys on service start, as is common for new Fedora installations), it would improve the situation considerably.
Comment 8 Adam Williamson 2011-09-15 13:26:25 EDT
is this how it's always behaved, or something changed in f16?
Comment 9 Martin Gracik 2011-09-16 03:07:24 EDT
Nothing has changed, worked like this for a long time.

Anaconda generates the ssh server keys only if you provide the "sshd" kernel parameter. Otherwise there are no keys in the install environment. Also the config file always had the ".anaconda" suffix.
Comment 10 Kamil Páral 2011-09-16 06:42:52 EDT
I had a feeling it used to work before, but I just tested F15 and F14 and you are right, it didn't work.

This is just a RFE then.
Comment 11 Ales Kozumplik 2011-09-22 10:44:28 EDT
I think we only start sshd (and generate the keys) on request because at some point generating the keys took too much time on s390 hosts (go figure).
Comment 12 Chris Lumens 2011-09-22 10:54:59 EDT
Yes, that does sound familiar.
Comment 13 Martin Gracik 2011-09-22 11:21:45 EDT
Yes, s390 has the keys generated during compose, and they are already in the initrd. So this would require "if not s390..."
Comment 14 Adam Williamson 2011-09-30 15:56:00 EDT
Discussed at the 2011-09-30 NTH review meeting. Agreed -1 NTH: the purpose of the NTH process is to identify fixes that are sufficiently important to be taken through a freeze, and this really doesn't meet that description.

We know anaconda team now has a policy in place that they will only commit NTH and blocker fixes to the pending release branch after a certain date, and that's a great policy from a stability PoV, but we can't really bend the NTH process to accept bugs as NTH that we wouldn't really want to take through a freeze just so they can be committed to anaconda outside of a freeze.

Maybe the anaconda policy could be relaxed slightly and you could introduce a keyword or whiteboard field for bugs that can be committed to the pending release anaconda branch outside of a freeze period but which aren't really NTH. We could set up a process for QA to help you review these or you could simply review them yourselves. Anyway, just an idea.
Comment 15 Chris Lumens 2011-09-30 16:27:37 EDT
Martin - if you have a fix for this, feel free to propose it on the list.  I'm willing to accept a patch for f16-branch as long as it's not invasive.
Comment 16 Richard Marko 2011-10-24 08:26:43 EDT
Wasn't this lost during the migration to systemd? I think that the key generation was part of sshd init script so when there were no keys the script generated them automatically. 

Now one has to copy the config and run `service sshd-keygen start` prior to running sshd (and it takes time to figure that out).
Comment 17 Fedora End Of Life 2013-01-16 10:41:14 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 18 Fedora Admin XMLRPC Client 2013-02-04 10:06:41 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Brian Lane 2013-02-04 13:56:19 EST
It doesn't look like lorax is doing anything unusual in its sshd setup, and I don't think having the anaconda sshd config as the default is a good idea (it has root login enabled). You can either pass inst.sshd when booting or copy /etc/ssh/sshd_config.anaconda over to /etc/ssh/sshd_config and start it with systemctl start sshd.service

Note You need to log in before you can comment on or make changes to this bug.