Re: [go-nuts] input password to a ssh command

661 views
Skip to first unread message

Andrew Gerrand

unread,
Sep 11, 2012, 11:50:43 PM9/11/12
to zhub...@gmail.com, golan...@googlegroups.com
You should try to use key-based authentication if you can. This will
avoid the entire password mess.

Otherwise, investigate the SSH_ASKPASS environment variable. It
specifies a program that should be used to collect a
password/passphrase from the user when there's no controlling terminal
available (as I presume is the case here).

Note that the intended use of SSH_ASKPASS is to launch an X11-based
application, so it also expects the DISPLAY environment variable to be
set. You can just set a dummy DISPLAY in this case.

From "man ssh":

SSH_ASKPASS If ssh needs a passphrase, it will read the
passphrase from the current terminal if it was run
from a terminal. If ssh does not have a terminal
associated with it but DISPLAY and SSH_ASKPASS are
set, it will execute the program specified by
SSH_ASKPASS and open an X11 window to read the
passphrase. This is particularly useful when call-
ing ssh from a .xsession or related script. (Note
that on some machines it may be necessary to redi-
rect the input from /dev/null to make this work.)

Andrew

Kyle Lemons

unread,
Sep 12, 2012, 1:09:14 AM9/12/12
to zhub...@gmail.com, golan...@googlegroups.com
I can't tell precisely what context your code fits in, so some general comments: when debugging things with SSH, it is often quite enlightening to crank up the verbosity.  It can get pretty chatty, but it's generally pretty straightforward to understand.

As Andrew points out, SSH could be trying to still ask a human for the password (this is typically called "keyboard-interactive" authentication, as opposed to simply "password"). SSH (well, OpenSSL) works very hard in order to determine the controlling terminal so that it can ask the real user sitting at the keyboard to enter their password.  There are ways of providing input, but they involve workarounds like the above-mentioned SSH_ASKPASS or (if I recall) things like allocating a PTY for the SSH process to act as its terminal.  Generating an SSH keypair and using authorized_keys is a common way to allow scripts and other more-automated processes access to passwordless login, and combined with an SSH agent can pose minimal extra security exposure (with a keypair that has a passphrase; this also requires passing through a few variables from the environment to the SSH process).  I believe there is a program called sshpass that uses some of these workarounds if you have a way to bundle that with your app and using keys is, for whatever reason, not practicable. 

On Tue, Sep 11, 2012 at 8:23 PM, <zhub...@gmail.com> wrote:
Enter code here...
Hi all, 

I am tring to use the package code.google.com/p/go.crypto/ssh to issue a command 
on remote machine, the command is scp, and it need a pasword to input.
then i create a new reader 
pw := strings.NewReader("xxxxxxxxx\r") 
and assign it to the session 
session, err := this.conn.NewSession()
defer session.Close()
if err != nil{
return err
}
session.Stdout = w
session.Stderr = w
session.Stdin  = pw

if err := session.Start(cmd); err != nil {
log.Println(err)
return err
}

if err := session.Wait(); err != nil {
log.Println(err)
return err
}

But seems it does not take effect, the sctp always prompt me "permission denied",
but the password is obviously right.
I also tried
pw := strings.NewReader("xxxxxxxxx\n") 
pw := strings.NewReader("xxxxxxxxx") 

all these not worked.

Is there something wrong with my code?

Thanks!



--
 
 

agl

unread,
Sep 12, 2012, 3:34:40 PM9/12/12
to golan...@googlegroups.com, zhub...@gmail.com
I believe that the example for Dial should be helpful to you:


Cheers

AGL

Salman Aljammaz

unread,
Sep 13, 2012, 9:51:29 AM9/13/12
to Kyle Lemons, zhub...@gmail.com, golan...@googlegroups.com
If I understand correctly, this is what you want to have, where A is
the local machine and B & C are remote ones:

A –crypto.ssh→ B –scp→ C

In addition to what was already suggested, and depending on how much
bother you're willing to go through, you might want to consider
tunneling ssh-agent traffic through an ssh.Channel. I.e. like to how
OpenSSH implements agent forwarding. Then set up an ssh-agent on A
which has the private keys to C. Scp will query the agent on A to get
to C.
Reply all
Reply to author
Forward
0 new messages