Bug#483756: insist ssh-vulnkey -a be run by the administrator upon upgrade
On Sat, May 31, 2008 at 06:57:42AM +0800, jidanni@jidanni.org wrote:
> CW> But that's OK; any keys that would be detected by ssh-vulnkey will also
> CW> be blacklisted automatically by sshd.
>
> Well all I know is that I do my sid upgrades, and my friends emailed
> me to tell me I had things needing replacing on their machines.
>
> I don't run sshd but often use ssh...
Sure, but that's a problem with *their* machine (i.e. it allows access
from unauthorised persons) rather than a problem with your machine. The
sshd blacklisting will prevent this problem on their side - you might
send them an updated key but you won't be able to log in with it.
(If they aren't running an sshd with blacklisting support, then that's
primarily their problem. However, nobody who has applied any of the
Debian openssh upgrades has this problem.)
> CW> # Some keys on your system have been compromised!
> CW> # You must replace them using ssh-keygen(1).
> CW> #
> CW> # See the ssh-vulnkey(1) manual page for further advice.
>
> OK, I suppose that's good but of course I'm no expert.
> Wait, also mention the importance of cleaning up keys that one has put
> on remote machines as well as this machine. Also say it on the man
> page.
Such a note has been in the ssh-vulnkey(1) manual page since its first
version.
> OK, thanks for adding more instructions and warnings.
> Maybe at least add something to the apt-listchanges news stuff with
> lots of asterisks saying root should do ssh-vulnkey -a and then what
> to do if something is detected.
I did consider adding a NEWS entry. The reason I chose not to was that
there's no way to have it appear for the security updates but not also
have it appear when people upgrade to lenny months from now (because
there would need to be NEWS entries with different versions in
stable-security and in testing/unstable). That problem is even worse in
Ubuntu because three different stable releases and a development branch
were all affected. It's a problem rather than a mere cosmetic glitch
because it would cause an alarming message to pop up months after most
people have forgotten about this bug, and thereby instil confusion and
panic.
I would *like* to add a NEWS item, but I decided that the problems
weren't worth it. I think
/usr/share/doc/openssh-server/README.compromised-keys.gz (pointed to by
the debconf note that appears if you have any compromised host keys, so
at least some people find out about it) and the advisory documentation
will have to do.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: