Silly me. Just now I learned the `ProxyCommand` setting in ~/.ssh/config http://superuser.com/questions/107679/forward-ssh-traffic-through-a-middle-machine
Since I have got the ssh -A -t login1 ssh prod.server working, all I have to do is setup the ProxyCommand in ~/.ssh/config Host prod.server User jake ProxyCommand ssh -A login1 nc %h %p Then remove the :gateway setting in the config/deploy.rb . Everything is nice and dandy. On Tuesday, January 29, 2013 8:04:39 AM UTC+8, Jake Chen wrote: > > I do have this option set to true. I was using password authentication > before. > > I found out that one can setup > > ssh_options[:forward_agent] = true > > > to enable agent forwarding. I tried but with no luck. My ssh agent > configuration works, as explained in my previous post. > > Any suggestions on how to investigate this problem? > > On Monday, January 28, 2013 11:44:20 PM UTC+8, Rafa García wrote: >> >> Hi Jake, >> >> Maybe you can play with pty value. Example: >> >> default_run_options[:pty] = true >> >> Explanation from Capistrano's code: >> >> # * :pty - if true, a pseudo-tty will be allocated for each >> command. The >> # default is false. Note that there are benefits and drawbacks >> both ways. >> # Empirically, it appears that if a pty is allocated, the SSH >> server daemon >> # will _not_ read user shell start-up scripts (e.g. bashrc, >> etc.). However, >> # if a pty is _not_ allocated, some commands will refuse to run >> in >> # interactive mode and will not prompt for (e.g.) passwords. >> >> This topic(pseudo terminals<http://en.wikipedia.org/wiki/Pseudo_terminal>) >> always confuse me. >> >> Regards >> >> [1]http://en.wikipedia.org/wiki/Pseudo_terminal >> >> >> >> 2013/1/28 Jake Chen <[email protected]> >> >>> The login server of my company is rather paranoid I guess. I can' t use >>> that server as gateway for tunneling to production servers. >>> >>> # Term 1 >>> ssh -N 7845:prod.server:22 -L jake@login1 >>> >>> # Term 2 >>> ssh [email protected]:7845 >>> >>> >>> will fail. Term1 returns something like >>> >>> Channel 2: open failed: administratively prohibited: open failed >>> >>> >>> I googled a lot, found out this is the reason that failed capistrano. >>> Then I learned ssh-agent stuff, managed getting this to work: >>> >>> ssh jake@login1 ssh [email protected] >>> >>> >>> This command will give me a fake terminal. Saying something like: >>> >>> Pseudo-terminal will not be allocated because stdin is not a terminal. >>> >>> >>> executing `hostname` will return the correct answer. >>> >>> Is there anyway that I can let capistrano deploy my humble code this way? >>> >>> -- >>> -- >>> * You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> * To post to this group, send email to [email protected] >>> * To unsubscribe from this group, send email to >>> [email protected] For more options, visit this group at >>> http://groups.google.com/group/capistrano?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
