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

OpenSSH user enumeration

openwall.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: OpenSSH user enumeration

#51

Post by half-kh-hacker »

shpx wrote: post #43
thaumaturgy wrote: post #21

Earlier quoted context omitted.

A correct sshd_config includes: PasswordAuthentication no

You can also use https://tinyssh.org instead of the sshd from OpenSSH. It only implements key based authentication and newer encryption algorithms. It's available on Ubuntu: sudo apt install tinyssh wget https://github.com/yourusername.keys -O ~/.ssh/authorized_keys sudo systemctl enable tinysshd.socket but it's not widely used, which makes using it risky. To my knowledge there hasn't been a formal audit. Also it doe…

> Also it doesn't implement the scp protocol

From the FAQ[1]:

> TinySSH doesn’t have problem with scp protocol, only doesn’t have scp program.

I assume this means an OpenSSH `scp` command will work just fine when pointed at a tinyssh daemon, without the rsync alias.

[1]: https://tinyssh.org/faq.html

Re: OpenSSH user enumeration

#52

Post by pests »

jwilk wrote: post #41
Borealid wrote: post #40

Earlier quoted context omitted.

1. A "good" key safe for the forseeable future would have around 256 effective security bits. To get a key that strong, your password would have to be (speaking VERY generously here) 40 characters long and truly random. 2. When using real password authentication, connecting to a compromised server results in a disclosure of your password. When using challenge-response authentication, it does not. Note that correctly-…

> Incorrectly configured SSH will send passwords over the wire. What do you mean?

Real password based vs challenge response.

With real password when you type your password into the ssh password prompt it then sends that password to the server.

Challenge response is a method in which you usually encrypt or hash random server provided data. You send the hash. The server knows your password and can hash the data with it too. The hashes are compared not the password. In this method the password never leaves your machine. Replay attacks are prevented due to the server sending different data for you to hash on different login attempts.

Re: OpenSSH user enumeration

#53

Post by obituary_latte »

mercer wrote: post #47
mirimir wrote: post #7

Earlier quoted context omitted.

Does anyone still use password authentication on servers that actually matter? I mean, I'm just a hobbyist, and I switched to keys several years ago. Basically, I just use root and user, because anything else unnecessarily adds information.

I had a server that used password authentication for the root user (on the standard port). After a few months of uptime it was hacked. I suppose even minimal extra security would've helped (no root user, only allow x login attempts in y time, changing the port for ssh), but I was still surprised someone got in so soon by simply guessing a 20+ string of gibberish (I still wonder if maybe something else happened). All…

It was something else. Nothing or no one brute-forced a 20+ random string pass. More likely some service (Wordpress, phpbb etc) got owned. I’ve had multiple servers running for years with < 15 char non random root pass (stupid as it is to do so) with no problems.

Re: OpenSSH user enumeration

#54

Post by acdha »

jakobdabo wrote: post #39
mirimir wrote: post #7

Earlier quoted context omitted.

Does anyone still use password authentication on servers that actually matter? I mean, I'm just a hobbyist, and I switched to keys several years ago. Basically, I just use root and user, because anything else unnecessarily adds information.

Can somebody please explain to me why exactly using good passwords and allowing root login is bad security? Every SSH security tutorial mentions those but they never mention the reasons. If somebody hacked into my password manager and managed to steal the root user's password then they could do the same with my private key. Where is the difference? Also, if somebody hacked into a non-root administrative account, they…

Mistakes: if it’s a server used by a small number of security conscious admins, it’s moot. If it’s used by a lot of people, however, the odds go up dramatically that someone will have a weak password, one which is on a common list, or reused on a site which you’re just about to learn was breached.

Keys can be leaked but since it involves copying files and users aren’t penalized for using strong ones it’s much less common.

Re: OpenSSH user enumeration

#55

Post by e12e »

jakobdabo wrote: post #39
mirimir wrote: post #7

Earlier quoted context omitted.

Does anyone still use password authentication on servers that actually matter? I mean, I'm just a hobbyist, and I switched to keys several years ago. Basically, I just use root and user, because anything else unnecessarily adds information.

Can somebody please explain to me why exactly using good passwords and allowing root login is bad security? Every SSH security tutorial mentions those but they never mention the reasons. If somebody hacked into my password manager and managed to steal the root user's password then they could do the same with my private key. Where is the difference? Also, if somebody hacked into a non-root administrative account, they…

Just to add to @borealid's comment: a password that encodes 96+bits of entropy is effectively a shared symmetric key (OK, technically a secret).

Point being - it needs to be managed like a key: it's inconvenient to type, hard to remember, should be stored encrypted at rest, preferably in an hsm.

Gnupg agent/ssh agent and the various key agents for desktops all do this, and generally support hsm as well.

There's also a small difference in the complexity of enumerating the keyspace of rsa/ed2259 vs trying random passwords. With key stretching I'm not sure if there's implicit differences in rate of attempting login.

As for no direct root login via ssh - I think it depends a bit on the server. On a shared system login via regular user +sudo leaves an easier audit trail (who ran "sudo apt-get dist-upgrade" on Friday evening and took the weekend off without checking that production systems didn't crash... Was it "root" or "bob "?).

Then there's the nudge towards only doing what needs root as root (eg: curl/wget stuff as regular user, verify signatures, content - then run as root).

Is it more secure to locally dump and asymmetrically encrypt backups on disk as root - locally, and have a dedicated backup-user that gets the archives? Probably.

In general ssh keys (and certs more so) makes it feasible to split up access and authorization, revoke access etc without relying on something complex like ldap/kerberos for user management.

> Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate.

If they only have your ssh key, they'd typically need your password to elevate. Or you might require a shared root password - or set a password on wheel and require newgrp wheel before sudo. Not sure if the latter with disabled root account has much benefit, though.

Re: OpenSSH user enumeration

#56

Post by e12e »

pests wrote: post #52
jwilk wrote: post #41

Earlier quoted context omitted.

> Incorrectly configured SSH will send passwords over the wire. What do you mean?

Real password based vs challenge response. With real password when you type your password into the ssh password prompt it then sends that password to the server. Challenge response is a method in which you usually encrypt or hash random server provided data. You send the hash. The server knows your password and can hash the data with it too. The hashes are compared not the password. In this method the password never…

Note also that requiring a password for sudo might have some issues, as the password is sent over the ssh connection as you type. I'm not sure what the state of the art is wrt counting and guessing characters - or if mossh makes the problem worse - or helps. For the general idea, see:

http://www.securiteam.com/securitynews/5KP0O0A3PU.html

Does anyone know of recent work on passively attacking interactive ssh in order to guess what's being typed? I could see machine learning helping here, given the ability to observe enough sessions to form a training set...

Re: OpenSSH user enumeration

#57

Post by e12e »

exikyut wrote: post #20
oxymoron wrote: post #18

Earlier quoted context omitted.

I think he’s saying: a) Why are you using bleeding edge software in production, and especially so unreleased versions of OpenSSH? b) Why are your SSH servers exposed to public traffic? c) User enumeration is useful for finding accounts with weak passwords. Why do you have personal accounts on prod servers? Why do you have _any_ accounts not using public key authentication at all?

FWIW, regarding a), > We believe that this issue warrants a CVE; it affects all operating systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0, released in November 2000), and is easier to exploit than previous OpenSSH username enumerations... As for b) and c), I 100% agree. In fact: if you're using KVM-based virtualization, and you have VNC or serial access to your node (GCP gives you serial access, v…

Just remember (at least for non ephemeral systems): always have two ways in. That way if one path is down (fiber cable cut, serial disconnected, cloud admin panel down for maintenance, ssh authorized_keys file has wrong permissions, ssh/ssl cert(s) expired... ) - you can still get in via the other path.

Re: OpenSSH user enumeration

#58

Post by e12e »

jarfil wrote: post #2

Usernames are not a secret, passwords are a secret.

As others have noted - this allows user enumeration. Which can be very useful:

Does a system appear to run one of the many horribly insecure "enterprise" backup solutions? Or some other horrible, ancient system?

Does $person from orgchart appear to have a $user? (target for spear phising, compromise of laptop).

Information hinting at distribution (eg: Ubuntu).

Is there a jboss user? Etc.

Re: OpenSSH user enumeration

#59

Post by exikyut »

e12e wrote: post #57
exikyut wrote: post #20

Earlier quoted context omitted.

FWIW, regarding a), > We believe that this issue warrants a CVE; it affects all operating systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0, released in November 2000), and is easier to exploit than previous OpenSSH username enumerations... As for b) and c), I 100% agree. In fact: if you're using KVM-based virtualization, and you have VNC or serial access to your node (GCP gives you serial access, v…

Just remember (at least for non ephemeral systems): always have two ways in. That way if one path is down (fiber cable cut, serial disconnected, cloud admin panel down for maintenance, ssh authorized_keys file has wrong permissions, ssh/ssl cert(s) expired... ) - you can still get in via the other path.

A very good idea.

Perhaps a valuable resource would have a disposable proxy in front of it; then one way in (or even no ways in!) might be viable.

Post reply on HN