3

I've been working to have a script in a centralized server to do some things and output a .tar.gz file (see redirect temporarily STDOUT to another file descriptor, but still to screen). I also have exchanged ssh keys, so now from a client machine I can execute the script in my main server and output the result to a .tar.gz file in the client while seeing all the other output (STDERR) of the script:

me@client:~$ ssh auto@remoteserver /usr/local/bin/myscript.sh > content.tar.gz
// shows the output of the STDERR here...

me@client:~$ tar ztf content.tar.gz
content/file.txt
content/foobar.txt
...

But if I force the execution of this command putting the command option in the ~/.ssh/authorized_keys:

#/home/auto/.ssh/authorized_keys file
command="/usr/local/bin/myscript.sh",from="client" ssh-rsa 0UYmshd5FSDFf2fd...

and execute the following, it does not work:

me@client:~$ ssh auto@remoteserver > content.tar.gz
// shows **NOTHING**

me@client:~$ tar ztf content.tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

if I look into the file, it contains both the STDERR and the STDOUT. Any idea why it is getting mixed? And more importantly, any idea on how to avoid this?

ps: I should mention that myscript.sh is a wrapper for the main script, that basically calls the main script with a set of fixed params:

#!/bin/sh
# myscript.sh: wrapper for mainscript.sh to use by the user auto with ssh-keys
/usr/local/bin/mainscript.sh foo bar
Community
  • 1
Carlos Campderrós
  • 763
  • 2
  • 6
  • 17

1 Answers1

3

The first way you invoke the command doesn't create a pty, while the second may or may not. Try telling sshd not to create a pty. In your authorized_keys file:
command="/usr/local/bin/myscript.sh",from="client",no-pty ssh-rsa...

If you want to ssh from the command line when the no-pty option is set in your authorized_keys files you must redirect the STDIN to read from /dev/null or you would get an error saying PTY allocation request failed on channel 0:

$ ssh auto@remoteserver < /dev/null > content.tar.gz

If instead you do the ssh command without a controlling terminal, there's not STDIN available and you can omit the < /dev/null part. So in cron you might do the following without problem:

0 4 * * * ssh auto@remoteserver > content.tar.gz
Carlos Campderrós
  • 763
  • 2
  • 6
  • 17
NathanG
  • 1,326
  • 10
  • 14
  • No, that didn't work :(. It gave error `PTY allocation request failed on channel 0` – Carlos Campderrós Apr 18 '12 at 13:48
  • Hm wait yes, it does work. If I try to ssh directly from the command line it gives me the previous error, but if I redirect STDIN from /dev/null, it does not give the error and everything works ok. I suppose that running this from a cron script will also work without needing the redirection, as it will be called without a controlling pty. – Carlos Campderrós Apr 18 '12 at 13:53