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

Consider the following command:

ssh aristotle sudo /bin/sh <

I want the redirection to apply to /bin/sh but it is consumed by sudo. Any ideas on how to achieve what I want?

share|improve this question
This is not really a question for stackoverflow. However, can you clarify? Your command works fine to me. –  anderstornvig Jul 8 '09 at 22:01

6 Answers 6

Why not just copy over and then invoke it?

scp aristotle:/tmp/test.$$.sh
ssh aristotle sudo /bin/sh /tmp/test.$$.sh
ssh aristotle rm /tmp/test.$$.sh

The $$ is the PID of the process on the local machine, giving some degree of randomness so your file doesn't get clobbered.

share|improve this answer

Redirection is working with ssh and sudo! It only interferes with any password dialog from ssh and/or sudo.

So EITHER you don't use redirection, but workarounds like e.g. copying the script to the target machine first and then executing it (as e.g. @edoloughlin suggested).

OR you configure ssh and sudo to not prompt for a password. Then it works like a charm:

$ echo "hostname" | ssh -A orwell sudo /bin/sh

There are thousands of howtos explaining how to use ssh passwordless, so i don't explain that part. And as for sudo, there are several ways to use it passwordless. @jtimberman suggested to allow the user in question passwordless sudo in general (via sudo's NOPASSWD feature, see sudoers(5)).

I personally use the PAM module pam-ssh-agent. It allows sudo to authenticate against a forwarded ssh agent and only falls back to password-based authentication if no ssh agent is available. On Debian & Ubuntu just

apt-get install pam-ssh-agent-auth

and then configure as documented in pam_ssh_agent_auth(8).

share|improve this answer

Try this way:

ssh aristotle sudo /bin/sh -c "/bin/sh \\<"
share|improve this answer
Thank you, I tried your suggestion but sudo still seems to be consuming the redirection when it prompts for the password. –  Jonathan Gossage Jul 8 '09 at 22:23
I have found that things work very differently when a shell is invoked from ssh than they do on a local command line and I am trying to determine what the (apparently) undocumented rules really are. –  Jonathan Gossage Jul 8 '09 at 22:29
UPDATE: sudo is not consuming the redirection. sudo will not prompt for a password w/o a terminal. –  joshudson Oct 2 '10 at 17:40
houdini@www ~ % sudo "echo foo >> ~houdini/foo.$$"
sudo: echo foo >> ~houdini/foo.30055: command not found
houdini@www ~ % ls ~houdini/foo*
zsh: no matches found: ~houdini/foo*
houdini@www ~ % sudo -s "echo foo >> ~houdini/foo.$$"
houdini@www ~ % ls ~houdini/foo*
-rw------- 1 root root 4 Jul  8 20:16 /home/houdini/foo.30055
houdini@www ~ % sudo -i "echo foo >> ~houdini/foo.$$"
houdini@www ~ % ls ~houdini/foo*
-rw------- 1 root root 8 Jul  8 20:17 /home/houdini/foo.30055
share|improve this answer

I used ssh somehost sudo cat \< /etc/passwd with some success; try something like:

ssh aristotle sudo /bin/sh \<

share|improve this answer

Likely, sudo is prompting for a password and its trying to get it from your script.

There's two solutions.

First, you can assign NOPASSWD for your userid on the target system.

 your_username ALL=(ALL) NOPASSWD: ALL

Or second, you can ssh to the system and provide a password to sudo, then run it again and

$ echo "your_password" | ssh remote_host sudo -l
your_username@remote_host's password:
[sudo] password for your_username: 
User your_username may run the following commands on this host:
    (ALL) ALL
$ ssh remote_host sudo /bin/bash <

Of course, you'll want to take precautions about your password appearing in your shell history (such as put it in a file only you have access to, then get the value from that file via cat or similar).

I strongly prefer the former, with SSH key-based authentication only, no passwords at all, and the private key residing on one system: my laptop (protected with a 16+ character passphrase).

Contents of my

hostname -f
share|improve this answer

Your Answer


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