SSH support for -address

[ghost]

Hi,

This is a cool project. Would be nice to see it support SSH banners, for an ssh:// -address mode.

Also wonder if -proto could be added for using -host.

Thanks!

[maxcnunes]

Good ideas. I will try to work on it once I get some free time (may take a while though). PRs are welcome if anyone wants to get it solved earlier.

[maxcnunes]

Hey v2.4.0 supports ssh protocol through -address or -proto

[ghost]

Very cool, thank you!

Unfortunately, does not seem to work.

$ waitforit -host 8.8.8.8 -port 22 -proto ssh; echo $?
0
$ waitforit -host 8.8.8.8 -port 25 -proto ssh; echo $?
0
$ waitforit -host 2001:41d0:8:6a52:298:2dff:fef3:8ce1 -port 22 -proto ssh; echo $?
0

[maxcnunes]

Weird, it is working for me:

waitforit -host 8.8.8.8 -port 22 -proto ssh -debug -timeout 2 ; echo "--->$?"
2018/09/04 15:54:23 Waiting 2 seconds
2018/09/04 15:54:23 Ping host: 8.8.8.8:22
2018/09/04 15:54:24 Ping host: 8.8.8.8:22
2018/09/04 15:54:24 Down: 8.8.8.8:22
2018/09/04 15:54:24 dial tcp 8.8.8.8:22: i/o timeout
2018/09/04 15:54:25 Ping host: 8.8.8.8:22
2018/09/04 15:54:25 Down: 8.8.8.8:22
2018/09/04 15:54:25 dial tcp 8.8.8.8:22: i/o timeout
2018/09/04 15:54:25 dial tcp 8.8.8.8:22: i/o timeout
--->1

[ghost]

I have some pretty unusual network configurations going on locally. That said, I don't think it's waiting for SSH headers.

$ waitforit -host 8.8.8.8 -port 22 -proto ssh -debug -timeout 2 
2018/09/04 21:15:30 Waiting 2 seconds
2018/09/04 21:15:30 Ping host: 8.8.8.8:22
2018/09/04 21:15:30 Ping host: 8.8.8.8:22
2018/09/04 21:15:30 Up: 8.8.8.8:22

Can you test that with google.com port 80, and proto SSH?

[maxcnunes]

Test ssh://8.8.8.8:80

$ waitforit -host 8.8.8.8 -port 80 -proto ssh -debug -timeout 2
2018/09/05 11:24:48 Waiting 2 seconds
2018/09/05 11:24:48 Ping host: 8.8.8.8:80
2018/09/05 11:24:49 Ping host: 8.8.8.8:80
2018/09/05 11:24:49 Down: 8.8.8.8:80
2018/09/05 11:24:49 dial tcp 8.8.8.8:80: i/o timeout
2018/09/05 11:24:50 Ping host: 8.8.8.8:80
2018/09/05 11:24:50 Down: 8.8.8.8:80
2018/09/05 11:24:50 dial tcp 8.8.8.8:80: i/o timeout
2018/09/05 11:24:50 dial tcp 8.8.8.8:80: i/o timeout

Makes sense to fail because google don't have a ssh available on that ip and port

Test ssh://8.8.8.8:22

./waitforit -host 8.8.8.8 -port 22 -proto ssh -debug -timeout 2
2018/09/05 11:26:06 Waiting 2 seconds
2018/09/05 11:26:06 Ping host: 8.8.8.8:22
2018/09/05 11:26:07 Ping host: 8.8.8.8:22
2018/09/05 11:26:07 Down: 8.8.8.8:22
2018/09/05 11:26:07 dial tcp 8.8.8.8:22: i/o timeout
2018/09/05 11:26:09 Ping host: 8.8.8.8:22
2018/09/05 11:26:09 Down: 8.8.8.8:22
2018/09/05 11:26:09 dial tcp 8.8.8.8:22: i/o timeout
2018/09/05 11:26:09 dial tcp 8.8.8.8:22: i/o timeout

Makes sense to fail because google don't have a ssh available on that ip and port

[ghost]

I mean google.com (108.177.122.101 or similar), not 8.8.8.8 which is just their DNS resolver service.

[maxcnunes]

gotcha, I noticed the problem now. I will fix it ~later today~ once I have some free time for this, thanks!

[maxcnunes]

hey @teran-mckinney, currently the -proto argument is only used by http/https connections. Because it does an HTTP(s) request to that address. So, even if you set -proto=ssh waitforit will only check if that address (host+port) is accessible. But, it won't do any other further checking as creating an ssh session. We could implement it, but I'm afraid it maybe could over complicate this tool. Because to achieve that waitforit would need a few other arguments such as ssh user, ssh password, ssh private key, and etc. Due to that, I'm closing this issue. Thanks.

[ghost]

Gotcha, I understand. In this case, I imagine listening just for an SSH banner would be plenty, or attempting to authenticate. I have similar checks where a failed authentication is what I consider a valid response, trying to login with an invalid user. This way you know the daemon is defnitely running at least to some extent.

Of course may not make sense to add in anyways, but wanted to explain my methodology.