Dear OpenSSH people,
It would be nice if SSH could forward the client's controlling
terminal to the remote process in addition to the client's stdin and
stdout. This way, if the user wants to run a process through sudo on
the remote machine while redirecting stdin and stdout locally (ssh B
sudo foo <in >out), sudo would be able to read a password from the
user. Ditto if the process is invoked through two steps of SSH (ssh B
ssh C foo <in >out). Similarly, rsync over SSH would work properly
with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See
this thread
on the rsync mailing list:
http://lists.samba.org/archive/rsync/2006-September/016284.html
Matt
Dear OpenSSH people,
It would be nice if SSH could forward the client's controlling
terminal to the remote process in addition to the client's stdin and
stdout. This way, if the user wants to run a process through sudo on
the remote machine while redirecting stdin and stdout locally (ssh B
sudo foo <in >out), sudo would be able to read a password from the
user. Ditto if the process is invoked through two steps of SSH (ssh B
ssh C foo <in >out). Similarly, rsync over SSH would work properly
with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See
this thread
on the rsync mailing list:
http://lists.samba.org/archive/rsync/2006-September/016284.html
Matt
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Matt McCutchen wrote:> Dear OpenSSH people, > > It would be nice if SSH could forward the client's controlling > terminal to the remote process in addition to the client's stdin and > stdout. This way, if the user wants to run a process through sudo on > the remote machine while redirecting stdin and stdout locally (ssh B > sudo foo <in >out), sudo would be able to read a password from the > user. Ditto if the process is invoked through two steps of SSH (ssh B > ssh C foo <in >out). Similarly, rsync over SSH would work properly > with --rsync-path="sudo rsync" or --rsh="ssh B ssh". See this thread > on the rsync mailing list:How would that be different from "ssh -t server" and "ssh -tt server" that have been in ssh(1) for a quite some time? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On 9/17/06, Darren Tucker <dtucker at zip.com.au> wrote:> How would that be different from "ssh -t server" and "ssh -tt server" > that have been in ssh(1) for a quite some time?I should see "foo" on my terminal when I run the following: ssh (options) localhost 'echo foo >/dev/tty' </dev/null >/dev/null But I get: $ ssh localhost 'echo foo >/dev/tty' </dev/null >/dev/null bash: /dev/tty: No such device or address $ ssh -t localhost 'echo foo >/dev/tty' </dev/null >/dev/null Pseudo-terminal will not be allocated because stdin is not a terminal. bash: /dev/tty: No such device or address $ ssh -tt localhost 'echo foo >/dev/tty' </dev/null >/dev/null tcgetattr: Inappropriate ioctl for device Connection to localhost closed. I'm using Fedora Core 5's openssh-4.3p2-4 . Matt _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev