Subject: Proposal: Disable SSHd Protocol v1 by Default (WAS: Re: ssh config
To: tech-security@netbsd.org, <netbsd-users@netbsd.org>
From: Brian A. Seklecki <lavalamp@spiritual-machines.org>
List: netbsd-users
Date: 03/14/2002 03:49:39
	First off, sorry for the cross-post, but I'd like to get developer
and user opinions & feedback on this one.

	Hi all.  I've been following the recent array of threads on
OpenSSH performance and security related issues.  A lot of valid issues
are being addressed, including benchmarks indicating that it's possible to
optimize binaries on a per-platform basis to improve entropy gathering,
reduce key generation times, etc.  All very cool, the wonders of open
source community in action.

	Previously I had suggested disabling the PermitRootLogin directive
in the default sshd config file.  Debate ensued, and the general consensus
among the security conscious was that permitting root to remotely log in
was generally a poor practice (for a innumerable amount of reasons).
That was progress as well.  Now, with the most recent rash of SSH issues,
there is one issue of concern that seems to have been neglected.  I know
this suggestion isn't going to make a lot of users w/ slower hardware
platforms very happy be cause of the need for increased CPU time for:

*) Server key regeneration at KeyGenerationInterval
*) Session key exchange times

That issues goes unspoken for.  We've all seen the increased delay on key
exchange times when using protocol 2 over protocol 1. I've even seen Sun
ultra class hardware (400+ Mhz) running Solaris lacking /dev/random or
egd, using ssh internal entropy gathering mechanisms, perform like sun4m
hardware running BSD.

But is convenience worth sacrificing security integrity?

I propose disabling the use of SSH Protocol 1 by default as precautionary
measure.

/etc/ssh/sshd_config:

Protocol 2

/etc/ssh/ssh_config:

Host *
        Protocol=2,l


*) Almost every security advisory related to OpenSSH prior to the recent
'off-by-one' and zlib linking issues were related to weaknesses in the
version 1 protocol.  Even the original ssh developers @cs.hut.fi and
ssh.com recommend exclusive use of protocol 2 (mailing list posts, etc.)

*) Users will be encouraged to use DSA keys instead of RSA keys (-t dsa1)
for systems like automated logins, etc.  RSA keys will still work with
Protocol 2 (-t dsa) but DSA keys are becoming more mainstream.

*) Consequently the first run (rc.d/sshd keygen) will run more quickly as
there will only be 1 key to generate as opposed to 3.

To play the devils advocate:

*) This is an abrasive move in terms of backward compatibility.  Many
users with legacy commercial ssh terminals in a production environment may
be force to upgrade (we all know what it's like to hear DBAs bitch and
moan).

*) Users upgrading will need to regenerate public RSA keys with the '-t
rsa' instead of '-t rsa1' flag, as well as copy the new key to the remote
users ~/.authorized_keys file.

The general consensus among the security community seems to be in favor of
disabling protocol 1, so I don't see any reason OpenSSH continues to ship
with it enabled, and more importantly, why we shouldn't take this
advantage to take a hard-line.

Opinions? Feedback?

-lava


On Tue, 12 Mar 2002, Thor Lancelot Simon wrote:

> On Tue, Mar 12, 2002 at 11:54:22AM +0900, itojun@iijlab.net wrote:
> > >> 	for NetBSD-current, ssh configuration file have moved from /etc
> > >> 	to /etc/ssh (follows openssh 3.0.2 -> 3.1 change).
> > >> 	you will need to perform the following before you restarting sshd:
> > >> 	# mkdir /etc/ssh
> > >> 	# mv /etc/{ssh.conf,sshd.conf,ssh*key,ssh*key.pub} /etc/ssh
> > >> 	# vi /etc/sshd.conf
> > >> 		(change reference to /etc/ssh*key to /etc/ssh/ssh*key)
> > >Are you sure this was the right thing to do?
> >
> > 	yes.
>
> Why?
>
> > >Since we don't use the
> > >same config file names, why cause users more pain by moving them again
> > >just because OpenSSH did?
> >
> > 	i really think that we should revert the config file name changes
> > 	(go back to ssh_config and sshd_config).
>
> Well, why didn't you do that, then?  I don't understand how it could
> possibly make sense to make *half of* the change.  Is the idea just to
> get users accustomed to having these files move around continuously so
> they won't object at some point in the future when you change the names
> back to the original names?  Because if that's the case, I think you ought
> to just make the entire change now.
>
> --
>  Thor Lancelot Simon	                                      tls@rek.tjls.com
>    But as he knew no bad language, he had called him all the names of common
>  objects that he could think of, and had screamed: "You lamp!  You towel!  You
>  plate!" and so on.              --Sigmund Freud
>