Bug 738607

Proposing as F16 Final NTH.

I tested on an i686 DVD.

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).

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

When I boot anaconda with "sshd" option, everything works as expected:
http://fedoraproject.org/wiki/Anaconda/Options

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).

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?

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.

is this how it's always behaved, or something changed in f16?

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.

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.

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).

Yes, that does sound familiar.

Yes, s390 has the keys generated during compose, and they are already in the initrd. So this would require "if not s390..."

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.

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.

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).

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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