4

I'm trying to automate some things on remote Linux machines with bash scripting on Linux machine and have a working command (the braces are a relict from cmd concatenations):

(ssh -i /path/to/private_key user@remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"')

But if an ampersand is concatenated to execute it in background, it seems to execute, but no output is printed, neither on stdout, nor on stderr, and even a redirection to a file (inside the braces) does not work...:

(ssh -i /path/to/private_key user@remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"') &

By the way, I'm running the ssh client dropbear v0.52 in BusyBox v1.17.4 on Linux 2.4.37.10 (TomatoUSB build on a WRT54G).

Is there a way to get the output either? What's the reason for this behaviour?

EDIT:

For convenience, here's the plain ssh help output (on my TomatoUSB):

Dropbear client v0.52
Usage: ssh [options] [user@]host[/port][,[user@]host/port],...] [command]
Options are:
-p <remoteport>
-l <username>
-t    Allocate a pty
-T    Don't allocate a pty
-N    Don't run a remote command
-f    Run in background after auth
-y    Always accept remote host key if unknown
-s    Request a subsystem (use for sftp)
-i <identityfile>   (multiple allowed)
-L <listenport:remotehost:remoteport> Local port forwarding
-g    Allow remote hosts to connect to forwarded ports
-R <listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 12288, larger may be faster, max 1MB)
-K <keepalive>  (0 is never, default 0)
-I <idle_timeout>  (0 is never, default 0)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection

Amendment after 1 day:

The braces do not hurt, with and without its the same result. I wanted to put the ssh authentication to background, so the -f option is not a solution. Interesting side note: if an unexpected option is specified (like -v), the error message WARNING: Ignoring unknown argument '-v' is displayed - even when put in background, so getting output from background processes generally works in my environment.

I tried on x86 Ubuntu regular ssh client: it works. I also tried dbclient on x86 Ubuntu: works, too. So this problem seems to be specific to the TomatoUSB build - or inside the "dropbear v0.52" was an unknown fix between the build in TomatoUSB and the one Ubuntu provides (difference in help output is just the double-sized default receive window buffer on Ubuntu)... how can a process know if it was put in background? Is there a solution to the problem?

tueftl
  • 218
  • 3
  • 7
  • Have you tried running it in verbose mode? (-v) – Justice Cassel Jun 20 '13 at 19:11
  • Right now, but then I just get `WARNING: Ignoring unknown argument '-v'` - even when executing in background, but still no other output. – tueftl Jun 20 '13 at 19:14
  • if you really are executing `( .... )` INCLUDING the '( )' chars, can you remove those? Those are interpreted as a call for a sub-shell (process). They may be "swallowing" your output. I used to do backgrounded ssh with output all the time. It should work. – shellter Jun 20 '13 at 19:20
  • See the examples listed [here](http://stackoverflow.com/questions/29142/getting-ssh-to-execute-a-command-in-the-background-on-target-machine). You may find the solution there. – Justice Cassel Jun 20 '13 at 19:20
  • Thanks for the quick comments - but it all does not solve yet. @JusticeCassel that question tells about putting the remote command in the background, but I want to put the `ssh` itself in the background like in Jon Ericsons answer there. Tomorrow I'll try if that works on x86 Ubuntu non-dropbear. @shellter I removed the braces, but sadly get no difference. – tueftl Jun 20 '13 at 19:34

1 Answers1

6

I had the similar problem on my OpenWRT router. Dropbear SSH client does not write anything to output if there is no stdin, e.g. when run by cron. I presume that & has the same effect on process stdin (no input).

I found some workaround on author's bugtracker. Try to redirect input from /dev/zero. Like:

ssh -i yourkey user@remotehost "echo 123" </dev/zero &

It worked for me as I tried to describe at my blog page.

Martin Plicka
  • 76
  • 1
  • 4
  • I had the same problem here with OpenWRT (KAMIKAZE, bleeding edge, r20828). Trying to catch output from ssh into variable in init.d script. I tried everything and then found this workaround! It works like a charm, many thanks! – lukyer Apr 10 '16 at 15:57