SSH Remote Execution - servidor de verificação pode fazer isso?

Question

Eu tenho um dispositivo embutido (Perle IOLAN +, um adaptador Ethernet para serial) que eu posso administrar via SSH. De tempos em tempos, preciso fazer login e executar um comando neste dispositivo. Fazer o login via SSH, obter um shell interativo e executar o comando é suave e funciona bem.

No entanto, eu queria automatizar o processo e ter um script no meu servidor para fazer login e executar esse comando para mim periodicamente. Eu estava testando para ver se eu poderia executar via SSH e parece que não posso.

O comando que eu quero executar, que funciona bem via shell interativo, é kill line * . No meu servidor, tento ssh user@device_host kill line * . Mas o resultado esperado não ocorre. quando tento ssh user@device_host uptime não recebo nenhuma saída, mesmo que uptime on no shell interativo do dispositivo funcione bem.

O dispositivo não está executando um sistema operacional normal e completo - é uma maneira de incorporar o * nix, com poucos comandos disponíveis. Eu queria saber se seu servidor SSH pode não reconhecer a execução do comando remoto. Existe alguma maneira de verificar? Os servidores SSH pareados geralmente não têm esse recurso?

Poderia haver outra maneira de executar um comando à distância sem passar por um shell interativo?

A saída de ssh com -vv é:

$ 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

    

Answer 1

Em ssh user@device_host kill line * o "*" é interpretado pelo seu shell local, antes de ser enviado para o servidor. Você tem que citar o comando assim:

ssh user@device_host 'kill line *'