`[exception] did not receive banner.` exception

Question

`[exception] did not receive banner.` exception

Opened this issue 7 years ago · 8 comments

For an sshd configuration, it is valid to have the Banner option in /etc/ssh/sshd_config set to none.

However, ssh-audit then always throws a [exception] did not receive banner..

It would be nice if ssh-audit could optionally skip checking for a banner.

Answer 1 · 2017-09-26T14:35:11.000Z

Banner in sshd_config is something different than exception regarding "banner". Even by default it is none. Exception is regarding identification string, e.g., SSH-2.0-OpenSSH_7.5.... I can agree that wording could be better.

@jpluimers, do You really get that exception? I would like to debug that case, because only way I can achieve it, is by faking sshd server and not sending identification string.

Answer 2 · 2017-09-27T15:03:45.000Z

I should have put the ssh-audit version and server target in the issue. Need to find out which machine this was meant for as I forgot. Might take a while, so please keep this open for now.

Answer 3 · 2017-09-28T07:41:55.000Z

OK, and also, please, let me know if You give up, so this issue shouldn't stay open forever.

Answer 4 · 2017-09-29T08:56:51.000Z

I got it one more time at a RaspberryPi connected via LAN from a MacBook connected via WiFi at my brothers place when he was using his microwave.

Plain ssh works fine, but ssh-audit fails every now and then. I think ssh is more resilient to a non-stable network than ssh-audit.

Answer 5 · 2017-09-29T11:46:03.000Z

That could be the case, as I have set-up very small timeout limits (3 seconds for connection, 5 seconds for reading data) to use it for bulk scans and receive answer fast when ssh server doesn't respond. This could be made configurable, but that would add new option, which should be remembered and used.

Does that sound something useful for You?

Answer 6 · 2017-09-29T17:22:11.000Z

It does. Though I understand your hesitation to add yet another set of options.

Answer 7 · 2017-10-01T22:34:29.000Z

Option could be added, just have to think about the naming and design, e.g., will that include two options (connection and read timeout) or a single one; how to specify them intuitively, etc. I was thinking something along the lines of -t 3:5. What do You think?

Answer 8 · 2017-10-05T08:48:01.000Z

Good idea.

Note that having one option with a list of parameters can be hard parsing and harder to remember the order of the parameters, so it might be easier to support this:

[--connection-timeout|-ct] <integer>
[--read-timeout|-rt] <integer>