[95200] in cryptography@c2.net mail archive
Re: improving ssh
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Thu Jul 19 09:26:49 2007
Date: Mon, 16 Jul 2007 16:49:43 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Ed Gerck <edgerck@nma.com>
Cc: Cryptography <cryptography@metzdowd.com>
In-Reply-To: <46991969.5070502@nma.com>
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@metzdowd.com
