Key rollover instructions
Dear Web Team,
please fold in the information for the key rollover into the
website. The Security Team will collect and prepare information
through the wiki and by contacting maintainers and
send finalised instructions to you in regular intervals.
I think we should have an alphabetical list and a separate
page of packages known not to be vulnerable.
Thanks in advance,
Moritz
OpenSSH:
========
A package has been released as DSA-1576, which eases key transformation,
1. Install the security updates
Once the update is applied, weak user keys will be automatically
rejected
where possible (though they cannot be detected in all cases). If
you are
using such keys for user authentication, they will immediately stop
working
and will need to be replaced (see step 3).
OpenSSH host keys can be automatically regenerated when the OpenSSH
security
update is applied. The update will prompt for confirmation before
taking
this step.
2. Update OpenSSH known_hosts files
The regeneration of host keys will cause a warning to be displayed
when
connecting to the system using SSH until the host key is updated in
the
known_hosts file. The warning will look like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that the RSA host key has just been changed.
In this case, the host key has simply been changed, and you should
update
the relevant known_hosts file as indicated in the error message.
3. Check all OpenSSH user keys
The safest course of action is to regenerate all OpenSSH user keys,
except where it can be established to a high degree of certainty
that the
key was generated on an unaffected system.
Check whether your key is affected by running the ssh-vulnkey tool,
included
in the security update. By default, ssh-vulnkey will check the
standard
location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and
~/.ssh/identity),
your authorized_keys file (~/.ssh/authorized_keys and
~/.ssh/authorized_keys2), and the system's host keys
(/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).
To check all your own keys, assuming they are in the standard
locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):
ssh-vulnkey
To check all keys on your system:
sudo ssh-vulnkey -a
To check a key in a non-standard location:
ssh-vulnkey /path/to/key
If ssh-vulnkey says "Unknown (no blacklist information)", then it
has no
information about whether that key is affected. If in doubt,
destroy the
key and generate a new one.
4. Regenerate any affected user keys
OpenSSH keys used for user authentication must be manually
regenerated,
including those which may have since been transferred to a
different system
after being generated.
New keys can be generated using ssh-keygen, e.g.:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
5. Update authorized_keys files (if necessary)
Once the user keys have been regenerated, the relevant public keys
must
be propagated to any authorized_keys files on remote systems. Be
sure to
delete the affected key.
OpenSWAN / StrongSWAN
=====================
rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart
Beware: Restarting the ipsec services terminates all currently open IPSec
connections, which may need to be restarted from the other end.
Reply to: