Comment 5 for bug 15359

Revision history for this message
In , Martin Pool (mbp) wrote : Re: "bad plaintext length" (was Re: Bug#151743: Can't verify this :( [was: ssh: 3.4p1-2 fails to install saying "cipher_encrypt: bad plaintext length 337"])

On 26 Oct 2002, Colin Watson <email address hidden> wrote:

> On Tue, Jul 16, 2002 at 02:08:14AM +0100, Jonathan Amery wrote:
> > Hmm, I tried this on a stable machine here, and got the same error:
> >
> > allison.empire.pick.ucam.org:~/ # [02/07/16.02:06:12] $
> > : pts/6 bash[4621] ; ssh-keygen -p -N '' -f key1
> > cipher_decrypt: bad ciphertext length 337
> > allison.empire.pick.ucam.org:~/ # [02/07/16.02:06:16] $
> > : pts/6 bash[4622] ; dpkg --list ssh
> > Desired=Unknown/Install/Remove/Purge/Hold
> > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> > ||/ Name Version Description
> > +++-==============-==============-============================================
> > ii ssh 1.2.3-9.4 Secure rlogin/rsh/rcp replacement (OpenSSH)
> >
> > Do you have an extant backup of the host key from before the upgrade?
> > I fear that it might have got corrupted somewhere.
>
> While this is obviously a nasty bug, it doesn't seem to be having
> widespread effect, so I'm downgrading it.

I haven't seen the problem again.

> Perhaps one thing that would help would be if ssh's postinst backed up
> host keys before attempting to edit them?

That seems like a very sensible idea to me.

Perhaps make them 0400 afterwards, and perhaps back them up in a way
that would protect against repeated broken attempts to upgrade.
(e.g. move to "host_key.$TIMESTAMP~")

--
Martin