Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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/ > content.tar.gz
// shows the output of the STDERR here...

me@client:~$ tar ztf content.tar.gz

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/",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 is a wrapper for the main script, that basically calls the main script with a set of fixed params:

# wrapper for to use by the user auto with ssh-keys
/usr/local/bin/ foo bar
share|improve this question
up vote 2 down vote accepted

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/",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
share|improve this answer
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
Yup, indeed it does work, thank you very much :) – Carlos Campderrós Apr 18 '12 at 13:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.