BUT- I worked at a company a while back that had fail2ban notify us when by E-mail when it banned people. Changing the SSH ports dropped the bans per 6 month from 80-60 to 1-2. So while its certainly not the only thing you should do, there is something to be said for obscurity (in addition to existing real security of course).

If I see a auth failure "root"-"123456" I instantly know that's not a targeted attack, it will unnecessary fill my log files that will add with time and become a burden to audit my systems, which at some point I either don't do it thoroughly or any at all.

SELinux takes care of controling which application could open outbound ports, so if your box is properly configured, there are other ways to reduce the impact if the box is exploited

I would guess that if you enable debugging it will show some identifiable information, I never had to debug it.

i had always assumed that the protocol somehow protected your password, but reading the spec at http://www.ietf.org/rfc/rfc4252.txt that's not the case (and i've pretty much convinced myself it's not possible to do better).

learn something new every day...

[apart from the reference above, someone else here claims to be logging these things.]

if this can be made to work for ssh when using system passwords that would be very cool. but to my (inexpert) eye it seems unlikely (without relying on a trusted client). do you have a description for that case?

the problem, in short, is that the password is not shared. the server does not know it - it only knows the hash. and the hash is not sufficient as a shared secret.

> SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server.

Source: http://srp.stanford.edu/analysis.html

but i get the impression that still doesn't mean that ssh can be made to work with system passwords without transmitting them (over an encrypted channel). i don't understand why - maybe srp requires a particular kind of hash?

ah yes - this answer http://security.stackexchange.com/questions/23821/srp-can-th... gives some details.

Assume for a moment that you have to transmit the password to the server instead of using proof of knowledge algorithms. This makes the server a potential point for stealing the password. This is of negligible risk in theory, because the server has access to itself by definition. But in the real world people reuse passwords. So in the real world you can improve security by hashing what the user types with server-specific data (public key?) and using that as the server-specific password. Then someone that can capture the password can only log on to that specific server.

However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey, keyboard-interactive). As the name says, keyboard-interactive sends your keystrokes, one at a time (bar buffering) to the remote server.

This is required, for example, when using PAM, as PAM requires the actual authentication key.

So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?

Military tanks aren't painted green because green paint is more bulletproof, they use green because hot pink tanks get shot at more.

Changing the port isn't armor, it's camouflage. Camouflage is still a useful thing.

Your point about not using a port north of 1024 is solid advice.

I think it is a good idea.

It is the expectation that this is enough that is the bad idea.

[1]http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop

Im using this https://github.com/stealth/sshttp to run it on port 443.

The other port it actually runs on is firewalled off from outside.