mailing list archives
Re: sshd1 allows unencrypted sessions regardless of server policy
From: mhw () WITTSEND COM (Michael H. Warfield)
Date: Tue, 14 Dec 1999 14:35:05 -0500
One nit in what was a good analysis over-all...
On Tue, Dec 14, 1999 at 04:43:32PM +0100, Markus Friedl wrote:
[I am posting this here since nobody seems to take care of ssh-1.2.27]
I would like to bite on that line, but I think I'll be a good boy
Because passphrase-less hostkeys are 'encrypted' with cipher "none"
the code for this cipher is always compiled into the programs. This
way the client is free to choose "none" and no server will complain.
AFAIK... The passpharse-less host keys are encrypted with 3-DES
and no password. They were, at one time, encrypted with IDEA with no
password. This is according to the documentation (specifically some
remarks Tatu made in the Changes file). As you discovered with this hole,
reality may differ from documentation space.
I know about this because I ran smack into a compatibility
problem upgrading a number of my older hosts to use OpenSSH. If the host
key was generated with an old enough version of SSH (around 1.2.8 or so),
the host key was encrypted with IDEA, which OpenSSH does not support. That
meant that just after upgrading to OpenSSH, you're toast because the daemon
can not read the host key (error is "unsupported encryption algorithm"). The
solution is to run "ssh-keygen -u /etc/ssh_host_key" (modify for your host
key location), using the ssh-keygen program from ssh-1.2.27, prior to the
ugrade (the OpenSSH keygen program can't read the old key either and doesn't
support the -u option). According to the ssh docs, that re-encrypts the host
key in the default algorithm (3-DES in the case of 1.2.27). No harm is done
by running "ssh-keygen -u" on a newer key.
So... You say the host key is not encrypted. The documentation
says that it's encrypted 3-DES with no passphrase. I know that older
host keys were encrypted with an algorithm which OpenSSH can not read
(and identifies it by number as IDEA). I also know that running ssh-keygen
on the host key corrects the incompatibility. It could be that the new
host key is encrypted with 3-DES and no password as stated in the docs or
it could be that it's encrypted with NONE. Both would account for the
behavior I've seen. Since you've already discovered one discrepancy, a
second one is not that unlikely...
Like I said... Just a nit...
Michael H. Warfield | (770) 985-6132 | mhw () WittsEnd com
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
sshd1 allows unencrypted sessions regardless of server policy Markus Friedl (Dec 14)
SSH-1.2.27 & RSAREF2 exploit Iván Arce (Dec 14)
SSH 1 Why? Daniel P. Zepeda (Dec 15)
Re: SSH 1 Why? Emiliano Kargieman (Dec 15)
Re: SSH 1 Why? Emiel Kollof (Dec 15)
Re: SSH 1 Why? Iván Arce (Dec 16)
Re: SSH 1 Why? R. J. Wysocki (Dec 18)
Groupewise Web Interface Sacha Faust Bourque (Dec 19)