3 ms·

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 tha

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

by simias 13y ago

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.