Output of ssh with -vv is:

$ ssh -vv user@remote_host uptime
OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remote_host [remote_host] port 22.
debug1: Connection established.
debug1: identity file /home/raven/.ssh/id_rsa type -1
debug1: identity file /home/raven/.ssh/id_rsa-cert type -1
debug1: identity file /home/raven/.ssh/id_dsa type -1
debug1: identity file /home/raven/.ssh/id_dsa-cert type -1
debug1: identity file /home/raven/.ssh/id_ecdsa type -1
debug1: identity file /home/raven/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
---- snipped - lots of kexinit messages ----
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 6c:4c:41:a3:d2:04:66:a1:e8:66:2d:35:4c:79:6a:98
debug1: Host 'remote_host' is known and matches the RSA host key.
debug1: Found key in /home/raven/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/raven/.ssh/id_rsa ((nil)),
debug2: key: /home/raven/.ssh/id_dsa ((nil)),
debug2: key: /home/raven/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/raven/.ssh/id_rsa
debug1: Trying private key: /home/raven/.ssh/id_dsa
debug1: Trying private key: /home/raven/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to remote_host ([remote_host]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: uptime
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2472, received 1816 bytes, in 0.8 seconds
Bytes per second: sent 3032.4, received 2227.7
debug1: Exit status 0

I have a embedded device (Perle IOLAN+, an Ethernet to serial adaptor) that I can administer via SSH. From time to time, I need to log in and execute a command on this device. Logging in via SSH, getting an interactive shell and running the command is all smooth and works well.

However, I wanted to automate the process, and have a script on my server log in and run this command for me periodically. I was testing to see if I could remote-execute via SSH and it seems I can't.

The command I want to run, which works fine via interactive shell, is "kill line *". On my server, I try "ssh user@device_host kill line *". But the expected result does not occur. when I try "ssh user@device_host uptime" I don't get any output, even though "uptime" on in the device's interactive shell works fine.

The device is not running a full, normal OS - it's some manner of embedded, striped-down *nix, with only very few commands available. I was wondering if its SSH server might not recognise remote command execution. Is there some way to check? Are pared-down SSH servers often lacking this feature?

Might there be another way to remote-execute a command without going in through an interactive shell?

I have a embedded device (Perle IOLAN+, an Ethernet to serial adaptor) that I can administer via SSH. From time to time, I need to log in and execute a command on this device. Logging in via SSH, getting an interactive shell and running the command is all smooth and works well.

However, I wanted to automate the process, and have a script on my server log in and run this command for me periodically. I was testing to see if I could remote-execute via SSH and it seems I can't.

The command I want to run, which works fine via interactive shell, is kill line *. On my server, I try ssh user@device_host kill line *. But the expected result does not occur. when I try ssh user@device_host uptime I don't get any output, even though uptime on in the device's interactive shell works fine.

The device is not running a full, normal OS - it's some manner of embedded, striped-down *nix, with only very few commands available. I was wondering if its SSH server might not recognise remote command execution. Is there some way to check? Are pared-down SSH servers often lacking this feature?

Might there be another way to remote-execute a command without going in through an interactive shell?