Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

From: Matthew Seaman <matthew_at_FreeBSD.org>
Date: Tue, 9 Aug 2016 08:53:06 +0100
On 09/08/2016 03:23, Jeffrey Bouquet wrote:
> Will/could there be some kind of UPDATING announcement re which files
> explicitly to switch out/remove/replace/checkfor etc the deprecated
> lines and precisely the steps to replace with new or some other
> suitable action? Action required for both the sshd and client?
> Subdirectories involved? etc...  Unclear here, but I don't use SSH
> hardly yet... despite having bought the book.

As far as managing sshd on your own systems, you should not need to make
massive changes to the /etc/ssh/sshd_config when upgrading to 11.0 or
12.0 -- the normal mergemaster or etcmerge procedures will probably
cover things.  On an upgraded system, you will have still have
/etc/ssh/ssh_host_dsa_key{,.pub} but these will be ignored by sshd and
would not be generated on a new machine.

Optionally, you may choose to replace /etc/ssh/ssh_host_rsa_key{,.pub}
if that key has a short bit-length.

You may find that you get 'Key mismatch' warnings -- ssh may use a
different type of host key on connection to a machine after this update,
and it will alert you if this does not match what it has in
~/ssh/known-hosts from previous connections.  If you're satisfied that
the warning is explained by this configuration change, then you can edit
known-hosts to eliminate the warning message.

As a ssh user, you will need to review the ssh keys you are using, and
what is listed in the ~/.ssh/authorized_keys files of any machines you
want to login to.  You can add a new key of and alternate type in
parallel to your existing keys, and load multiple keys into ssh-agent --
this allows you to phase in a new key with minimal risk that you will
lock yourself out of a remote machine.  Doing this *before* you upgrade
any systems is just common sense.

The default configuration of sshd provided with FreeBSD provides good
security and a good level of interoperability with other ssh
implementations, and you can use it with confidence.  Depending on local
requirements you may want to impose a stricter policy.  In that case,
the following references will be interesting to you:

https://wiki.mozilla.org/Security/Guidelines/OpenSSH
https://stribika.github.io/2015/01/04/secure-secure-shell.html

These are, however, rather more than most people will really find necessary.

	Cheers,

	Matthew



Received on Tue Aug 09 2016 - 05:53:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:07 UTC