Security using User Names

OpenSSH will not reveal to the attacker whether it was the username or the password that was incorrect, just that the login attempt failed.

One could always test a username by trying to send mail to it, which is an imperfect indicator. Other services (e.g., finger) can potentially reveal usernames also.

Installing and using something like fail2ban or denyhosts will reduce the number of brute-force login attempts that clutter your logs.

Thanks for the help! I was just trying to get a rough sense of how important the relative guessability of the username would be.

@xenox:

I assume (as the attacker) the server requires a user name and a password

Never assume the attacker is dumber then you are.

Setup SSH to use ONLY certs, then you don't care who or what guesses your user names.

@vonskippy:

@xenox:

I assume (as the attacker) the server requires a user name and a password

Never assume the attacker is dumber then you are.

Setup SSH to use ONLY certs, then you don't care who or what guesses your user names. Yeah, this was a security policy that I used for the first time while setting up my Linode. After seeing the bafflingly large number of attempted logins in my logs for root and various other usernames, I'm very happy that I set this up and that it is commonly mentioned as part of various guides.

Why not just change the port and/or only permit access from trusted ip's?

Because security thru assumed obscurity isn't (hint: they're called port scans).

And some people don't have static IP's or need to access their systems while on the road so a "trusted IP" isn't always available.

@vonskippy:

Because security thru assumed obscurity isn't (hint: they're called port scans).

And some people don't have static IP's or need to access their systems while on the road so a "trusted IP" isn't always available.
It will still eliminate 99.9% of your failed login attempts.

There are two situations where security is concerned:

1) You're using strong passwords/keys, and those 99.9% don't have a chance anyway. They're just log spam.

2) You're not using strong passwords/keys, and you're dead in the water anyway, because any half-decent attempt will succeed, regardless of changing ports or whatever.

If you're concerned with log spam, use logrotate. That's what it's there for.

• Les

I recommend at least ip rate limiting plus maybe fail2ban or something like it. This is because

I do not know the motivations of the people running the feeble hacking tool.

@vonskippy:

Because security thru assumed obscurity isn't (hint: they're called port scans).

And some people don't have static IP's or need to access their systems while on the road so a "trusted IP" isn't always available.
Here's the funny thing, though.

If you're being targetted by an attacker then, yes, a port scan will expose the port anyway. BUT if you're just seeing random internet noise then simply changing the port will stop this because your random zombie doesn't port scan before hand (it takes too long, especially if you DROP traffic).

This means that you're not wasting CPU cycles negotiating SSL; you're not wasting disk space on logs, CPU on fail2ban or similar, resources on accepting connections etc etc.

It's a very very small win, but it is a win :-)