improving ssh

[Nicolas Williams]

Doesn't this belong on the old SSHv2 WG's mailing list?

On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote:
> SSH (OpenSSH) is routinely used in secure access for remote server
> maintenance. However, as I see it, SSH has a number of security issues
> that have not been addressed (as far I know), which create unnecessary
> vulnerabilities.

The SSHv2 protocol or OpenSSH (an implementation of SSHv1 and SSHv2)?

> Some issues could be minimized by turning off password authentication,
> which is not practical in many cases. Other issues can be addressed by
> additional means, for example:
> 
> 1. firewall port-knocking to block scanning and attacks

Do you think that implementations of the protocol should implement this?
(From what you say below I think your answer is "yes."  Which brings up
the questions "why?" and "how?")

> 2. firewall logging and IP disabling for repeated attacks (prevent DoS,
> block dictionary attacks)

SSH servers could integrate features like this without needing firewall
APIs.

> 3. pre- and post-filtering to prevent SSH from advertising itself and
> server OS

Unfortunately SSH implementations tend to depend on accurate client and
server software version strings in order to work around bugs.

Anyways, security by obscurity doesn't help.

> 4. block empty authentication requests

What are those?

Are they requests with an empty username?  The only SSHv2 userauth
methods that support that are the GSS ones, and that's a good feature
(it allows the server to derive the username from the client's principal
name).

> 5. block sending host key fingerprint for invalid or no username

Currently the only way to do this is to configure SSH servers to support
only SSHv2 and only the gss-* key exchange algorithms (see RFC4462,
section 2).  There exist implementations that support this.

To get rid of the "host authenticates itself first" attitude for all
non-GSS-based SSHv2 userauth methods will require radical changes to the
protocol and deployment transitions.

> 6. drop SSH reply (send no response) for invalid or no username

The server has to answer with something.  Silence is still an answer.
So is closing the TCP connection.

> I believe it would be better to solve them in SSH itself, as one would
> not have to change the environment in order to further secure SSH.
> Changing firewall rules, for example, is not always portable and may
> have unintended consequences.

Coding to firewall APIs is even less portable (heck, not all OSes have
firewall APIs).

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com