Quality of life idea?

[justinclift]

As a general thought, would it make sense to have the "first time setup" script copy the existing .key/.pub files from /etc/ssh if they're already present?

Asking because when switching an existing system to hpn-ssh, the newly generated host keys will cause unwanted connection issues from other hosts. The ssh -> hpn-ssh change is a purposeful, admin directed task, so doesn't need security issues caused by its roll out.

When switching systems to hpn-ssh here, pretty much the first task afterwards is to shut it down, nuke the hpn-ssh generated keys, then copy the existing ones from the /etc/ssh directory, then start it up again.

I'd be surprised if that wasn't a common thing people are doing. :smile:

[rapier1]

One of the things that we wanted to ensure what that people could use OpenSSH and HPN-SSH side by side. That's why we put the config files and keys in /etc/hpnssh. I had thought about just using any existing keys in /etc/ssh but I didn't think that was entirely the right thing to do in all cases. So I decided to err on the side of paranoia and generate new keys. That way admins would either have to make that decision consciously or users would have to accept new keys.

What I think I should do is find out if the package management script can handle user interaction (yes/no) and branch based on that. That way I could make it more flexible with some minor additional annoyance during installation.

Are you using rpms or debs for this?

[gdevenyi]

debian et al can handle this with debconf features and post-install script. Not sure what rpms do.

[rapier1]

Do you have any pointers? Packaging hasn't been something I've focused enough on.

[justinclift]

Are you using rpms or debs for this?

For my case, it's debs (Debian 12), as Proxmox is built upon that. :smile:

[justinclift]

Doing some quick searching online shows up this, which sounds right:

https://unix.stackexchange.com/questions/41959/prompting-for-input-in-post-install-script-in-dpkg

Apparently it's a system called debconf (as @gdevenyi mentioned above), used for getting input from a user and storing it on the local system (in a database) for reference as needed.

Looks like it has a tutorial here too:

http://www.fifi.org/doc/debconf-doc/tutorial.html

Assuming that tutorial is still relevant, it doesn't look toooooooo complex. :smile:

[rapier1]

Wanted to let you know that we're looking into doing more with packaging to give users some additional options. One of these would be to change the default install locations and naming schemes. So by default it will build for a side by side install with OpenSSH. However, you'd have the option to have it build the binaries without the hpn prefix and install them into default locations overwriting/replacing the OpenSSH installation. This would preserve the keys.

That's on the build end. On the package distro end we're going to try to include a method to link to the existing OpenSSH keys (we think that's a better idea than copying them) instead of creating hpn specific ones. We're also going to try to have an option to the alternatives command to redirect calls to ssh/stfp/etc to the hpn equivalents. That way we can have a side by side install but not require the users to learn new commands.

I'm not sure when this is going to happen but it is on the todo list now.

[justinclift]

Cool, thanks for looking at the idea. :smile:

link to the existing OpenSSH keys

Hadn't thought of doing that instead, but should have. You're right, that would be better than just copying the keys. :smile:

[justinclift]

We're also going to try to have an option to the alternatives command to redirect calls to ssh/stfp/etc to the hpn equivalents.

That makes good sense. Have seen the Alternatives system used for things like java, and the approach seems to work "ok" enough:

https://wiki.debian.org/DebianAlternatives