search

mozilla / ssh_scan

DEPRECATED - A prototype SSH configuration and policy scanner (Blog: https://mozilla.github.io/ssh_scan/)
Mozilla Public License 2.0
793 stars 105 forks source link

fix #432: Fix the regression present in v0.33 #433

Closed jinankjain closed 6 years ago

jinankjain commented 6 years ago

ssh_keyscan is behaving weirdly when a port is passed to it as an argument. By weird what I mean is instead of sending to output stdout it is redirected to stderr. This is a temporary fix and it needs more investigation why is that the case.

@claudijd @jumanjiman

jumanjiman commented 6 years ago

I confirm that this fixes the regression as reported in #432

jinankjain commented 6 years ago

@jumanjiman Thanks for confirming

claudijd commented 6 years ago

@jumanjiman thanks for reporting and @jinankjain for fixing! I wasn't aware of https://github.com/jumanjihouse/docker-ssh-scan either, cool!

@jumanjiman any interest in combining forces with ssh_scan and docker-ssh-scan? We currently provide ssh_scan as a docker image, but maybe it's not exactly what you want. What's the feature gap that ssh_scan isn't providing right now? I'm really open to suggestions, ideas, opinions, etc.

jinankjain commented 6 years ago

@claudijd Are you aware about any reason why it was redirected to stderr instead of stdout?

claudijd commented 6 years ago

@jinankjain I have not had time to investigate further, but my assumption is that this is ssh-key behavior, I'm mostly focused on getting the work around out to fix the issue and I will revisit to address root cause. We may end up reporting upstream to them if that is truly the behavior.

claudijd commented 6 years ago

work-around deployed via gem here => https://github.com/mozilla/ssh_scan/releases/tag/0.0.34

claudijd commented 6 years ago

Docker hub is also updated here => https://hub.docker.com/r/mozilla/ssh_scan/

claudijd commented 6 years ago

I'm still not sold about whether this is an ssh-key issue as much as it's an issue with the provider in this case (digital ocean) seeing the behavior as malicious and blocking it and that combined with ssh-keyscan being a black box (ie. we call out to it as a dependency) we don't have a lot of visibility here.

claudijd commented 6 years ago

I started with a few tests like so...

$ ssh-keyscan -t rsa,dsa -p 49154 67.205.145.156 > output1.txt
# 67.205.145.156:49154 SSH-2.0-OpenSSH_7.6
# 67.205.145.156:49154 SSH-2.0-OpenSSH_7.6
$ ssh-keyscan -t rsa,dsa 67.205.145.156 > output2.txt
# 67.205.145.156:22 SSH-2.0-OpenSSH_7.6
# 67.205.145.156:22 SSH-2.0-OpenSSH_7.6
$ cat output1.txt 
$ cat output2.txt 
67.205.145.156 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDN+8qiCWCtry8KuY6MvWMhcPt58co/HhvZfiduZ+UnOnatf8lirP3A3d0wyjS1R/+7XfeYxwjs2OahHKAJyyK02FYSMFbAmW8pnkCzP94LoosRUy50bZh00W6WD6m/H7bwK1QzhAN8RKT8cPKtyROTtt2Um58WXsxrIWZ+FpnaDqACFasgX5cZAQkOHK3YWhDHEP7lJOex7FHia/vz5gMJxb9B8ZfOE04bvFEIlBswiE1hy/1mXU47uUwU/qmY+uxf5dwg9Gapil1lWH7DQaQ0CHbFOUA/UCis11LzxWds4NNvFztws+rFSkE2tLVS1HE2TCwv+ljgLUf9wXiiicWH

But, after a few attempts, I'm now getting way less useful responses, which tells me maybe we're dealing with an active IPS/IDS and these requests are timing out now...

$ ssh-keyscan -t rsa,dsa -p 22 67.205.145.156
$ ssh-keyscan -t rsa,dsa 67.205.145.156

So, in short, I believe this is somewhat outside the context of the scanner, but the server target behavior. If we can handle that behavior more nicely, like we do in the patch, that is great, but if it's going to timeout we're just going to need to expect that scenario and report it as such.