Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple SSH Security

disknotifier.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: Simple SSH Security

#71

Post by mastax »

aryhdrsfhzdf wrote: post #59
tadbit wrote: post #56

Earlier quoted context omitted.

> If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: > - you know the password This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.

What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships) NOPASSWD is poor hygiene.

GCP sets it in Debian, apparently.

Re: Simple SSH Security

#72

Post by upofadown »

shikoba wrote: post #44
zoomablemind wrote: post #35

Earlier quoted context omitted.

> ...For example I never use RSA keys. Exactly, the default RSA for the keygen is what a lot of users accept without realizing the implications. Well, lots of HowTos out there suggest "enter, enter, enter.." to get your key. What's the rationale for keeping RSA as a default these days?

What? RSA keys are insecure?

No they are not. It is just some sort of internet legend going around right now. If I had to play the odds I would consider RSA more secure than curves simply because RSA has been solid for much longer than the current curves have existed.

Re: Simple SSH Security

#73

Post by grosswait »

jsd1982 wrote: post #27

Just a quick note on this excerpt: > Disallowing root login is also frequently recommended. I believe this has limited merit in our current landscape since 95% of the time, the user you log in with has sudo privileges. Then it adds no extra security. But you should really judge this for your own situation. Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access, t…

If shared logins are in use attribution can be problematic.

Re: Simple SSH Security

#74

Post by rkeene2 »

noinsight wrote: post #58
rkeene2 wrote: post #48

Earlier quoted context omitted.

I typically frame this as accounts are for accountability. Reducing accountability isn't typically a goal for organizations so it's strictly better to have 20 accounts with sudo versus everyone using a single shared account (shared accountability) UNLESS the accountability is managed some other way (I think this something Gravitational Teleport tries to sell on this forum often).

You can use smart cards as plain SSH keypairs and sshd will of course log the fingerprint of the key used to authenticate. That's pretty foolproof accountability.

I in fact have done this (heavy user of smart cards and author of middleware), BUT what sshd logs (a fingerprint of the public key) requires a bit of work to match an authorized_keys format file (basically a stripped down PKCS#1 format with a header).

I actually use a fork of OpenSSH called PKIXSSH which supports X.509 certificates in sshd, and this is far more reliable.

Re: Simple SSH Security

#75

Post by grosswait »

upofadown wrote: post #25

These howtos involving cryptography should generally be ignored unless you actually understand the issues fairly well. The default configuration gets a lot of scrutiny. The stuff from "Big Bobs Super Secure" configuration howto mostly comes from the same sort of article. The ideas from these things take on a life and truth of their own after they circulate around a few times.

I disagree, you can always go straight to one of the industry recognized hardening benchmarks then. The ssh hardening guidance in the posted article and any number of hardening guidelines are all pretty similar.

The defaults keep the mailing lists from filling up with troubleshooting questions, but anyone with some command line skills can change one parameter at a time and test. If you’re exposing ssh to the internet you should absolutely not be ignoring hardening guides.

Re: Simple SSH Security

#76

Post by neandrake »

shikoba wrote: post #44
zoomablemind wrote: post #35

Earlier quoted context omitted.

> ...For example I never use RSA keys. Exactly, the default RSA for the keygen is what a lot of users accept without realizing the implications. Well, lots of HowTos out there suggest "enter, enter, enter.." to get your key. What's the rationale for keeping RSA as a default these days?

What? RSA keys are insecure?

I’m not an expert but I think RSA is discouraged these days because it’s strength is dependent on the key size which is regularly outdated as computers get faster/parallelize. Ten years ago a 512bit key was considered secure but these days I think 4096 is the recommended minimum length for a keypair that’s considered secure. Because of this it requires cycling through keys every now and again which can be tedious and even painful if you build PKI using it. The latter happened with a project I worked on where we’ve had to cycle our users keys for an application a few times now, I think jumping from 512 to 2048 and recently to 4096. This is even more tedious in a zero-knowledge system where the keys can only be unlocked with user authentication but deadlines for updating exist..

I’m not positive but I don’t think Elliptic Curves have the same issue, or key lengths have longer predicted life spans.

Re: Simple SSH Security

#77

Post by GekkePrutser »

zoomablemind wrote: post #35
haarts wrote: post #15

Earlier quoted context omitted.

I was long of that conviction too. But the default install optimizes for a different thing, compatibility. Or at least emphasizes is more than I would do. For example I never use RSA keys. So these can go. Less cyphers => less attack surface. But I do agree that I'm sure the defaults picked are sensible.

> ...For example I never use RSA keys. Exactly, the default RSA for the keygen is what a lot of users accept without realizing the implications. Well, lots of HowTos out there suggest "enter, enter, enter.." to get your key. What's the rationale for keeping RSA as a default these days?

For me: great smartcard support. Smartcards with EC are still rare. I think the latest yubikeys can do it with OpenPGP but it takes some fiddling and I also use physical cards.

And really, RSA-2048 is more than sufficient to keep all but the most funded hackers out. And if those target me, they'll get in anyway.

Re: Simple SSH Security

#78

Post by zinekeller »

upofadown wrote: post #72
shikoba wrote: post #44

Earlier quoted context omitted.

What? RSA keys are insecure?

No they are not. It is just some sort of internet legend going around right now. If I had to play the odds I would consider RSA more secure than curves simply because RSA has been solid for much longer than the current curves have existed.

There's a cherry on top there though: shorter RSA keys are easily breakable now, so most recommendation now focuses on extending from the defaults. It doesn't help that the practical default for SSH was 1024-bit until 2019-ish (OpenBSD folks: yes, OpenSSH did move to 2048-bit RSA way earlier, but OpenSSH builds on other OSes don't move that fast).

Re: Simple SSH Security

#80

Post by knorker »

egberts1 wrote: post #64
knorker wrote: post #54

Earlier quoted context omitted.

Doesn't help much when shodan has already portscanned everyone. I just searched for "ssh -port:22" and found many hits. But also yes. Switching port (or just blocking China) will vastly reduce SSH probes.

Don’t forget to block Brazil And Romania And Kazakhstan And …

I'm not saying there aren't non-China probe spam.

But without China it's just non-stop to the point of consuming noticeable amount of hard drive space for logs, and making it annoying to read logs looking for other things.

At least that's my experience.

Post reply on HN