Hacker News Reader

Comment by Osmium | Hacker News Reader

There are lots of good guides online on how to protect yourself from this (disable password-based auth, or use 2-factor auth, Fail2ban etc.), but there's one piece of advice that crops up a lot that is probably a bad idea, and that's changing the SSH port. This can give (at best) a false sense of security and (at worst) actually reduce security if you choose a port number above 1024, because then malware could pose as SSH without requiring root access and then steal your password once you've entered it.

Just thought it was worth mentioning because I recently went through all this myself to try and secure a Raspberry Pi and it was news to me...

View on HN

I agree that changing the port is not a great security measure in theory and I think it should be last of a large number of things a person does to secure SSH.

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).

Not to mention the hardware resources. Prior to changing our SSH port, the fail2ban process was #3-5 in terms of CPU time on many of our boxes. Changing the SSH port puts it out of contention for even the top 10.

If you must then just limit connections per minute that can be opened per address to the sshd port in the host firewall instead. Sshd should be configured to close the connection after a number of failed logins. Now you get the same effect without a daemon parsing logfiles.

I recently added UFW configuration to my provisioning scripts, so we now use UFW's 'limit' rules to do that on the port we use for SSH. We could probably get away with moving it back to the default with this in place.

I still think that it's a good idea to change the default port for sshd, even if you don't let root to login and use public key auth and fail2ban. Why? Because this "obscurity" helps keeping false possitives to a reasonable low number, so you can actually see if there's a tageted attack or not.

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

do (can?) auth failures display passwords? if so, is that a good idea? people (ie me) sometimes enter the wrong, but valid password. having that logged somewhere seems like a bad idea.

If you use public-key it only shows the ip. I don't know if you use password, 2-factor auth or Kerberos it shows any additional information.

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

The standard sshd does not log failed passwords. A few years ago I was seeing a lot of brute force attempts and I was curious to see the passwords. The only way I could do it was to edit the source code of sshd to add my own logging line and recompile the whole thing.

steal your password

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.]

Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise).

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?

If you use "sudo foo" in the remote shell, and then type your password, it could steal that. Or even if you somehow obfuscated your sudo password, it could change the command presented to sudo, so after you type your password, the new substituted command would be executed. Exaple: you type "sudo less /var/log/messages" but the fake-ssh tells the remote shell that you really typed "sudo email-me-all-your-data". Then the real sudo authenticates you, and executes the command you didn't type.

With "password" authentication method, the password is not transmitted to the remote server. (AFAIK)

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.

about password auth - you're wrong (AFAIK). i even gave a reference in my original post. didn't you bother to check it?

I am wrong. No.

There exist ways for a client and server to convince each other they share a secret (such as a password) without giving an adversary enough information to infer the secret. Here is one such: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

does that work when it's a system password that exists in a hashed (scrypt) database? it seems like it would leave things open to someone stealing the hashed system password.

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.

I'm not an expert, but your question has interested me for quite a while as well, so I did some research. It seems that SRP does not require the plaintext password to be stored by the server.

> 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

interesting, thanks. turns out there are even patches for ssh! http://srp.stanford.edu/links.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.

Even if it's not possible to improve the security of a single-server system, there is definite room for improvement in the real world.

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.

Changing the port is still a worthwhile thing to do in many cases.

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.

Changing the port number can boost security if it makes it easier to scan the log for attempts.

I think it is a good idea.

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

Additionally you could also use something like fwknop[1]. It opens the ssh port for your ip when you need it and closes it after a preset time has passed.

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

> above port 1024 malware...

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.

Reply on news.ycombinator.com