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 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
ssh -vvv user@device_host uptimeto 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 withssh -tt user@device_host uptime(behave like interactive script), if it would help.opensshand behaves this way, it looks like there isForceCommandoption used insshd_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 someexpectscript to interact with the shell (you can find many similar questions about this topic).