5 ms·

Run it on a port where (port != 22 && port < 1024). Problem solved. Not every non-standard port is unprivileged. Lots of people run SSH on port 443 to get aroun

by kijin 13y ago

Run it on a port where (port != 22 && port < 1024). Problem solved. Not every non-standard port is unprivileged. Lots of people run SSH on port 443 to get around firewalls. I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.

dawkins 13y ago
I run ssh in a non standar port and its annoying to always specify the port. Thank you for the tip about ~/.ssh/config
simias 13y ago
I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port < 1024. While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use. Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).
- reidrac 13y ago
  You can verify the fingerprint, can't you? Not that I always do it (even is just the "first time", as you said), but IMHO the SSH model is definitely better than a central authority you have to pay to get your certificate signed.
- cagriemer 13y ago
  Have a look at SSHFP[1] DNS resource record. If you combine SSHFP record with DNSSEC, you can actually validate the fingerprint. [1] http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255
- deleted 13y ago
  [deleted]
- planckscnst 13y ago
  monkeysphere is how you deal with your SSH keys. It's pretty awesome. http://web.monkeysphere.info/getting-started-ssh/ http://web.monkeysphere.info/getting-started-ssh/ So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132 https://news.ycombinator.com/item?id=6617132
- bsdetector 13y ago
  They just need to scan once to find the port speaking SSH, then brute force as usual. If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.
  - monkeyspaw 13y ago
    OTOH, not running on port 22 prevents you from drive by scans. You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by. Having port 22 open can end my IPs on a list of "let's try to break later". It's not close to a complete solution, but I find it beneficial.
- beagle3 13y ago
  > Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means. SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models. ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.
- stormbrew 13y ago
  You actually can sign your host keys (and actually login keys) with relatively recent versions of openssh: http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates
  - simias 13y ago
    That's excellent! Thank you for pointing that out.
gopalv 13y ago
Ideally, you can run both https:// https:// and ssh:// on 443, with sslh. Everyone who's expecting to see HTTPS will see it on :443 as well.
beams_of_light 13y ago
I would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time. The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.
crest 13y ago
I can recommend gatling by passing firewalls on port 443. It waits 2 seconds for a HTTPS request before it starts OpenSSHd in inetd mode.
KedarMhaswade 13y ago
I think this is the easiest you can/should do that helps keep random checks and break-in attempts away.

by kijin 13y ago

dawkins 13y ago

I run ssh in a non standar port and its annoying to always specify the port. Thank you for the tip about ~/.ssh/config

simias 13y ago

I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port < 1024. While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use. Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).

reidrac 13y ago
You can verify the fingerprint, can't you? Not that I always do it (even is just the "first time", as you said), but IMHO the SSH model is definitely better than a central authority you have to pay to get your certificate signed.
cagriemer 13y ago
Have a look at SSHFP[1] DNS resource record. If you combine SSHFP record with DNSSEC, you can actually validate the fingerprint. [1] http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255
deleted 13y ago
[deleted]
planckscnst 13y ago
monkeysphere is how you deal with your SSH keys. It's pretty awesome. http://web.monkeysphere.info/getting-started-ssh/ http://web.monkeysphere.info/getting-started-ssh/ So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132 https://news.ycombinator.com/item?id=6617132
bsdetector 13y ago
They just need to scan once to find the port speaking SSH, then brute force as usual. If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.
- monkeyspaw 13y ago
  OTOH, not running on port 22 prevents you from drive by scans. You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by. Having port 22 open can end my IPs on a list of "let's try to break later". It's not close to a complete solution, but I find it beneficial.
beagle3 13y ago
> Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means. SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models. ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.
stormbrew 13y ago
You actually can sign your host keys (and actually login keys) with relatively recent versions of openssh: http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates
- simias 13y ago
  That's excellent! Thank you for pointing that out.

gopalv 13y ago

Ideally, you can run both https:// https:// and ssh:// on 443, with sslh. Everyone who's expecting to see HTTPS will see it on :443 as well.

beams_of_light 13y ago

I would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time. The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.

crest 13y ago

I can recommend gatling by passing firewalls on port 443. It waits 2 seconds for a HTTPS request before it starts OpenSSHd in inetd mode.

KedarMhaswade 13y ago

I think this is the easiest you can/should do that helps keep random checks and break-in attempts away.