SSH Check – public SSH server testing tool | Hacker News Reader

SSH Check – public SSH server testing tool

sshcheck.com

231 pointssajagi120 comments

I followed the Mozilla SSH guidelines[0] modern configuration, and turned out pretty good on this tool.

[0] https://wiki.mozilla.org/Security/Guidelines/OpenSSH

There are a couple of strange things here.

It lists oakley group 14 as insecure with no justification. That's a 2048 bit diffie hellman group and it should be totally fine.

It also lists hmac-sha1 as problematic, although in hmac the weaknesses of sha1 are irrelevant.

I'm not sure about the umac 64 bit block size. That should at least have some more info why it's considered problematic.

Usually OpenSSH is pretty good at deprecating problematic algorithm choices, so I tend to stick with upstream defaults.

It shows this as justification right now:

Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io).

Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not.

People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people?

https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe?

Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones).

You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct.

Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.

I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/. Both 422435 bytes.

Or you aren't understanding the key statement of his comment

> You'd have to find collisions that are of an identical length and still be useful

Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.

Git doesn't simply SHA-1 a file or the repo, it's more than that.

Linus:

> I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header.

[https://stackoverflow.com/questions/42433126/how-does-the-ne...]

> Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.

This is incorrect. Git attaches a header to the blob before hashing, that much is true, but the technique used by Shattered to create colliding hashes can be used to create colliding Git hashes as well — you simply need to take the header into account in advance of doing the collision. (Which is why the particular PDF files released by Shattered do not hash to the same value in Git, but that does not mean that the technique used does not apply: it does.) At the time of shattered's release, I commented on this[1]; that comment goes a bit more into the paper's findings.

> Or you aren't understanding the key statement of his comment

Frankly, I thought the key statement of his original comment, as applicable to SSH, was, why use SHA1 when SHA256 exists, and doesn't have these issues? Take the route that requires you to not need to be a cryptographer to figure out if it'll work or not.

[1]: https://news.ycombinator.com/item?id=13729985

> Or you aren't understanding the key statement of his comment

Sounds like it. People STOP referring to shattered.io, it is an entirely different issue.

Also, even if this was related... Can you really use shattered for MITM during key exchange which takes fraction of a second when that attack takes weeks of computation on a cluster of supercomputers??

Hi hannob, I'll re-check the classifications. Pretty sure you're right about the hmac-sha1 being still ok. Wrt oakley 14 and umac64 (and others) I'll try to add more detailed justifications. Thanks for your comment!

It's important to note that "HMAC-SHA-1" is an entirely different construction compared to SHA-1. It is a HMAC that happens to use SHA-1 internally, and it uses it in a way that means it does not yet share weaknesses with SHA-1 as a hash.

Of course, if you are writing something today, you should lean towards HMAC-SHA-256 or 512 as an extra buffer, but choosing to avoid HMAC-SHA-1 because it says "SHA-1" is not a valid reason.

The site also seems to flag RSA host keys. Using SHA1 in this case shouldn't be a security issue since the hash is calculated as SHA1(SHA2(x)) and you would need to break SHA2 as well. [1]

[1] - https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

It would be super-useful if it could give you something actionable for each issue if finds.

https://wiki.mozilla.org/Security/Guidelines/OpenSSH

While not exactly the solution you're looking for the Mozilla OpenSSH guidelines are quite better than the default sshd_config

That is useful, thanks!

Seems fairly good - I would consider going 25519-only if you have compatible clients for kex and auth.

Some of their concerns with SSH agent forwarding are good too - but make me wonder if writing some little GUI that would have you allow or deny authentication requests would solve the problem.

OK, I am not embarrassed to ask...

If I see some "weak" or "insecure" tags, what can I do about it? I have no idea how to disable MAC, key-exchange, and encryption algorithms used by the server I control. I had thought that just using SSH was "enough"

More importantly, if I do disable the insecure stuff, what will it break ?

This article is very detailed and includes examples of setting sshd to only use more secure options: https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

There was also a lot of HN discussion about it: https://news.ycombinator.com/item?id=8843994

> If I see some "weak" or "insecure" tags, what can I do about it? I have no idea how to disable MAC, key-exchange, and encryption algorithms used by the server I control. I had thought that just using SSH was "enough"

For the most part it is, many of the things they're labeling as "weak" is not stuff that's likely to get you exploited today, but stuff that might at some point in the future - attacks only get better. Not necessarily things that are completely broken, just weak by today's standards.

> More importantly, if I do disable the insecure stuff, what will it break ?

Older clients mostly. Many phone apps for example don't have recent SSH implementations that support newer cryptography.

Great tool - I found some weaknesses in my SSH server. After fixing them, I wanted to test it again but I can't find a refresh button...

EDIT: turns out you need to wait 10 minutes.

Yeah, same here :/

Ah, thanks, just saw your edit.

i am adding refresh button to my to-do list! :)

I actually decreased the cache expiry to 10 seconds instead, I believe that should be ok for everyone.

A suggestion: add simulated handshakes for various versions of OpenSSH and PuTTY to indicate which cipher/auth/kex algorithm they would negotiate with their default settings (ala the SSL Labs scanner).

If it included info on what to do with the WEAK ones, it would be much better. Sort of like the Google Pagespeed style.

https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

Is it just me or am I the only one who is a bit hesitant to submit the public IP/hostname to some random service on the web. I'm not trying to say that the creator of this has any ill intent, but I also don't know that they aren't cataloging addresses of potentially vulnerable ssh daemons.

Anyway.. just to reiterate I'm not trying accuse you of anything OP. Very cool utility, nice work!

If they wanted to find vulnerable ssh daemons it would be much faster and easier to scan the web than wait for people to enter their details here.

Or to put it another way: if you're worried that your SSH is vulnerable, fix it. Don't rely on not typing it into a website, because people will find it regardless.

> because people will find it regardless

In my experience, if you have an SSH port accessible from the internet, it has been probed today by a few Chinese/Russian IPs. Unless my raspberry pi home server is somehow a high value intelligence target...

In my experience a SSH service on a random, non-standard port gets surprisingly few probes. I look after several machines and I see less than one attempt per year (versus hundreds per day for port 22). I have yet to see somebody probe a SSH that listens on IPv6-only.

You might want to consider using port knocking[1] to make your ssh server even less susceptible to attack.

[1] - https://en.wikipedia.org/wiki/Port_knocking

No, the best solution is to only allow login by SSH keys. No passwords => brute-forcing is impossible. So your threat model for someone gaining access no longer includes someone using weak passwords.

If your ssh port is wide open and there's a remotely exploitable vulnerability, then using keys may not save you.

But there's no reason you couldn't use both keys and port knocking at the same time.

Unless you have a reason to target people here, of course...

No, you're not the only one.

I totally understand your concern.

However, here's my perspective:

- if the server is public already then black hats can simply probe your networks (IPv4 is not that big) and find the servers by themselves. The odds are that hackers are probably not interested in your company anyway.

- there are people who don't care about security of their servers (or rather are lazy / naive) and might find this service useful. Even if we were black hats it would at last alarm them that something is wrong. If they ignore the warnings - well - god help them.

EDIT: typos

That's not something you need to worry about - if you have a vulnerable ssh daemon with a public IPv4 address, then it's already been indexed and you submitting / not submitting it won't change anything.

Scanning all standard ports of all addresses of all IPv4 internet is computationally feasible and is done by many parties. For example, https://www.shodan.io/ is one place that has done so and allows public searching of e.g. all public IPs returning a particular SSH version or having particular key exchange algorithms enabled.

Not if it's running on a non-standard port though

Yes, non-standard ports transfer it to the domain of either somewhat targeted scan or serious effort - scanning all ports of all IPv4 requires many machines and/or many weeks, so that's not available to everyone. However, I'd still expect multiple organizations to keep an up-to-date scan of all public facing ports worldwide; it's impractical to do it for fun, but if have a need and some budget, it seems doable.

You're getting a lot of responses along the lines of: "Well if it's on the public internet it's already being indexed and scanned already, so there's no harm submitting a single IP address / hostname." Whoever thinks this is relevant: Please post your personal server's IP address here.

My phone number is 10 digits. It can easily be enumerated. I'm still not posting it in a public forum or submitting it to an unknown web site.

Sure thing. I have two boxes that run sshd exposed to the internet: 69.164.221.163 and 45.79.85.20. sshd runs on port 2020 now; I was running it on port 22 before but I got so many failed login attempts that it was actually causing noticable load on the system (something like average 10% CPU usage just for sshd).

I still get a couple hundred failed login attempts every day. Reasonably strong passwords and fail2ban mean that it's nbd.

Also, my phone number is on my website (it's 320 584 9293) and most of the spam calls I get are through whois, not the fact that there's a tel: URL out there pointing at it.

There's a significant difference - posting this information here is saying that x.y.z.w is my server, and that has a privacy concern, just as saying that my (or your) phone number is 1234567890.

Anonymously submitting that x.y.z.w is a server running ssh, on the other hand, doesn't provide anything beyond what's already publicly known.

Also, your phone number is not easily enumerated. Scanning even a small range of phone numbers (i.e. attempting a connection to see if they're valid) takes significant time and effort. Finding all open standard ssh ports on the whole internet, on the other hand, can be done in minutes with a good enough connection.

Do you get a few random phone calls every hour from someone you don't know?

Your ssh port is.

Why is this a service and not a standalone tool that I can use from my own machine?

Do I really want to be giving out the locations of my ssh servers to some random website?

Also, a standalone tool could be used behind corporate firewalls, where this service is useless.

Well, yes and no - I can see the argument that it might be nice to test them locally before you expose them to the world (and I suppose you might also have them on a private LAN permanently), but otherwise, they will be tested, by someone, and soon...

But the fewer people "test" it, apart from me, the better.

This is akin to putting your email address all over the internet. If you do that, you're going to get lots of spam. If you are more careful about who you give it to, you'll get less.

It's clearly a win to keep both email addresses and ssh server addresses as private as possible.

The difference between IP and email adresses is that one is trivially enumerated, the other is not.

Any internet-facing server that responds on port 22 will get several (up to hundreds) of failed login attempts per day. Just install something like fail2ban and watch your logs.

When was the last time you looked at your SSH logs for public machines? Your public IP is just that, public. Anyone can scan it, and it most certainly gets hit by many scanners a day.

Yeah I'd like a local tool. Maybe I want to do a test before I put it on the internet.

Not quite the same but there's always

  nmap --script ssh2-enum-algos.nse

Try this https://github.com/arthepsy/ssh-audit

I tried entering my personal server's hostname and port number but it timed out trying to connect. Then I remembered that I configured my server's firewall to only allows SSH connections from my home ISP or work IP address.

I too would prefer to use a standalone tool that I could use for testing my SSH configuration without having to temporarily disable those firewall rules.

Is this based on ssh-audit? https://github.com/arthepsy/ssh-audit

It is not, but thanks for sharing that link, looks very useful!

It appear to have problems with newer chiphers.

sshd[28670]: fatal: Unable to negotiate with 40.112.150.31 port 47286: no matching cipher found. Their offer: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,3des-cbc,twofish256-ctr,twofish192-ctr,twofish128-ctr,twofish256-cbc,twofish192-cbc,twofish128-cbc,twofish-cbc [preauth]

Hi andreaso, do you happen to have a list of encryption algs on your side? We don't support chacha20-poly1305 (yet) and afaik aes in gcm mode, but e.g. aes ctr are reliable so I find it strange these are not supported on your side.

That sshd only supports the chacha20-poly1305 cipher.

Perfectly fine with that, since I'm the only one logging into that server.

Great tool! Though I think it much safer to control these things client side, that way no matter what you're connecting to you know you're getting safe ciphers.

safer for you, not safer for the server.

On one hand, nice way to collect a database of SSH servers without triggering alarms.

On the other, people using this tool are more likely to take steps to secure their servers.

shodan.io already has a pretty good database of SSH servers. Want to find servers running an old version of OpenSSH? Easily queriable.

https://www.shodan.io/search?query=OpenSSH_5.2+country%3A%22...

There's a decent chance your SSH server is already in this database and many others.

Very good point!

Ok, say I am on vacations and my laptop turned brick. The SQL crashed and I need to perform a restore.

What do I do if only SSH keys are allowed? So I keep my key on a USB key? How is that safe to plug in into a computer?

Do I go around with a USB-Linux-distro with my key on it? What if in the border an official decides to keep the USB device I was holding on to.

How do you manage this situation?

You have other people on call to care for critical infrastructure.

I know many people keep an encrypted copy in various cloud or email accounts. Then all you would need is the encryption password and internet access to download the application to decrypt.

A USB smart card like a Yubikey NEO or 4 might be useful. Keys are securly stored in the card and never leave it. Alternatively, a USB smart card reader and a normal smart card, but this is physically larger.

Is there a similar tool that tests HTTPS enabled web servers on their choice of ciphers etc?

https://www.ssllabs.com/ is just that.

Or https://testssl.sh/ if you don't want to rely on a third-party.

https://observatory.mozilla.org/ is a great all-in-one tool that does SSL, headers, and a bunch of other stuff - calls out to ssllabs among others.

https://sslping.com even monitors your configuration every day for free

What a wonderful little site. Thanks for the link!

Thank you! (my site)... SSLPing didn't get as much attention on HN as SSHCheck does...

Well then let me thank you again :) Very slick UI, signed up in seconds, set myself up in under a minute.

What are your plans with it? Just leaving a free service running or do you want to add paid plans as well? (and if not, I would recommend setting up at least a "Support" plan of some kind; it sends a strong signal)

Thanks again :)

I have no set plan yet (the site is 1yr old)... SSLPing monitors almost 6000 servers daily, 250+ users... so maybe I'll follow your advice with some kind of support plan (I was thinking of donations)

> I was thinking of donations

Common piece of feedback I have seen in many donation-driven software projects:

Don't do donations. Do a support plan; even one as basic as "priority replies to emails". If a company wants to use your product, even if they want to pay, it's very hard to justify a donation whereas a support plan is far more readily bought.

I've actually been building a tool that does just this during the current YC Startup School program.

You can get on the launch list here: https://watchdog443.com

My main focus is ongoing alerting of changes to HTTPS configs rather than just a one off check. So you can be confident that everything is up to your spec or know as soon as something isn't.

Because we'll know your setup we can also alert you to things you specifically should be aware of - for instance a browser policy change that would affect user experience due to your certificates not meeting the browser policy etc.

Feel free to mail me if you'd like more info! (email in profile.)

(PS. YC Startup School's virtual demo day is tomorrow if you're interested! All the startups that completed the course are posting a short demo video.)

Just shows the following for me:

An error occurred This happenned when we were trying to connect to io.r1ch.net:22.

https://sshcheck.com/server/io.r1ch.net/

I'll take a look - it will take some time as I am currently swamped. Can you please check again in few days? Thanks!

Should this have "Show HN:" in the title? The author of the site appears to be the OP.

https://news.ycombinator.com/showhn.html

It'd be useful to know what this is likely to break, AFAIK I sshd doesn't log what ciphers people used, like Apache can do. A caniuse.com for SSH would be useful.

It can log that stuff -- increase "LogLevel" in sshd_config.

Is there any possibility to do check again, eg. after updating sshd config? After entering same data again i get previous result.

Out of curiosity I tried github.com and one of my servers. To my surprise it judges my server to be far more secure than github.

Ubuntu 16.04 launched from an AMI on AWS EC2 has weak points in its SSH setup out of the box—supporting SHA-1 and 64-bit UMAC.

It's quite probably because of compatibility with the older clients. Unfortunately you can't simply use only the safest algorithms out there because the clients wouldn't be able to connect :/

Kind of useless. I've checked, change settings and can't check again. I'm getting results from some cache.

you have to wait 10 minutes ... I am adding a refresh button as we speak.

No IPv6 support.

hi snvzz, which server did you try it on? i tried few ipv6 servers and it was ok.

Try any DNS name which only has a AAAA record, e.g. ipv6.google.com, which results in “An unexpected error occurred.”

Alright, thanks!

As secure explained.

As an added note, your server seems to resolve some A record, despite no A records in the domain. I suspect whatever you're using for DNS does park all NXDOMAIN into some website of their own.

After updating my SSH config, the tool won't let me re-check, it just gives me the previous results.

You have to wait 10 minutes, but he is adding a refresh button. https://news.ycombinator.com/item?id=14559709

Is there a good reason to open up access to your ssh port for some service by a novelty account which could easily collect information on what version ssl sub-protocols you do and do not support?

Consider me paranoid but I don't like services like this unless they come from reputable sources and even then I'd much rather run something local.

Remember to close your port in your firewall after running the test.

I think it's more the other way round. You already have a public SSH server for whatever reason (e.g. hosting, tunelling, ...) and you might use this tool to check its capabilities.

The reputability of such service or even existence thereof does not have anything to do with how much your server is or is not secured.

I'm not sure I get you, I find this service most useful for public-facing SSH services (where the risk of attack in the greatest). I wouldn't bother forwarding my laptop's port 22 just to test it, that's for sure.

If an attacker wants to gather a list of vulnerable SSH servers in the wild they just have to map a bunch of random addresses (and that seems to be extremely common judging by the number of failed auths on my public server). Although it could be useful if you wanted to get a list of ssh servers not running on port 22.

Yes, if it is public then I agree.

But if it is private you're going to have to unlock a port, let the service do its thing and then re-lock afterwards. If you forget the last step you are now more at risk than before.

Also, since the service does not advertise what IP it will be connecting from beforehand (presumably the host you complete that form on, but that's not a certainty, it's IP is 40.112.150.31, in an MS Azure block) you would open up access to the world in order to do this.

Even if the IP address was guaranteed static then I wouldn't dare recommending admins to add an exception to firewall. That would certainly be a very bad practice. There are tools available (mentioned in the comments around) that do the same job and can be run in the DMZ (the question is, would anyone go through the source code and verify the tool does not contain any malicious code?).

Excellent, so how about the opposite: tell people on the website not to make an exception for your service.

I am tempted to not interfere with the darwinian process ;) But seriously, we'll probably add some note like that.

hope someone makes a local-executable version...

There already is: https://github.com/evict/SSHScan

and returns almost the same details , there is also a nmap script https://nmap.org/nsedoc/scripts/ssh2-enum-algos.html I've always found these kind of webapps attractive in a way ... the fact that it may be doing a os.popen("nmap -vv bla bla bla") makes me uncomfortable ,

Another one https://github.com/arthepsy/ssh-audit

https://github.com/isgroup-srl/secure-ssh-server

Can you share what went into building this?

(disclaimer: I work for Rebex)

SSH libraries written by Rebex. With the exception of ECC it's all closed-source.

netcat -z -w 2 $ipaddress 22;echo $?

How hard is that?

Call me critical AND paranoid.. but this kind of thing should be a tool people can run locally. Not via some public service, which is probably gonna be blacklisted on plenty of RBLs.

However first and above all, SSH SHOULD NEVER LISTEN AND/OR RESPOND to non whitelisted ip addresses. NEVER, no exceptions.

Also i think it is more a promotion for the rebex site and software, not so much the ssh scan utility... based on the selected sample site, simplicity of the utility and site,

Server Identification: SSH-2.0-RebexSSH_1.0.0.0

There are many cases when you don't know the IP you will be connecting from. The only way around that I know of would be a VPN, but SSH's auth and crypto strength is at least as good.

As long as people keep doing this, i will have a job cleaning up fuck ups. :)

I think it suffice to disable root login, password authentication and maybe use a non-standard port to clear the logs from scanners. What do you do if your address changes or something? I wouldn't risk locking myself out.

Meh, I've got two hosts running SSH that are accessible from anywhere. They run OpenSSH on OpenBSD and are pretty locked down (only specific ciphers, key exchange algorithms, and MACs are permitted), root login is disabled, and password authentication is disabled, among other non-default configuration options. These two hosts allow access (via SSH) to another 40 or so boxes running various flavors and versions of Linux that can't be locked down as much.

I do not worry one bit about those two hosts getting compromised as I took the time to minimize the chances of that happening.

The fact you think that secures you, worries me, and that you share the almost exact setup you have with the world, just as much. Security is layers, and one layer is not telling the world about your setup.

Security is also not relying on obscurity to keep you safe.

having your server ssh exposed to the world and trusting your configuration is relying on obscurity. Having strict firewalls, with only a limited amount of trusted ip addresses is anything but relying on obscurity.

Reply on news.ycombinator.com