
Why putting SSH on another port than 22 is bad idea - justinwr
http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/
======
16s
Security through obscurity is useless. I have heard people repeat this for the
last 20 years. They are wrong and they have no idea what they are talking
about. They just parrot what others say. Like chaos it perpetuates itself.

We camouflage tanks. We build stealth fighters. If obscurity had zero value,
we'd just paint the tanks bright pink with hot orange flames and drop all the
stealth research too. No need to sneak around. Obscurity is useless right?

Hide from the bear and it might not find and eat you. Move your ssh port and
your logs will have less idiots out there filling them up. That fact alone is
worth changing ports.

Obscurity has its place along side other tactics. And when you put it all
together, you'll have a more secure system.

So please cut the "Security through obscurity" crap.

~~~
rhubarbquid
Right, adding obscurity doesn't decrease security. It might help... worst case
it does nothing.

~~~
dionyziz
It might actually decrease security, as it gives a false sense of security and
people just take it as their only security measure in the end. Give them
obscurity and they feel secure. There are countless examples of this, I don't
believe I need to give some here.

~~~
migrantgeek
What are some examples? Like hiding a wallet in a shoe at the beach? Even that
is actually successful in some cases.

Most thieves aren't career criminals in search of wallets. Perhaps a
respectable working man sees a wallet of a young rich kid currently in the
water. The man could use some extra cash and sees large bills protruding from
the wallet and decides to take it. Why not? The man has a family and that kid
probably has a trust fund.

The wallet stuffed in a shoe or buried under a towel prevents temptation. It's
not actually more secure but it keeps honest people honest.

Nothing is really secure. Adding security is all about making something
harder. Harder to live with, harder to access, harder to do un-detected, etc.
If hiding something from plain sight makes it even slightly more troublesome
of a heist, it's actually security IMO.

It shouldn't be your only form of security but to write it off completely
seems silly.

~~~
petsos
Now imagine a million people from all over the world passing by. Would hiding
the wallet in the shoe help?

------
nairteashop
> When we start SSH on port 22, we know for a fact that this is done by root.
> But what happens when we move SSH to port 2222? This port can be opened
> without a privileged account, which means I can write a simple script that
> listens to port 2222 and mimics SSH in order to capture your passwords.

Well OP is assuming that I trust the root user of the machine I am SSH'ing to.
If I do, then what's the concern? The root user probably told me what the SSH
port is. If I don't, then well what's to say the SSH daemon on port 22 is
secure? In any case, there are many other ports that are not 22 and are <
1024\. You don't have to pick 2222.

Changing the port is not the ultimate defense against attack, but in my
experience it does reduce random drive-by type attacks. Same reason you raise
your windows when you lock your car - as easy as it is to break a car window,
a thief would rather steal from a car with an open window than smash your
windows and steal from yours.

~~~
theboss
If you don't trust the other side, you aren't administering the server, in
which case this article isn't written for you.

If you are, then the author is 100% correct that it is not a good idea to run
a SSH server above port 1024, or any port other than 22.

There are much better solutions to dealing with drive-by attempted logins, and
some of them are built into ssh.

~~~
nairteashop
> If you are, then the author is 100% correct that it is not a good idea to
> run a SSH server above port 1024, or any port other than 22.

Ok, but you haven't explained why. The author's stated claim is that running
an SSH server over 1024 means the connecting party cannot trust the server,
but that of course doesn't apply if _you_ are running the server.

If you want to truly secure your server, then yeah, changing the port doesn't
really do much but there are some minor benefits (see other responses in this
thread, and on the internet). I'm still not seeing the harm.

~~~
theboss
If you are running the server and your server is compromised than the attacker
can remove the ssh server you are running and put up his own malicious program
to collect your password if and only if they port is above 1024, and they
don't need root privileges, they can have www-data privileges or whatever

~~~
Volundr
Again if he can remove ssh running _as root_ on port 1xxxx, he can run his
ssh-alike on port 22.

~~~
theboss
but he can do 1xxx from an unprivileged NOT ROOT and he requires root to do
that with port 22, again

~~~
Volundr
So basically, he's gained root once to kill ssh running as root, but you think
that gaining root again in order to run something on port 22 is what's going
to stop him?

------
csense
> capture your passwords

With public key auth, an attacker can't capture anything useful (unless of
course they record traffic and later figure out a way to later capture the
private key [1], but this isn't a problem that changing the port will fix).

> mimics SSH

You can't mimic the key files in /etc/ssh/ssh_host_whatever_key without root
privileges, assuming these files are properly secured. So users will get an
unexpected warning that the host key has changed.

> simple script that listens to port 2222

True -- in cases where something isn't already listening on 2222. But if sshd
is started early in the boot process and listens on 2222, won't any script
started as a regular user be unable to bind to the socket?

[1]
[https://news.ycombinator.com/item?id=6609601](https://news.ycombinator.com/item?id=6609601)

~~~
edvinbesic
Also, what if ssh is on port 1023, which is still a non standard port, not
default but privileged, does this help in any way?

I'm asking because I don't really know but have to set up my own servers from
time to time (hobby admin).

Edit: I always use key based auth, don't allow root etc.

~~~
glesica
It cleans up your log files, that's why I do it. If you run ssh on port 22
your log files with be full of script kiddies with turnkey exploits spamming
every IP address they can find. Change the port and suddenly that the logs get
much, much quieter. So it's not really a security technique, it's a
convenience technique.

------
onedognight
> So running SSH on a non-privileged port makes it potentially LESS secure,
> not MORE. You have no way of knowing if you are talking to the real SSH
> server or not.

Of course you do: the SSH host keys. They are an integral part of the SSH
trust model. If you blindly accept any host key thrown at you, for a machine
you didn't just boot for the first time, then nothing can help you as you can
easily be man-in-the-middled _even if_ you are using port 22 (say from the
cafe wireless you are using).

------
atoponce
So many problems with this article, it's very hard to take seriously. Let's
start with not giving us reasons to protect the innocent. Oooh. Scary! He must
be a real pro at security! He's keeping secrets that are too valuable to
share! Please.

Next, he talks about anyone setting up a script to listen on a non privileged
port to collect passwords. Okay. So, are you saying I shouldn't connect to
your server then? Because if I set MY server's SSH port on 2222, I'm not
worried about anyone collecting passwords on MY server. Unless they have root.
Then I have bigger problems, and they can also collect my password when
logging on to port 22.

Also, security through obscurity is hardly useless. Sure, don't use it as your
only security defense, but it does have value. Obscurity means hiding
something of value from plain sight. Can you find that object? Sure. That
doesn't mean stealth is pointless. If so, we wouldn't have camouflage, stealth
bombers, and the NSA. Stealth can be be valuable.

Lastly is keys over passwords. Again, unless you have root on the box, you're
not getting the login password without brute force, or some protocol
vulnerability. And, if your password is weak, what makes you think using keys
is any stronger? First, you can create SSH keys without encrypting it with a
password. If you choose to encrypt it with a password, what makes you think
that password will be any stronger? Sure, remote password brute forcing us
infeasible, but scanning Github for private keys isn't. What's one server
versus another, unless you're targeting the user?

No, this article isn't thought through.

------
InclinedPlane
I put SSH on a different port because it cuts down on the drive by login
attempts. I don't have random users on my systems so I don't care that it's
possible for non-priveleged users to listen on high ports, there shouldn't be
anything listening on any port on my systems without my knowing about it. And
I don't use running ssh on a different port as an excuse for lax security.

Under different circumstances different tradeoffs would apply, but for my
current modes of use I don't see a compelling reason to put SSH on port 22.

~~~
edvinbesic
This has been my general theorycraft as well. It's still on a privileged port
but not standard. I'm curios as to if it has any effect though or if it's all
pointless.

------
uncoder0
If you are using passwords for auth with SSH you have already lost.

------
dijit
This raises a few questions.

firstly, How does he hope to mimic SSH with a script, when most 'companies'
will roll out DNS sshfp records, heck, I even do it at home. -- he'd need to
access the private keys in /etc/ssh/ to be able to do anything; unless he's
rooted my box, I don't see how he could.

Secondly; he'd need to kill my sshd process in order to make his script work,
sshd is not the kind of process driven behemoth that apache+modphp is, so you
can't brute force it to death- how are you going to kill it if you're not
root?

Finally; if you kill my sshd- where does your session go.

of course, all of this could be bypassed if you had root, but if you are root
you can do anything anyway- you could capture and decrypt data with the
private keys- surely that'd be easier.

(also, if you're root you can bind port 22 anyway, so it's a moot point)

------
smutticus
I run SSH on a non-standard port because it makes it easier to see when
someone is genuinely targetting me for attack. If I run SSH on 22 then I won't
know when someone is targetting me for attack since I'll be under constant
script kiddie attacks from everywhere all at once. If I have nothing on 22
then all those attacks just get silently blackholed. Which is ideal.

------
IgorPartola
The non root user issue is invalid. While I can start an ssh-like service on
port 2222 as a non root user, I cannot read the private ssh server key owned
by root. If the sshd got switched to one run by an unprivileged attacker, you
would get a bad server fingerprint and not connect (you wouldn't, right?).

------
danielrm26
Here's my response to this, point by point:

[http://www.danielmiessler.com/blog/putting-ssh-another-
port-...](http://www.danielmiessler.com/blog/putting-ssh-another-port-good-
idea)

~~~
summerdown2
I'm not sure your comment about the ability of a user to create a daemon on
another port being the same regardless is correct:

> He claims that you shouldn’t run your SSH daemon on a non-privileged port
> because anyone can spin up a daemon up there. Great point, except you can
> still do that even if you run your main one on 22.

... surely the point here is that this is not an internal server (if it were,
you wouldn't be getting tens of thousands of attacks in your example).

So in the case of a server running on port 22, someone with user level access
couldn't set up a daemon running on port 2222 because it wouldn't be allowed
through the external firewall. Put ssh on 2222, and you just opened the
firewall for a port any user can open.

I agree with a lot of your other comments, though.

------
badman_ting
Security through obscurity is not to be avoided outright, using _only_
security through obscurity is to be avoided outright. If you have an otherwise
secure system and then you obscure it in some ways, the worst that can happen
is that it has no effect. So the problem is in thinking it alone will protect
you, but it is not harmful in itself.

I think people throw this phrase out because it scans nicely and makes you
sound like you know what you're talking about, especially to yourself.

------
mh-
_I can write a simple script that listens to port 2222 and mimics SSH in order
to capture your passwords._

ignoring other authentication methods, PKI, etc..

------
danielrm26
Obscurity is only a poor security layer if it's used as a substitute for
security instead of a supplement.

[http://www.danielmiessler.com/blog/putting-ssh-another-
port-...](http://www.danielmiessler.com/blog/putting-ssh-another-port-good-
idea)

Camouflage on tanks doesn't remove the armor; it just lowers the chance that
it'll be needed.

------
ams6110
Running ssh on another port is typically something you do with your own
machines. If you're connecting to a foreign system, you either trust it or you
don't. The fact that ssh is on port 22 or not means nothing.

------
anaphor
a) Nobody doing this expects that it will increase the difficulty of cracking
the server via SSH, or at least nobody I've talked to does it for this reason
and I certainly don't. b) Since when is the uid that started a process a form
of authentication? c) Who cares what the default settings are for most SSH
clients? It's trivial to put it in your config file and forget about it. d)
Using port 443 for SSH is a legitimate use to get around firewalls/traffic
shapers.

------
nudetayne
Pretty sure I'll continue to put SSH on a non-standard port. I already monitor
my systems and its their logs heavily, and this cuts down on 99% of SSH-
related spam. Any attack that's serious, the port will not matter.

------
Aqueous
obscurity is not security. nothing's going to stop people from portscanning
your server no matter what port it is on.

~~~
thirsteh
Stop trying to make it so cut-and-dry. This is not pure cryptography where the
adage actually applies (a cryptographic construction should remain secure if
everything about it except the key is known.)

You shouldn't _mistake_ obscurity for security, but obscurity that doesn't
actively bother the user doesn't _hurt_ security. Again, emphasis on not
_mistaking_ obscurity for security, i.e. moving SSH to a port other than 22
does not mean that you can keep using password authentication.

Virtually all DNS servers on the Internet deny zone transfers (AXFR). This is
entirely an "obscurity" measure, but it's still useful _as long as people don
't assume one of their hosts won't be found if it has a guessable hostname or
IP address._ There are many other examples.

~~~
Aqueous
I don't see what moving it to 2222 does that turning off password
authentication, requiring public key authentication disallowing remote root
login, and fail2banning repeated login attempts doesn't.. Is there a
vulnerability in SSH or our asymmetric key cryptography that I don't know
about(other than the one possibly introduced to the random number generator)?
If there is, is the NSA less likely to use 2222 to knock on our door than 22?
The only thing - the only thing - that moving it to 2222 does is reduce load
avg due to brute force botnet attacks. And banning ips after 3 failed
connection attempts should have a similar effect on the load avg. That is the
only benefit. If you ask me that benefit isn't enough for me to give up the
time spent typing -p 2222 every time i run the ssh command.

~~~
thirsteh
Even if that's the only thing, that's not useless. Just don't mistake it for a
security measure.

Also, you can put port numbers in your SSH config, so you never have to type
them.

~~~
Aqueous
I move from computer to computer a lot and don't take my SSH config with me.
Typing the extra -p 2222 is tedious when it doesn't give me any benefit.

The only thing moving the SSH daemon does is give us a slight, conditional
performance benefit (that using fail2ban on port 22 also gives, along with an
_actual_ security benefit). It does not give us any security benefit at all.

