SSH Check – public SSH server testing tool(sshcheck.com) |
SSH Check – public SSH server testing tool(sshcheck.com) |
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.
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.
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.
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.
SSH libraries written by Rebex. With the exception of ECC it's all closed-source.
How hard is that?
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
I do not worry one bit about those two hosts getting compromised as I took the time to minimize the chances of that happening.
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.
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.
[1] - https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io).
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?
While not exactly the solution you're looking for the Mozilla OpenSSH guidelines are quite better than the default sshd_config
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.
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 ?
There was also a lot of HN discussion about it: https://news.ycombinator.com/item?id=8843994
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.
EDIT: turns out you need to wait 10 minutes.
Anyway.. just to reiterate I'm not trying accuse you of anything OP. Very cool utility, nice work!
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.
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.
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.
nmap --script ssh2-enum-algos.nsesshd[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]
Perfectly fine with that, since I'm the only one logging into that server.
On the other, people using this tool are more likely to take steps to secure their servers.
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.
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 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.)
An error occurred This happenned when we were trying to connect to io.r1ch.net:22.
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.
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.
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...
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
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.
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.
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.
Your ssh port is.
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.
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)
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)
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).
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.
But there's no reason you couldn't use both keys and port knocking at the same time.
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.
> 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...]
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.
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??