
Why Putting SSH On Another Port is a Good Idea - danielrm26
http://www.danielmiessler.com/blog/putting-ssh-another-port-good-idea#.Umsq_hbdDzU.hackernews
======
djcapelis

      2. Next he talks about this non-root listener issue. 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.
    

I don't think I understand this point at all. What is it that you're trying to
say?

Are you sure you understood the original post's point?

    
    
      djc@capelis.dj:~$ nc -l -p 14
      nc: bind to source :: 14 failed: Permission denied
      nc: bind to source 0.0.0.0 14 failed: Permission denied
      nc: failed to bind to any local addr/port
      djc@capelis.dj:~$ nc -l -p 1414
      ^C
    

See the difference?

(Edit: The original blog entry has now been edited to slightly clarify the
wording. But the update mostly seems like an attempt to rapidly justify the
author's original point.)

~~~
city41
Privileged ports are why I disagree with this rebuttal. I want some assurance
that when I ssh into a box, that I'm hitting a true and sanctioned sshd.

~~~
danielrm26
> I want some assurance that when I ssh into a box, that I'm hitting a true
> and sanctioned sshd.

You don't get that from it being on 22; you get it from verifying host keys.

~~~
djcapelis
> You don't get that from it being on 22; you get it from verifying host keys.

You know how you just wrote a blog post talking about how more layers of
security are better even if all you're gaining is _obscurity_? This isn't an
exception. And it is a valid point that by moving from a privileged port to a
non-privileged port, you just traded away a layer (arguably a more useful one
than you gain by moving away from 22) for absolutely no reason. (You could
move to a different privileged port and still get everything else.)

tl;dr: You advocate giving up an actual layer of protection for a layer of
obscurity. This is especially puzzling when you could get both.

Further, the reality of the situation is that as a practical matter most
sysadmins are terrible about key management and when they see those warnings
the very next thing they almost always do is immediately delete the key and
hastily attempt to login to the machine via ssh. (The better ones to see
what's going on and try and fix it, and the worse ones just assume that the
key changed because sysadmins change keys all too often without notifying
users and don't investigate at all.)

It turns out that humans are annoyingly predictable.

~~~
danielrm26
Ok, fair point.

I'd say it differently, though. Instead of defending the original point, which
was bad, I'd instead say among all other controls--most important of which is
patching, removing passwords, etc.--one control is running below 1024.

I could go for that.

Except I actually think the gain from being up high (over 60K) is greater than
the gain from being below 1024. It's not about being invincible, it's about
not being a target at all.

~~~
MarkMc
Firstly, I like the tone you used to concede your original point.

As to whether the port should be below 1024 or above 60000, I am undecided.
I'd love to see some empirical data on this: let's say I run ssh over several
days on port 22, port 762 and port 90332. How many connections do I get for
each port?

~~~
jstanley
For 90332, I suspect not many :)

------
dotBen
The reason he's right is most attacks on SSH are one-dimensional.

In most cases the dimension is IP range - an automated process moves from IP
address to IP address examining port 22 for any common vulnerabilities. Rarely
do these processes check all ports. Moving your SSH deamon to a different port
prevents those automated processes from _then_ hitting your security layer on
whichever port you are running.

The other dimension of attack is when an attacker is focusing on your IP
address specifically. Then he probably is going to nmap your IP and discover
which port(s) SSH is running on. Changing the default port for SSH doesn't
help here, but this use case is far less common.

Like others have said, changing port doesn't remove the need for security
measures (cert-based/passwordless login, disable root, fail2ban) but it
reduces any of those even being tested in the first place when most of your
attempted attacks are IP-range based.

~~~
__david__
Turning off passwords and only using keys also mitigates the standard brute
force attacks that happen. Frankly I'd much rather do that then have my server
on a non-standard port.

~~~
wildgift
Attacks on port 22 end up consuming CPU.

~~~
yeukhon
and attack on other ports don't?

~~~
riobard
The assumption is that bots don't usually scan other ports: way too
inefficient for them to scan all ports for every potential target host.

------
quesera
In moving sshd to an alternate port, I've noticed two things: a _greatly_
decreased amount of log noise from dictionary attacks, and a moderately
_increased_ amount of portscans.

It's reasonably clear to your average net malfeasant that any host running
recognizable services is going to be running sshd.

So why not do both?

Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you
swimming in interesting data.

Then run real sshd elsewhere, possibly filtered, possibly port knocked, and
hopefully permitting key-based auth only.

~~~
mikegirouard
I've done this in the past with some pretty good results. Though, I've dropped
it because I found myself constantly locking myself out of my own machines.

I can't deny, it is a cool technique though. PortSentry is a good tool to use
for just this. Anytime someone came to :22 and the machine just disappears.

------
kenrose
Actually, one thing I've found useful is keeping an sshd listening on port
443. I know, I know, sacrilege reusing the HTTPS port, right?

The benefit of this is that it can allow you to tunnel through an HTTP proxy
(e.g., like in a corporate environment). Many HTTP proxies only allow traffic
through to port 80 and port 443. The benefit of ssh on port 443 is that if the
proxy is handed a CONNECT verb, it will transparently just transmit data
between your client and the remote server, irrespective of what that content
is. In fact, this behaviour is what makes HTTPS remain secure when going
through an HTTP proxy.

You can use this to tunnel ssh through an HTTP proxy. Putty supports this out
of the box, but if you're using openssh, you'll need corkscrew also.

You can always try to tunnel to an ssh server on port 22, but most proxies
will hand you HTTP403 on any CONNECT request to a non-port 443.

More info at
[http://daniel.haxx.se/docs/sshproxy.html](http://daniel.haxx.se/docs/sshproxy.html).

~~~
antocv
> Many HTTP proxies only allow traffic through to port 80 and port 443. The
> benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb,

Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a
corporate environment where nothing is let out on port 80, except through
their HTTP proxy. However, port 443 is allowed out.

> In fact, this behaviour is what makes HTTPS remain secure when going through
> an HTTP proxy.

That would be a MITM against https and it doenst work that way.

If you would go over the http proxy to connect to your sshd on port 443, that
would be stupid as the proxy would see your connections. Its much easier and
better to just connect directly without asking the proxy.

~~~
grahamedgecombe
It can work like this - see: [http://wiki.squid-
cache.org/Features/HTTPS#CONNECT_tunnel](http://wiki.squid-
cache.org/Features/HTTPS#CONNECT_tunnel)

~~~
kenrose
Right. Sorry, in case I wasn't clear, the HTTP proxy acts as a _proxy_ for
HTTP on port 80, but _tunnels_ HTTPS traffic (and anything else including ssh)
on port 443. The tunnelling is done using the HTTP CONNECT verb.

------
bcoates
He's right that "security by obscurity" isn't the entire story -- it's more
like a mnemonic device for the more complex idea that:

1\. In the real world, security resources aren't free.

2\. Security decisions are made by users.

3\. Humans will engage in risk compensation [1]

4\. Setting policy doesn't change people's brains, it just tells them what to
do.

5\. It doesn't matter what you intend, it matters what users actually do.

The upshot of this is that any security policy that is highly visible and
highly inconvenient will reduce your security, and has to have a _substantial_
benefit to justify its cost. You can say "I'll do stupid port reassignment
tricks, and I'll also mandate that passwords are forbidden, and require that
private keys be managed properly" but at three in the morning when the
whatever is overdue and not working what you're gonna get is:

 _I 'll just do password auth with root:root, nobody ever hits port 24601
anyway. Besides, look at this page [2], using a strange port makes me
invisible like the Predator and makes me four thousand times more secure! I
really want to believe this so I do._

Also, subverting scanners is an anti-security move, not a pro-security one.
Scanners are a helpful tool to identify what the hell is running on your
network. Your security efforts have to find _every_ hole, the bad guys only
have to find _one_. Don't put yourself at an even bigger disadvantage by
making your systems harder to analyze.

[1]
[http://en.wikipedia.org/wiki/Risk_compensation](http://en.wikipedia.org/wiki/Risk_compensation)

[2] [http://www.danielmiessler.com/blog/security-and-obscurity-
do...](http://www.danielmiessler.com/blog/security-and-obscurity-does-
changing-your-ssh-port-lower-your-risk)

~~~
INTPenis
I think you're making some assumptions about people in your argument.

This is really very simple, security is a multi layered thing and security by
obscurity is never a good layer by itself but part of a larger "onion" it can
be helpful.

Bottom line, good security always takes discipline because humans are the last
line of defense. There is no one button solution and anyone in security should
know this so the argument shouldn't even be present about that point. Changing
the SSH port towards the internet is a very pragmatic solution to spam in your
logs.

I know people will mention fail2ban but I'd rather not have a log parser
running day and night on every internet facing server when I can just change
the port and get rid of all that spam Forever. (I have yet to encounter one
robot that can dynamically scan for SSH ports and use anything else than 22).

Also, in my personal opinion, using a high port like 24601 is insecure because
if your SSH daemon ever crashes then an unprivileged user on your system can
listen on that high port and receive your precious connections. So personally
I always use an alternative ssh port under 1024.

~~~
marcosdumay
> security by obscurity is never a good layer by itself but part of a larger
> "onion" it can be helpful.

That's ok. Just don't pretend that you are getting anything worthwhile from
that policy. All you get is a 10 bit door, added (not multiplied - so, it does
not increase your overall security) to whatever security you already had.

In computer security, people normally consider anything with less than 64 bits
worthless. A 10 protection can be brute-forced by hand.

As humans work, changing that port is a clear indicator of an admin that
didn't care about avoiding the less secure modes of SSH. If you are looking
for obscurity, I'd consider a non-standard port (and concern about bots) to be
a huge flag announcing "This system is exploitable".

~~~
mscarborough
> I'd consider a non-standard port (and concern about bots) to be a huge flag
> announcing "This system is exploitable".

Every system is exploitable. How is changing a port indicative of someone who
did nothing else to secure their shell access? I keep all mine on 22, but have
been considering moving it just to keep the logs a little more sane for when I
actually have to read them to find something.

------
cldr
Ouch, camouflage on a tank is a good analogy. Nice response post.

In addition to, as the author encourages, being "weary of the 'by obscurity'"
argument (as I'm sure we all already are), I would also advocate being wary of
it :)

~~~
relix
No it isn't. Every server runs SSH, so this is more like there's a field, and
you know there's a tank in the field, but you can't see it.

The next thing you do then is take out your standard radar device which scans
the field, and pinpoints exactly where the tank is in 3 seconds, and then you
aim your tank buster at that spot and fire.

~~~
maaku
Or, you put up a fake, camouflaged tank and let the enemy reveal themselves
when they attack it. (Leave 22/tcp open as a honeypot, triggering an immediate
iptables drop).

------
teddyh
As I understand his argument, it’s “Changing port number add security,
therefore it’s a good idea.” I think nobody argues that it _adds security_.
The problem is that:

1\. It adds _very little_ security: 16 bits is not much, and the result is not
256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead
effectively still 256 bits, or 256+8×10⁻⁷³ bits.

2\. The security it adds is itself bad (sent in cleartext, easily brute-
forced)

3\. These problems stand against the many drawbacks of this previously
discussed (complexity, confusion, etc.).

And the final argument: If increased security is what you want, _simply
increase your key lengths and /or password lengths_, and you will get much
more than 8×10⁻⁷³ bits of security, without any of the above problems.

~~~
sdfjkl
I changed it because it makes FreeBSD's nightly security run output not
contain thousands of lines like this:

    
    
        Jul 28 23:53:57 hostname sshd[1068]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55040 ssh2
        Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
        Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
        Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
        Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
        Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
        Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
        Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2
        Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2

~~~
belorn
Here is an even worse log output nightmare: Enable logging in the
firewall/ids, which show _all_ packets sent to a closed port.

It's massive. Endless. _Like looking into the endless void._

Of course, my computer does not log packets that are just bouncing against my
computer. It would distract me too much, and maybe it would do so for you to.
Easier just to tell the computer to not bug you about it, and trust that the
"attack" is harmless enough so to not to bother logging it at all.

~~~
sdfjkl
This is the default email that a freshly installed FreeBSD sends you every
night. It also contains a bunch of other bits. That's a bit different than
subscribing to firewall spam.

~~~
teddyh
It follows, obviously, that creating these log entries in the first place
(much less _reporting them_ ) is a silly thing to do, just as receiving
firewall logs for every packet to a closed port would be.

------
sarnowski
The "change-port" discussion for SSH is so boring :-/ OpenSSH is I guess the
most secure daemon on all your servers. People should more think about to
change the HTTP(S) ports of their non-public facing sites and other daemons
and frameworks they use.

~~~
quesera
> OpenSSH is I guess the most secure daemon on all your servers.

Probably correct. However, sshd _should_ be the only public facing daemon that
hasn't dropped root privileges immediately after binding to its privileged
port.

So it should be the only daemon that can directly offer root privs to an
attacker.

I say "should" because it's a big world out there and people do some bizarre
and indefensible things. Sometimes merely lazy things, but the net effect is
the same.

~~~
peterwwillis
It is almost the same thing to offer non-root privs, because of the great
number of patched and unpatched priv escalation holes in Linux. Almost
guaranteed you will be able to get root if you get normal user privs.

------
mdmarra
Better solution: require VPN connectivity and don't expose SSH on any port to
the public Internet.

Running services on non-standard ports will make the next admin that takes
over this server want to track you down and smother you in your sleep.

------
programminggeek
Here is something to think about, the author is right, but if you follow many
ssh setup tutorials that say to move to say port 25000, you are less likely to
be port scanned than the default, but still more likely than if you had used
something totally random like say port 42 or 818. By me even writing this
clever hackers will start scanning those ports too, just to be sure they are
hitting everyone. That being said, any port is better than the standard one
and picking an unused port instead of the standard ssh port will give a
reasonable 80/20 benefit for a lot of people.

~~~
eslaught
Port scanning is generally automated (edit: and scans _all_ ports, not just
the handful you listed), so it doesn't actually matter which port you pick as
long as it's not 22. Port scanners like nmap are widely available, so the time
to actually figure out which port is running SSH is quite short in practice.

Basically, there are two classes of people:

1\. Those who use port scanners.

2\. Those who do not.

If you are being attacked by someone in class 1, then moving your port gives
you absolutely no protection. Thus moving your port is only worth anything at
all if the percentage of class 2 people is significant.

However, if you also consider the probability a person in each class has of
actually compromising your machine, then the security looks less convincing.
Yes, it might be true that 95% of people don't bother to use a port scanner,
but the most competent hackers are almost certainly going to be in the 5% that
do use one.

~~~
GhotiFish
those numbers don't look good at when you take a look at what those two
classes of people are doing.

ie. 1. is targeting you specifically, 2. is bot targeting everyone

when presented with two options, thinking of those options as 50:50 is
natural, but it's really more like 0.0000001:99.9999999

~~~
mjhall
A bot doesn't necessarily only scan port 22 in a range - nothing stops the bot
herder making it scan 1-1024 instead.

~~~
riobard
Yes there is. It's called economics.

------
gmuslera
Standard or not standard port, you still should use port knocking in a way or
another (or only enable it for the specific IPs that can access it ever).
Internet don't even should be able to know that you have there a service that
is only for you or for a very small amount of people.

If a remote vulnerability is discovered in the server (happened in the past,
don't rule it out for the future), you will be attacked, and it won't be a
brute force attack to be blocked by fail2ban or similar. You can be scanned in
any time, put in a database as "having ssh version x running in y port" and
get ready for future use.

And if well simple port knocking could be defeated inspecting your traffic,
there are variants like fwknop that are resistant to that kind of interception
or replaying.

~~~
rsync
Agreed. Contrary to the naysayers, port knocking is an _unalloyed good_.

Whatever your setup is, it's _better_ if it doesn't show up in a scan at all.

The "knock is a weak password" argument is silly - nobody suggests using
_only_ the knock, but rather to use the knock in addition to your existing
auth scheme.

------
tuzakey
Its kinda silly to move the port, a targeted attack is going to start with an
portscan of you box, the attacker is going to say "oh what’s this here on port
2222?" and promptly discover that its ssh listening on a high port. Port
knocking would make that discovery less likely I suppose but its still all
treating a symptom of a bigger problem.

So why not solve the problem with something a little more proactive like
turning off password auth and go for sshkeys only. Maybe toss in something
like fail2ban if you want to interrupt kiddies scanning your boxen.

That said high port ssh can be nice if you're frequently on restrictive
networks and getting out on port 22 is impossible.

edit(spelling)

~~~
tszming
Yes, you have pointed out - a targeted attack.

What if non-targeted attack like a robot scanning all port 22 in your
datacenter?

~~~
tuzakey
Thats where fail2ban is useful, pick a number of failed auth attempts on _any_
service you care to integrate, lets say 8 PAM failures, and trigger a rule
that inserts an iptables rule to drop/reject the attackers IP for 5minutes.
That will time out the ssh scan for all but the most patient scanners. If you
shared the fail2ban database across hosts you could inject null routes for the
offender into your router or block them at your firewall.

~~~
tszming
I think you have missed the point - you should tell why using non-standard
port is less secure, not provide me an alternative, because I would also argue
VPN is better fail2ban.

You cannot neglect the fact that there are vast amount of bots scanning only
port 22 in the Internet. We know this because we have found the evidence in
our OWN logs, not from those security experts always saying security through
obscurity is bad and therefore we should do nothing.

~~~
lotyrin
Because moving your port has an opportunity cost.

Documenting and configuring it has a non-zero cost which could be spent doing
something else more impactful.

I've never seen an infrastructure where there was a sufficiently advanced
state of security such that obscuring the port numbers of services was the at
top of the todo list.

Unless people recommending these things work for shadow organizations I've
never heard of, I'm pretty sure it's something done without any kind of cost-
benefit analysis.

What are the odds of a SSHd zero-day? Or, more specifically, what are the odds
that someone with zero-day knowledge would be so stupid as to decide to risk
the vulnerability being discovered by others by using it in a horizontal
search of all running SSHds?

Because it has to both be more likely than any other attack that could be
mitigated (and port obscurity would have to be the most effective solution)
with the same effort.

Pretty sure that for virtually all infrastructures, auditing that your systems
are properly isolated, users and services have the least privilege possible
prevent massively more probable attacks, and that firewalling services or port
knocking or really anything are more effective solutions for this attack.

------
Sami_Lehtinen
One question, why people always say that disabling passwords is important.
AFAIK, passwords with keys is better than keys only. Now if someone gets the
keys they can access the service with those keys without the passwords.
Disabling passwords just makes security in one way worse. Think about chip &
pin, because you have your credit card, wouldn't it be smart to disable PIN
completely? Of course key ring could be encrypted, but that still allows off-
line attack against it. If password is queried on-line, you can limit password
attempts which you can't do in off-line situation. - Thanks

~~~
inigoesdr
Disabling password-only authentication doesn't prevent you from using a
password on your key. When you login with key-based authentication you will be
prompted for the password for your key, even if password authentication is
disabled, because they are two separate & unrelated processes.

------
BryanB55
Anyone use Dome9? ([http://dome9.com](http://dome9.com)) they close all of
your ports and open them on demand via chrome extension or mobile app for when
you want to use SSH.

~~~
GrinningFool
Seems kind of like inetd? Except having to trust the reliability and
availability of a remote provider to manage it for you?

------
druiid
There's nothing inherently good or bad about running SSH on another port.
Honestly this argument is a bit silly given how easy it is to port-scan and
many scripts out there will do that before actually trying anything.
Essentially all you're going to do is make things annoying for your users.

The really real good idea is running a VPN in front of all of your servers and
never allowing SSH access to the outside world. I have two ports (at most)
open on all of my servers: 80 and 443. OpenVPN takes less than an hour to
setup. There's no reason not to set it up!

~~~
virtualwhys
Agreed, VPN via physical firewall is a particularly nice solution.

Sounds like you've offloaded mail, dns, etc. elsewhere if you only have at
most 80 and 443 open.

------
Oculus
That was very fair response. Kudos for being able to attack the points, not
the person.

------
ballard
It's probably already been said, but it can be said enough: Security through
obscurity is valid for marginally increasing the total security margin, but
relying on any one practice or technique always smells like a dangerous
approach. (Hence the hollistic practice of many overlapping features providing
defence-in-depth.)

Changing ports reduces the threat surface in limited but practical ways,
however far more effective would be using secure port knocking (say fwknop
with GPG and is also time-based).

Secure port knocking and changing ports together would be perfectly valid. In
fact, I have deployed these for openbsd jumpboxes guarding core
infrastructure. So breaking in would require defeating fwknop with GPG and
ssh.

(If anything needs public auditing, it's GPG and SSH. VPN code also
considering the logic often makes OpenSSL look simple. )

------
_mpu
By experience, it just lets you avoid getting a shitload of brute-force
attacks. So I do it.

------
cenhyperion
On my personal boxes I use a combination of non-standard ports, disabling
password auth (seriously, this will do more for your security than anything
else), and fail2ban. Even with key authentication fail2ban still blocks
several IPs a day.

------
n0on3
I apologize but there is no such thing as "it is (ALWAYS|NEVER) a good idea"
no matter how many blog posts people wrote about that.

It just depends on which are the tradeoffs between the antithetic goals that
you have when you do any kind of security hardening.

Aside from that, since many already mentioned port knocking as another layer
in the pile of this game, let me point out that not all port knocking (-like)
implementations are __that weak __, look e.g. at knockknock
[[http://www.thoughtcrime.org/software/knockknock/](http://www.thoughtcrime.org/software/knockknock/)
].

------
csdreamer7
Wasn't it posted on HY that modern exploit tools like metasploit scan all
ports for SSH services by default now?

That was my biggest reason not to bother changing the port.

Is there any real reason beyond that? (I do use fail2ban to block repeated
attempts.)

------
abalone
He's overreacting a bit. Port knocking is not just an "obscurity layer". It's
more akin to a PIN or weak password.

The condescending opening is a tip off ("people who _almost_ understand the
topic").

~~~
jvdh
Even so, it is still a very weak security layer that you are adding on to
something that is already very secure. Does that really make it less secure?

Now running SSH on a different port is an even weaker obscurity layer, but
still, it still adds some security.

~~~
teddyh
I think _nobody_ is denying that it _adds security_. The question is, does the
added security offset the increased complexity and associated difficulties?

~~~
rsync
This is, I think, the only valid argument against knocking.

The standard (and always condescending) responses are that it is either a very
small password and/or that an attacker can record and replay the knock from an
eavesdropping position.

Both of those are true, of course, but they neglect that the knock is always
_in addition to_ whatever else you are already doing to protect ssh.

So I have always rejected those arguments and continue to evangelize for port
knocking.

BUT, the added complexity part is a valid point. I try to keep systems as bare
and simple as possible and hate to add even a single unnecessary dependency
package. I am happy to say that (on FreeBSD, at least) knock[1] is light,
simple, and has run for _thousands of days_ on busy production servers as well
as my personal servers without even a single incident.

[1] /usr/ports/security/knock

~~~
teddyh
I used the word “complexity” not in the meaning of “the installed system is
more complex for having more software in it”, but in the sense of “I don’t
want to feel like I’m entering Diagon Alley just for wanting to use SSH” –
i.e. complex to _use_ , not complex to _set up_.

But your interpretation works too – they are _both_ valid arguments, in my
opinion.

------
fletchowns
How about: Why it doesn't matter what port you run SSH on

* Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port

~~~
__david__
Why would I use a VPN when I have SSH? IE, why do you think that a VPN is
somehow more secure than an SSH connection?

~~~
zorbo
VPN is not mutually exclusive with using SSH. What he's saying is that people
should firewall their SSH ports to only allow access from trusted IPs, and
VPN's make that easier to do.

~~~
__david__
So that means you can't SSH into your remote machine from an arbitrary
connection? What do you do when you're traveling?

~~~
fletchowns
You use a VPN and then connect to SSH

~~~
__david__
So then we go back to my original question. Why do you think a VPN is more
secure than SSH?

IE, Why is it important that your SSH port only be connected to by known IPs,
but your VPN port is OK to be connected to from anywhere?

~~~
fletchowns
It's not really about one being more secure than the other. They are both very
secure. It's just good to have multiple layers of protection in case something
goes wrong somewhere, whether it's caused by human error or something else.

------
msimpson
Let's start with a secure implementation for remote access:

1\. SSH:

Port - 22

Protocol - 2

PermitRootLogin - no

StrictModes - yes

MaxAuthTries - 1

PasswordAuthentication - no

PermitEmptyPasswords - no

ChallengeResponseAuthentication - no

UsePAM - yes

2\. PAM_ABL (auto-ban by account after three retires)

3\. IPTables (auto-ban by IP after three retries)

So in the above implementation an attacker has three attempts, max. This means
the logs are quiet, yet accurately depict intrusion attempts. This also stops
brute force attempts in their tracks and requires no exemptions to normal
workflow.

If, under the above circumstances, I were to obscure the port as well, this
would serve no purpose than to completely side step script kiddie brute force
attempts (as minimized as they would be in this configuration) with the
horrific side effect of forcing my users to maintain (at the least) a config
entry for the custom port assignment. Which, by the way, would become
perpetually worse with the amount of servers and users in play.

This is why obscuring the port is such a bad idea.

And if you still want to obscure the port because the server, or network
device, in question should only have occasional access by an extremely limited
group of people, then just throw on a white list and possibly restrict access
only through another server. Both provide more security than moving the port.

And moreover, this article isn't even about SSH. It's about the semantics
surrounding the usage of the term "security through obscurity" in the previous
article. Which is hilarious to me, as both articles are full of shit. For one,
the security implications of non-privileged ports is moot as the attacker
already has access. And two, being less likely of a target is still being a
target. Those five people who found the port in the test sample. Those are the
ones who win most likely to exploit; not the thousands of script kiddies brute
forcing you.

Your time would be much better spent obscuring the actual version information
for the service than the access point to it ...

(Reposted here, as the original site went down.)

------
mlopes
So, the guy's point is that if someone has access to your machine, then it's
ok to make life easier for them to run a fake sshd?

------
jonbaer
I still can't understand why things like port knocking or single packet auth
schemes like fwknop never really took off ...

------
spc476
I run SSH on port 22, but occasionally (when I travel) I will run it on port
443. Yes, know 443 is used by HTTPS, but:

1) I don't run HTTPS on the box I SSH into

2) I might hit an overly restrictive WiFi that only allows traffic out over
HTTP and HTTPS

Which is another reason why you might not want to run SSH on another port. You
might not be able to reach it.

------
jrockway
I run my ssh server on port 443 in addition to 22, because some network
connections block anything except 80 and 443, and this allows me to easily
proxy through that broken network connection.

(Actually, I appear to have stopped doing this. But it's something to consider
if you are on weird networks on a regular basis.)

------
dmourati
Amend the title to include (if you run only one SSH daemon and you're the only
one who needs to access it).

Then I agree.

Otherwise, hell no.

------
justinwr
I posted the original because I thought it was interesting. Elated to see an
honest response. I love HN.

------
bubblesorting
Better yet, put a firewall in front of sshd and only allow connections from
your management network ;)

------
hrjet
Is there a way to increase the privileged port range from 1024 in linux? If
it's set to a high enough number, say 1024*1024, that would solve both
problems (we could use a large port number for ssh and not allow non-root
users to hijack the port).

~~~
edgarvm
1024*1024=1048576 TCP port is a 16-bit value i.e. only values between 0 a
65535 are valid, it's not a wide range at all

------
blossoms
After pondering this article, I think the only reason to run SSH on a
different port is to prevent zero day ssh authentication bypasses, which I
don't think is a decent reason -- I'll eat my hat when this happens again.

------
mattln
I think he mentions port knocking precisely because he DOES understand point
#1 ( the difference between security through obscurity as a layer but not your
only layer), and is giving an example of using it as one such layer.

------
mixmastamyk
I don't change the port, but use keys and instead allow a tiny, tiny subset of
the the internet to talk to my servers on 22... my networks.

Very little hassle, no crap in the logs. Is there a drawback I'm missing?

------
GalacticDomin8r
So really the only problem you had with the argument is the security via
obscurity? Yeah, me too. Otherwise, his point were spot on and you didn't
address them directly.

------
scardine
A daemon that blocks the attacker address after a number of wrong attempts is
much more secure. IMHO moving SSH to another port is kind of Cargo Cult
Security.

------
antihero
I still don't see any reason to change the port. Use _only_ key auth. Problem
solved.

------
dontmakemelaugh
if you have sshd on 22 you get 1000 hack attempts per day. if you move it
somewhere else you probably get none the whole day.

the chance to get hacked is way higher. why would you not want to lower the
risk?

------
orenbarzilai
while I agree with most of the things in this article, he states the
obvious...

Don't understand how this article got to the main page and it's still here
after more than 11 hours.

------
aiiane
Thanks for writing up the same response I had to that article.

------
ewokhead
a: $port != 22 is enough to thwart most bots and skiddies. If you think the
port number is a guarantee that you are safe or that you are communicating
with a blessed ssh you are sadly mistaken.

b: Uhh the port number means nothing. Host keys are there for a reason...
Someone does not understand the functions of SSH.
[http://www.snailbook.com/](http://www.snailbook.com/) <\- great book

c: If you are not investigating fingerprint issues when logging in via SSH and
you call yourself a sysadmin, please stop. You are going to be the reason your
company ends up in the news because your shit got owned and 2,000,000 user
account hashes were leaked blah blah.

d: If you are not using key based auth and you have a fly by night keystore
policy. Which means you have a keystore - stop. The whole keystore for SSH
shit irritates me. I cannot tell you how many times I have heard sysadmins say
a that a single private key is a "best practice". It is not a best practice it
is a stupid practice and really prevents you from protecting unauthorized
logins on other machines for the obvious reasons.

    
    
       Put your public keys on bitbucket.com or source 
       management. Put your private keys on an encrypted disk
       in an encrypted archive if you must. This is still dumb
       imho because it is not needed.
    
       Leave one account (root) with console only/no ssh access
       that will allow for keys to be revoked/recreated when
       users need new keys.
    

e: The original article [http://www.adayinthelifeof.nl/2012/03/12/why-putting-
ssh-on-...](http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-
another-port-than-22-is-bad-idea/) Is wrong and misguided. port knocking or
knockd is an obscurity measure, precisely the kind he argues against. The
linked article from the OP calls this out.

f: Spinning up daemons is a big deal for non-priv users? So spinning up a
remotely accessible Lisp out of emacs from a screen that is running in the
background is bad? Hmm, here I thought that computers were meant to be tools
for humans to get work done... Sorry, background processes are part of getting
shit done. Users should be able to spin up the stuff they want to spin up in
the network segments they have access to without the bureaucracy of misguided
fools making the jobs of others more difficult because they think spinning up
a gunicorn process or a custom daemon is worse than their unpatched kernel,
apache tomcat and mysql listening on a publicly accessible address. Stateful
firewalls and hosts allow/deny are there for a reason.

Sorry for the snarky reply here but there are a lot of people chiming in that
obviously have very little knowledge about managing *nix ops and remote
access. I have pretty strong opinions about this kind of stuff. Especially the
single key stupidity and not checking host fingerprints.

~~~
probably_wrong
Sorry for deviating for the topic, but I think it must be said: "Sorry for the
snarky reply" is not enough, considering that you wrote it at the same time
you could have gone back and rewrite the text into a polite, well-worded
argument. That's just condescension - if you really were sorry, you'd have
rewritten your text.

By replying like that you've ensured that your point won't come across - for
all I know you might be technically right, but using that tone ensures that
lots of people will refuse to read past the second paragraph.

If your argument is solid, that's all you need. IMHO, snark makes your point
come across as bragging, and no one likes that.

~~~
ewokhead
"Sorry for the snarky reply" is not enough, considering that you wrote it at
the same time you could have gone back and rewrite the text into a polite,
well-worded argument. That's just condescension - if you really were sorry,
you'd have rewritten your text."

You are right. I am not sorry for the snarky reply.

"By replying like that you've ensured that your point won't come across - for
all I know you might be technically right, but using that tone ensures that
lots of people will refuse to read past the second paragraph."

Okay.

"If your argument is solid, that's all you need. IMHO, snark makes your point
come across as bragging, and no one likes that."

Okay.

------
_sabe_
This is a non issue. Set your iptables to start dropping packages after 3
failed login attempts.

