Need help with ssh connection

I’m trying to use Ansible for remotely controlling outlets on a networked power distribution unit in a rack. I can manually ssh to it fine, but whenever I try to do it with Ansible, it can’t connect, and the -vvvv is not giving me anything useful. I tried using both the paramiko and ssh connections, neither worked, or provided any info.

[dmarold@drewtest ansible]$ ansible rack1_pdu -m raw -a ‘help’ -c paramiko -vvvv
[WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (i.e. yum update gmp).

<10.26.1.129> ESTABLISH CONNECTION FOR USER: apc on PORT 22 TO 10.26.1.129
rack1_pdu | FAILED => FAILED: No existing session
[dmarold@drewtest ansible]$ ansible rack1_pdu -m raw -a ‘help’ -vvvv
[WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (i.e. yum update gmp).

<10.26.1.129> ESTABLISH CONNECTION FOR USER: apc
<10.26.1.129> EXEC sshpass -d6 ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=“/users/dmarold/.ansible/cp/ansible-ssh-%h-%p-%r” -o StrictHostKeyChecking=no -o Port=22 -o GSSAPIAuthentication=no -o PubkeyAuthentication=no -o User=apc -o ConnectTimeout=10 10.26.1.129 help
rack1_pdu | FAILED => SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh
[dmarold@drewtest ansible]$ ssh apc@10.26.1.129
apc@10.26.1.129’s password:

American Power Conversion Network Management Card AOS v6.1.3
(c) Copyright 2013 All Rights Reserved RPDU 2g v6.0.9

Further data point: If I try to use the command module instead of raw, while it still fails, I do at least get the debugging output, and it looks like the initial connection succeeds, but then it fails when it tries to run a bunch of shell commands which obviously are not valid in AOS.

debug1: Next authentication method: password
debug3: packet_send2: adding 8 (len 51 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug3: Wrote 80 bytes for a total of 1485
debug1: Authentication succeeded (password).
debug1: setting up multiplex master socket

Can you just ‘ssh rack1_pdu’? Or do you have to ‘ssh user@rack1_pdu’ and supply a password?

You can add ‘-u username’ to your ansible command line. Does your PDU support SSH public keys? I’ve always used keypairs with ansible, so aren’t sure how you’d pass a password along.

If you look at the bottom of the first post I did ssh to it from the Linux command line. It doesn’t have a dns name, so I have a host_vars file defining the IP, and a group_vars file specifying username & password for all the APC gear. Just to be thorough I did just try with the -u but that didn’t help (nor does using -k and specifying a password). Unfortunately this doesn’t support ssh keys so that’s not an option.

On further investigation, this appears to be an issue with the ssh server built into the PDU rather than an Ansible issue. While I can ssh to it for an interactive session, if I try to just send a command like ‘ssh apc@10.26.1.129 olstatus 6’ it connects but the session closes before I get the response, and I think that’s what’s happening to the Ansible connection. If anyone has ever successfully used this with APC gear I’d love to hear about it.

The device might use a non-standard SSH daemon that only implements enough of the SSH protocol to allow remote interactive logins, but not enough to allow the types of non-interactive connections that Ansible is trying to make.

Try your test from the command line with and without the -T and -t flags (-T disables pseudo-tty allocation, while -t forces pseudo-tty allocation).

ssh -t apc@10.26.1.129 olstatus 6

ssh -T apc@10.26.1.129 olstatus 6

If the first one works, and the second one doesn’t, then you will need to add an entry into your ~/.ssh/config like this:

Host 10.26.1.129

RequireTTY

This will always ensure that the client requests a pseudo-tty, even when running non-interactively.

Unfortunately neither -t option made any difference. I’m going to just fall back & use Expect for these things. Thanks for the suggestions.