I believe this is a limitation (or one of the limitations) of the SSH server in ArubaOS. I ran into a similar interop issue when I tried to use a library that relies on an SSH session with two channels (iirc that was with the Perl Net::SSH library).
Ansible probably just wants to execute a remote command, without requesting a full interactive SSH session. You can try something like this yourself:
user@host:~$ ssh manager@testswitch "show ver"
We'd like to keep you up to date about:
* Software feature updates
* New product announcements
* Special events
Please register your products now at: www.hpe.com/networking/register
manager@testswitch's password:
SSH command execution is not supported.
Connection to testswitch closed by remote host.
user@host:~$
and you'll see more of what's going on when you add the '-v' flag for verbose output:
user@host:~$ ssh -v manager@testswitch "show ver"
OpenSSH_5.9p1 Debian-5ubuntu1.9, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to testswitch [172.31.133.29] port 22.
debug1: Connection established.
debug1: Remote protocol version 2.0, remote software version Mocana SSH 5.8
debug1: no match: Mocana SSH 5.8
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 12:ff:bc:13:f6:1a:92:be:f3:b9:2f:c0:41:62:6a:59
debug1: Host 'testswitch' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:113
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
We'd like to keep you up to date about:
* Software feature updates
* New product announcements
* Special events
Please register your products now at: www.hpe.com/networking/register
debug1: Authentications that can continue: password
debug1: Next authentication method: password
manager@testswitch's password:
debug1: Authentication succeeded (password).
Authenticated to testswitch ([172.31.133.29]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: show ver
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
SSH command execution is not supported.
debug1: channel 0: free: client-session, nchannels 1
Connection to testswitch closed by remote host.
Transferred: sent 1960, received 1752 bytes, in 0.2 seconds
Bytes per second: sent 10312.5, received 9218.1
debug1: Exit status 0
Generally I wouldn't recommend using CLI interaction for automation tasks though, CLIs are designed for human interaction and not with automation in mind. In my experience, CLI based automation is more likely to break with software updates than eg SNMP based config changes. You could also consider using the (relatively new) REST API that's been added to ArubaOS, if the learning curve for SNMP is too steep.