Revisiting 8b3800894c283cf34b8598731592770e22ebd984

(04:25:26 PM) rtyler: kohsuke: so `blimpy ssh` is going to return immediately now?
(04:25:41 PM) kohsuke: yes, it fails if ssh fails
(04:26:09 PM) ***rtyler is a bit confused
(04:26:14 PM) rtyler: this seems like a big UX change then
(04:26:21 PM) ***rtyler should read more carefully
(04:27:13 PM) kohsuke: Yes, modifying a test case made me wonder if there's a better way to do it
(04:28:00 PM) kohsuke: (though in practice you wouldn't see any change as "blimpy provision" does wait for ssh to come online)
(04:28:13 PM) rtyler: but a `blimpy ssh` won't log me into the machine?
(04:28:51 PM) kohsuke: I think just reporting ">> Connecting: SHIPNAME..." if the first attempt fails would be sufficient
(04:29:25 PM) kohsuke: The "gotcha" that made me write that patch is that my first attempt to use blimpy failed miserably at "blimpy ssh"
(04:29:51 PM) kohsuke: because it was trying a wrong user name, and I couldn't Ctrl+C it because of another bug that since then I fixed
(04:30:11 PM) rtyler: with aws and openstack it connects multiple times, usually the machine isn't accepting ssh connections right away
(04:30:14 PM) rtyler: especially on a fresh image
(04:30:25 PM) kohsuke: yes, I understand why you wrote it the way you did the first place
(04:31:17 PM) rtyler: heh
(04:31:21 PM) rtyler: alright
(04:32:05 PM) kohsuke: Let me change it to ">> Connecting: user@SHIPNAME:port" with dots added over time,
(04:32:15 PM) kohsuke: and if it's killed by SIGINT I'll run ssh one last time but without -q
(04:32:22 PM) kohsuke: so you see the error message
(04:32:41 PM) kohsuke: does that sound OK to you?
(04:34:30 PM) rtyler: that does sound good

It turns out some mode of failure includes ssh hanging (such as trying a
wrong port), so silently re-running SSH again wasn't very wise. Instead,
show the command line needed to let the user run the ssh command by
himself.
Revert "Fixing the unit test failure"

This reverts commit 882730729638f7f613b05f9291c32e691b162dac.