1

We host a SFTP server and we encourage our customers to check the SSH host key when connecting.

I was always under the impression that the SSH host key was fixed - it would only change when reinstalling the OS.

But in the past the SSH host key was changed (not sure, we don't monitor it) unexpectedly and that was raising (valid) questions by our customers.

We use the Cerberus FTP Server on Windows for hosting SFTP and FTPS. It looks like the SSH host key was changed when we replaced the SSL certificate for FTPS...

My questions:

  • Is changing the SSH host key a bad thing or is there a security benefit by changing it?
  • Is it valid to assume that the SSH host key is unrelated to FTPS/ SSL certificate changes?
  • Should the consider the unexpected change of the SSH host key as a bug in the used software?
  • Should we have to monitor our own SSH host key on changes?
Improve this question

2 Answers 2

Reset to default
3

Is changing the SSH host key a bad thing or is there a security benefit by changing it?

You should change it mainly if is has been compromised. Examples of such compromissions: an employee that could have knowledge of it is fired or leaves the company for any reason, you had to let an extersal support tech administrate the machine.

You could change it on a timely manner, but it should have a typical certificate lifetime, IMHO several years. That would allow to collect a possible undisclosed attach

Is it valid to assume that the SSH host key is unrelated to FTPS/ SSL certificate changes?

AFAIK, yes

Should the consider the unexpected change of the SSH host key as a bug in the used software?

I would considere that as a flaw in the administrative procedures: the key should be archived so that it can be restored after a (eventually partial) reinstallation

Should we have to monitor our own SSH host key on changes?

A change of the SSH host key should never occur by accident. That means the the change should be prepared and all users warned of it some time before and the day it is done. The change should be noted in the operational log.

Improve this answer
1

The benefit of changing the SSH private key is that any person who (unexpectedly) obtained this key cannot use it anymore to read your traffic or to become man in the middle.

That's about the only benefit I can think of.

Since SSH doesn't operate in PKI regime (SSH public key are not certified by trusted public certificate authorities, unlike SSL/TLS), each change of SSH private key on a server requires a communication to all the clients to authenticate the new key to them. The clients usually "pin" (remember) the exact public keys allowed for a single server and authenticating a new public key is a human action. Deauthenticating an old key is another human action. Some of the clients are scripts usually buried deep, unmodified for months or years, and for a server to determine how to contact their human maintainers is another manual task.

As follows, the change of SSH key should be visible to server's admins, otherwise it's a bug. And you need a workaround (such as daily monitoring) if you have this bug.

It is valid to assume that SSH private key is not related to FTPS certificate.

It is valid to assume that SSH private key is subtly related to FTPS private key. If you change the latter it is quite obvious to assume that you think you face a breach of security. The same breach is likely to leak an SSH private key too. But still the keys are separate, so automatically changing SSH private key is an overshoot, really.

Side note: normally you can have multiple SSL/TLS certificates for the same SSL/TLS private key. The private key doesn't have an expiration date field. If you generate a new private key, you need a new certificate to be signed by publicly trusted CA.

In other words, when re-generating the SSL/TLS certificate, you could keep the old SSL/TLS key. Many inexperienced admins don't know this.

Improve this answer
2
  • I know I've seen a question about reusing the private key when generating new certificates, but I can't seem to find it at the moment. Bottom line, there can be valid cases for it, but it's often better to generate a brand new private key then create a CSR and ultimately certificate based on the new key. So you can (and probably should) change the SSL certificate's corresponding private key regularly. And of course, even if you use the same private key, the certificate will get a new serial number and thus the old signature will no longer apply; it will be a brand new certificate.
    – user
    Commented Sep 30, 2016 at 11:42
  • @MichaelKjörling I think that if you had a key pinned on all clients (as SSH effectively does), and three manual actions would be needed to change, you would think thrice before you re-generated the key pair.
    – kubanczyk
    Commented Sep 30, 2016 at 16:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .