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 [EMAIL PROTECTED]