Question on SSH_ASKPASS
Jan Alphenaar
I have asked a question a long time ago regarding SSH_ASKPASS, but with the
latest version of OpenSSH I am not able to get the desired result.
My goal is to launch a script on a remote server via SSH without having to
type a password, because it is locally executed from a script. This should
not be too complicated, but somehow I am not able to figure this out myself.
I have configured the variables SSH_ASKPASS=<password_script> and
DISPLAY=nodisplay. My password_script just contains echo "password", nothing
else.
Now if I execute this ssh command:
ssh -T jan@<dest_host> "/<script_dir>/<script>"
It still asks me for a password. This command though
setsid ssh -T jan@<dest_host> "/<script_dir>/<script>"
does work as expected, it launches the remote script.
I know ssh should support this out of the box, so I want to get rid of
setsid.
Any help or directions are appreciated.
Warm regards,
Jan
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Peter Lambrechtsen
<jan.al...@dotcolour.com> wrote:
> Hi everybody,
>
> I have asked a question a long time ago regarding SSH_ASKPASS, but
> with the
> latest version of OpenSSH I am not able to get the desired result.
>
> My goal is to launch a script on a remote server via SSH without
> having to
> type a password, because it is locally executed from a script. This
> should
> not be too complicated, but somehow I am not able to figure this out
> myself.
Why aren't you using authorized_keys with a public/private keys.
That's what it's there for. Among other reasons.
Jim Knoble
: setsid ssh -T jan@<dest_host> "/<DEFANGED_script_dir>/<DEFANGED_script>"
:
: does work as expected, it launches the remote script.
:
: I know ssh should support this out of the box, so I want to get rid of
: setsid.
Hi, Jan.
You are correct in that using 'setsid' works as expected. The reason
is here, to quote the ssh(1) man page:
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 calling ssh from a .xsession or related script. (Note that
on some machines it may be necessary to redirect the input from
/dev/null to make this work.)
The problem is that, on many (most?) systems, to disassociate ssh from
its controlling terminal, you need to put it into a new "session".
Redirecting stdin from /dev/null ('ssh ... </dev/null') is not enough.
The setsid command you are using is pretty much the only way to do that;
it's pretty much a wrapper around the setsid(2) system call, which then
execs the command given on the command line (probably via execvp(3)).
This is a feature of POSIX (see
http://www.opengroup.org/onlinepubs/009695399/functions/setsid.html ).
Hope this helps.
--jim
--
jim knoble | jmkn...@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
Roumen Petrov
> Hi everybody,
>
> I have asked a question a long time ago regarding SSH_ASKPASS, but with the
> latest version of OpenSSH I am not able to get the desired result.
>
> My goal is to launch a script on a remote server via SSH without having to
> type a password, because it is locally executed from a script. This should
> not be too complicated, but somehow I am not able to figure this out myself.
>
>
> DISPLAY=nodisplay. My password_script just contains echo "password", nothing
> else.
>
> Now if I execute this ssh command:
>
> ssh -T jan@<dest_host> "/<script_dir>/<script>"
>
> It still asks me for a password. This command though
>
>
> does work as expected, it launches the remote script.
>
> I know ssh should support this out of the box, so I want to get rid of
> setsid.
>
>
> Warm regards,
>
> Jan
Look like old request "(generalised-askpass) Generalize SSH_ASKPASS"
https://bugzilla.mindrot.org/show_bug.cgi?id=69
Roumen
--
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/
Gert Doering
On Thu, Dec 24, 2009 at 12:36:37PM +1300, Peter Lambrechtsen wrote:
> Why aren't you using authorized_keys with a public/private keys.
> That's what it's there for. Among other reasons.
Unfortunately, some vendors fail to understand this. Like "Cisco". Or
"Citrix" (who *can* do pubkey auth, but there is no persistant storage
on the netscalers, so it will only work up to the next reboot).
For the time being, us poor admins have to fall back to nastier
approaches... like "put passwords into files".
(Not that "put password into script" is *that* much more insecure than
"have password-less key on file". If your files can be read by $evil_entity,
you're toast, in both cases...)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@greenie.muc.de
fax: +49-89-35655025 ge...@net.informatik.tu-muenchen.de
Carson Gaspar
> Hi,
>
> On Thu, Dec 24, 2009 at 12:36:37PM +1300, Peter Lambrechtsen wrote:
>> Why aren't you using authorized_keys with a public/private keys.
>> That's what it's there for. Among other reasons.
>
> Unfortunately, some vendors fail to understand this. Like "Cisco". Or
> "Citrix" (who *can* do pubkey auth, but there is no persistant storage
> on the netscalers, so it will only work up to the next reboot).
>
> For the time being, us poor admins have to fall back to nastier
> approaches... like "put passwords into files".
A better approach would be to use Kerberos. Most enterprise vendors like
the ones you mention support GSSAPI auth. Of course some don't :-(
> (Not that "put password into script" is *that* much more insecure than
> "have password-less key on file". If your files can be read by $evil_entity,
> you're toast, in both cases...)
The difference is slightly technical and mostly human behaviour. If an
attacker gets a cleartext password, it is _highly_ likely that password
will work across multiple system domains. If an attacker gets a
cleartext private ssh key, it is likely that will work across a smaller
domain of systems. The RSA/DSA key is also more secure against brute
force attacks. If you have very good password discipline the differences
are relatively small, but I've _rarely_ seen good password discipline in
real life.
--
Carson
Gert Doering
On Thu, Dec 24, 2009 at 08:51:25AM -0800, Carson Gaspar wrote:
> Gert Doering wrote:
> >On Thu, Dec 24, 2009 at 12:36:37PM +1300, Peter Lambrechtsen wrote:
> >>Why aren't you using authorized_keys with a public/private keys.
> >>That's what it's there for. Among other reasons.
> >
> >Unfortunately, some vendors fail to understand this. Like "Cisco". Or
> >"Citrix" (who *can* do pubkey auth, but there is no persistant storage
> >on the netscalers, so it will only work up to the next reboot).
> >
> >For the time being, us poor admins have to fall back to nastier
> >approaches... like "put passwords into files".
>
> A better approach would be to use Kerberos. Most enterprise vendors like
> the ones you mention support GSSAPI auth. Of course some don't :-(
Hmmm. I didn't have that much exposure to Kerberos yet, but doesn't
kerberos require me to manually acquire a ticket with kinit first, before
I can use that to remotely log to devices?
The scenario I have in mind is things like "automatically and unattendedly
backup the configuration of routers via SSH", and requiring a manual kinit
first would not be very useful.
But still: you're sure kerberized SSH to Cisco or Citrix Netscalers work?
I've never seen this mentioned on any of the Cisco lists, and that would
certainly be helpful for day-to-day operations.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@greenie.muc.de
fax: +49-89-35655025 ge...@net.informatik.tu-muenchen.de