On Wed, Apr 2, 2014 at 11:06 AM, Andy Kurth <[email protected]> wrote: > It looks like ssh on the management node is using a ConnectTimeout value of > 2 seconds: > debug3: timeout: 1999 ms remain after connect > > Does specifying a longer time make a difference? > ssh -o ConnectTimeout=10 -vvvv vm79 >
No, doesn't seem to change anything. Though I had set the connect timeout to 2 only recently because I was testing rebooting virtual machines and seeing if I could connect via ssh to them after a reboot, so it was set to whatever the default was before when it first started breakin. Below is a session with it set to 10. root@VCL-PROD:~] $ ssh -vvvv vm79 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /root/.ssh/config debug1: Applying options for vm* debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to vm79 [10.1.0.195] port 22. debug2: fd 3 setting O_NONBLOCK debug1: fd 3 clearing O_NONBLOCK debug1: Connection established. debug3: timeout: 10000 ms remain after connect debug1: permanently_set_uid: 0/0 debug3: Not a RSA1 key file /etc/vcl/vcl.key. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /etc/vcl/vcl.key type 1 debug1: identity file /etc/vcl/vcl.key-cert type -1 Connection timed out during banner exchange > > > On Wed, Apr 2, 2014 at 11:19 AM, Curtis <[email protected]> wrote: > >> Hi Andy, >> >> Thanks, inline... >> >> On Wed, Apr 2, 2014 at 8:22 AM, Andy Kurth <[email protected]> wrote: >> > I can't tell from just the commands. They look normal. Were there any >> > WARNING messages during the image process prior to the reboot? >> > >> > What error message is reported when you try to ssh from the management >> > node? (Connection timed out, etc) It may be helpful if you send the >> output >> > from running "ssh -v <win_computer>". >> > >> >> This is what that output looks like: >> >> [root@VCL-PROD:~] $ ssh -vvvv vm79 >> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 >> debug1: Reading configuration data /root/.ssh/config >> debug1: Applying options for vm* >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: Applying options for * >> debug2: ssh_connect: needpriv 0 >> debug1: Connecting to vm79 [10.1.0.195] port 22. >> debug2: fd 3 setting O_NONBLOCK >> debug1: fd 3 clearing O_NONBLOCK >> debug1: Connection established. >> debug3: timeout: 1999 ms remain after connect >> debug1: permanently_set_uid: 0/0 >> debug3: Not a RSA1 key file /etc/vcl/vcl.key. >> debug2: key_type_from_name: unknown key type '-----BEGIN' >> debug3: key_read: missing keytype >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug3: key_read: missing whitespace >> debug2: key_type_from_name: unknown key type '-----END' >> debug3: key_read: missing keytype >> debug1: identity file /etc/vcl/vcl.key type 1 >> debug1: identity file /etc/vcl/vcl.key-cert type -1 >> Connection timed out during banner exchange >> >> > To troubleshoot, you'll need to login as root using the password which >> was >> > redacted from the vcld.log output. Check the following: >> > >> > Is the Cygwin SSHD service running? If not, try to start it. If you get >> > an error related to incorrect credentials then something went wrong when >> > root's password was set early on in the image capture process. >> >> It's usually hung up, ie. won't respond to commands. >> >> If I login to the vm on its console (with virt-manager) then sshd >> can't be restarted from the windows service console, or cygrunsrv, but >> if I kill it with taskill and then start it, it starts up fine. >> >> Something to do with long logon times maybe? >> >> > >> > If SSHD is running, it could be a firewall problem. Try simply turning >> off >> > the firewall temporarily on the Windows computer and try to ssh from the >> > management node. >> >> The windows fw is not on, or at least it says it's not on. It's turned >> off in the image. >> >> > >> > If the firewall isn't the problem, something isn't configured correctly >> > with the sshd service. While logged in as root, you can try running >> > C:\cygwin\root\VCL\Scripts\update_cygwin.cmd. This gets run >> automatically >> > when an image is loaded and configures sshd correctly and starts the >> > service. If running this solves the problem, then you'll have to figure >> > out which commands or changes made by this script fixed it. If possibly, >> > it will be easier to troubleshoot if you take a snapshot of the computer >> > before running this script so that you can revert to the broken state in >> > order to narrow down the problem. >> > >> >> Ok will give the update_cygwin.cmd a shot. >> >> Thanks, >> Curtis. >> >> > -Andy >> > >> > >> > >> > >> > On Tue, Apr 1, 2014 at 6:28 PM, Curtis <[email protected]> wrote: >> > >> >> On Tue, Apr 1, 2014 at 4:16 PM, Curtis <[email protected]> wrote: >> >> > Hi All, >> >> > >> >> > We are having an issue with some of our images where when we try to >> >> > create a new image from an existing image, everything goes ok until >> >> > the part where the virtual machine is rebooted, and after it's >> >> > rebooted sshd does not start up and the imaging process fails. >> >> > >> >> > Anyone have any thoughts? I'm fairly sure it has something to do with >> >> > the various commands that are run on the image once an image creation >> >> > process starts. >> >> >> >> Also, this gist has all the commands that are being run: >> >> >> >> https://gist.github.com/curtisgithub/6117a73b47e994d9be03 >> >> >> >> But I'm not much of a windows administrator -- does anyone see >> >> anything unusual in that gist that might be causing issues? Perhaps >> >> something with the root logon or password? >> >> >> >> > >> >> > Thanks, >> >> > Curtis. >> >> > >> >> > -- >> >> > Twitter: @serverascode >> >> > Blog: serverascode.com >> >> >> >> >> >> >> >> -- >> >> Twitter: @serverascode >> >> Blog: serverascode.com >> >> >> >> >> >> -- >> Twitter: @serverascode >> Blog: serverascode.com >> -- Twitter: @serverascode Blog: serverascode.com
