When adding a machine via SSH, both using the cert and login methods, I get this error on initial tentacle health check. No other details. From the octopus server, I’m able to connect via PuTTy to port 22 of the Linux host it’s trying to connect to.
I’d like to give more detail, but not of the log files or RAW information is giving any helpful data. This same tentacle was working previously on build 3.0.2 during our initial testing of the new version.
Task ID: ServerTasks-17
Task status: Failed
Task queued: Monday, July 27, 2015 1:33 PM
Task started: Monday, July 27, 2015 1:33 PM
Task duration: less than a second
| == Running: Check A01-xxx-xxxx-X health ==
13:33:19 Info | Starting health check for a limited set of deployment targets
13:33:19 Info | The following deployment targets will be checked:
13:33:19 Info | - A01-xxx-xxxx-X at ssh://A01-xxx-xxxx-X/
13:33:19 Trace | Health check complete, storing results.
13:33:19 Error | The health check failed. One or more deployment targets were not available.
|
| == Failed: Check deployment target: A01-xxx-xxxx-X ==
13:33:19 Info | Running health check on A01-xxx-xxxx-X
13:33:19 Info | Sending health check request to A01-xxx-xxxx-X at ssh://A01-xxx-xxxx-X/…
13:33:19 Verbose | Requesting upload…
13:33:19 Verbose | Establishing SSH connection…
13:33:19 Trace | Deployment Target health check failed.
13:33:19 Fatal | Could not connect to SSH endpoint
|
| Failed: Health results:
13:33:19 Info | - OFFLINE: A01-xxx-xxxx-X at ssh://A01-xxx-xxxx-X/
13:33:19 Fatal | One or more Agents were not online. Please see the output log for details.
Hi Anthony,
Looking at your logs it looks as though it couldn’t even connect to the endpoint before sending any health check command across the wire. Just after logging Establishing SSH connection... the connection is opened with the connection details that’s been provided and I would expect a SSH connection established to be the next line. During this first phase the server will attempt to create a temp directory in ~/.octopus as a workspace so make sure the provided account has full access to this path (although again I would still expect to see the connection confirmation before this step).
There have been no changes to the SSH connection process in the last few releases although there have been more checks added to the health check process. That being said it doesn’t look as though in your case its even getting as far as providing any of the commands.
Since its failing on connection I can only assume that there are some connectivity problems between your server and target. Has anything else changed on the SSH target machine recently? Perhaps with the ssh authentication configuration? Are you able to connect using PuTTY from the OD server itself?
Let me know how further connectivity tests go and if there are still problems I would be happy to take a look at your specific set up.
Thanks,
Rob
Still same results. I can RDP into the server and ping/telnet just fine to the linux host. I have a ticket in with my IT department. I’ll relay what I find that may point to our local environment.
Is there anywhere else there may be a log entry or a config setting to change the logging level temporarily to see if I can get additional information?
Anthony,
Just a thought, but are you sure the server is configured to accept password authentication?
Perhaps also check the ssh auth logs by calling tail /var/log/auth.log straight after an attempted connection from OD.
Those verbose task logs are about as much as we store on our side during this process. Assuming its using the right port/IP I might suggest checking what logs are on the other side of the connection.
Perhaps try with another fresh new target to confirm that it can work in your environment.
Let me know what you find on the ssh target logs and if we cant get any further with this, I would be happy to set up a time to try to remote into your environment and take a look myself.
Thanks again,
Rob
Here is the line being written in /var/log/secure. I am starting research into this now, but if you have something that may help, I’d appreciate it.
Jul 30 14:25:42 a01-rci-red01-x sshd[49682]: Connection closed by 10.201.8.32 [preauth]
That IP is the ip of the octopus server.
Please disregard. When setting up my initial identity, I followed a step that transferred the default .pub it to the authorized_keys. When this was done for the account we’re using, it started working. Looks like it was just an oversight. Nothing to see here!