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