SSH Check – public SSH server testing tool • Hacker News Board

Re: SSH Check – public SSH server testing tool

#41

Post by jacquesm » Thu, Jun 15, 2017, 1:00 PM UTC

simias wrote: post #39

jacquesm wrote: post #33

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'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…

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.

Re: SSH Check – public SSH server testing tool

#42

Post by sajagi » Thu, Jun 15, 2017, 1:07 PM UTC

jacquesm wrote: post #41

simias wrote: post #39

Earlier quoted context omitted.

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…

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 A…

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?).

Re: SSH Check – public SSH server testing tool

#43

Post by MrRadar » Thu, Jun 15, 2017, 1:08 PM UTC

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

Re: SSH Check – public SSH server testing tool

#44

Post by el_duderino » Thu, Jun 15, 2017, 1:11 PM UTC

Aaargh20318 wrote: post #40

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

Re: SSH Check – public SSH server testing tool

#45

Post by jacquesm » Thu, Jun 15, 2017, 1:20 PM UTC

sajagi wrote: post #42

jacquesm wrote: post #41

Earlier quoted context omitted.

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 A…

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.

Re: SSH Check – public SSH server testing tool

#46

Post by sajagi » Thu, Jun 15, 2017, 1:28 PM UTC

dobin wrote: post #35

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

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

Re: SSH Check – public SSH server testing tool

#47

Post by sajagi » Thu, Jun 15, 2017, 1:30 PM UTC

jacquesm wrote: post #45

sajagi wrote: post #42

Earlier quoted context omitted.

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.

Re: SSH Check – public SSH server testing tool

#48

Post by CJefferson » Thu, Jun 15, 2017, 1:36 PM UTC

pawadu wrote: post #32

starquake wrote: post #23

Earlier quoted context omitted.

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

Re: SSH Check – public SSH server testing tool

#49

Post by sajagi » Thu, Jun 15, 2017, 1:40 PM UTC

andreaso wrote: post #12

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.

Re: SSH Check – public SSH server testing tool

#50

Post by scrollaway » Thu, Jun 15, 2017, 1:41 PM UTC

weddpros wrote: post #38

scrollaway wrote: post #25

Earlier quoted context omitted.

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)