Here's a modified version of Willie Wheeler's answer that transfers the file(s) via tar but also supports passing a password to sudo on the remote host.
(stty -echo; read passwd; stty echo; echo $passwd; tar -cz foo.*) \
| ssh remote_host "sudo -S bash -c \"tar -C /var/www/ -xz; echo\""
The little bit of extra magic here is the -S option to sudo. From the sudo man page:
-S, --stdin
Write the prompt to the standard error and read the password from the standard input instead of using the terminal device. The password must be followed by a newline character.
Now we actually want the output of tar to be piped into ssh and that redirects the stdin of ssh to the stdout of tar, removing any way to pass the password into sudo from the interactive terminal. (We could use sudo's ASKPASS feature on the remote end but that is another story.) We can get the password into sudo though by capturing it in advance and prepending it to the tar output by performing those operations in a subshell and piping the output of the subshell into ssh. This also has the added advantage of not leaving an environment variable containing our password dangling in our interactive shell.
You'll notice I didn't execute 'read' with the -p option to print a prompt. This is because the password prompt from sudo is conveniently passed back to the stderr of our interactive shell via ssh. You might wonder "how is sudo executing given it is running inside ssh to the right of our pipe?" When we execute multiple commands and pipe the output of one into another, the parent shell (the interactive shell in this case) executes each command in the sequence immediately after executing the previous. As each command behind a pipe is executed the parent shell attaches (redirects) the stdout of the left-hand side to the stdin of the right-hand side. Output then becomes input as it passes through processes. We can see this in action by executing the entire command and backgrounding the process group (Ctrl-z) before typing our password, and then viewing the process tree.
$ (stty -echo; read passwd; stty echo; echo $passwd; tar -cz foo.*) | ssh
remote_host "sudo -S bash -c \"tar -C /var/www/ -xz; echo\""
[sudo] password for bruce:
[1]+ Stopped ( stty -echo; read passwd; stty echo; echo
$passwd; tar -cz foo.* ) | ssh remote_host "sudo -S bash -c \"tar -C
/var/www/ -xz; echo\""
$ pstree -lap $$
bash,7168
├─bash,7969
├─pstree,7972 -lap 7168
└─ssh,7970 remote_host sudo -S bash -c "tar -C /var/www/ -xz; echo"`
Our interactive shell is PID 7168, our subshell is PID 7969 and our ssh process is PID 7970.
The only drawback is that read will accept input before sudo has time to send back it's prompt. On a fast connection and fast remote host you won't notice this but you might if either is slow. Any delay will not affect the ability to enter the prompt; it just might appear after you have started typing.
Note I simply added a host file entry for "remote_Host" to my local machine for the demo.
