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?

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
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
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

  • post output of ssh -vvv user@device_host uptime to have at least a bit idea what is going on behind the scenes and what is the other side running. Later on you can try to workaround it with ssh -tt user@device_host uptime (behave like interactive script), if it would help.
    – Jakuje
    Dec 12, 2015 at 18:55
  • Embedded devices often do not run openssh, often dropbear is used. Anyway, does it have a forced command in the daemon? Dec 12, 2015 at 19:15
  • @Jakuje: With -vvv, I indeed get a lot of output. Some info: remote system is OpenSSH5.9. I have added the -vv output to the question above - but I can't understand most of it.. -tt gave me an interactive shell on the remote machine as if I hadn't passed a command at all - no indication that the command executed, I'm afraid.. Dec 13, 2015 at 12:32
  • 1
    I think Rui was probably close to the correct answer. If it uses openssh and behaves this way, it looks like there is ForceCommand option used in sshd_config. Can you verify it? If you would be able to change it or remove it you are done. If not, you would probably have to code some expect script to interact with the shell (you can find many similar questions about this topic).
    – Jakuje
    Dec 13, 2015 at 17:05
  • I don't have file system access on the device, so I'm not able to edit sshd_config - a pity! Your idea to use expect sounds like the next best option - thanks! Dec 14, 2015 at 12:08

1 Answer 1


In ssh user@device_host kill line * the "*" is interpreted by your local shell, before it is sent to the server. You have to quote the command like this:

ssh user@device_host 'kill line *'

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .