[Swift-devel] askpass for command line ssh provider?

[Michael Wilde]

Hi Ian,

Yes, we'd like very much to do that; it was always our first preference. When we explored it last quarter, GO did not yet have a solution for this, but the intent was to stay in touch and use any solutions that became available, especially as one of the portal mechanisms here is the "GO Swift" prototype.

Is such a solution now available or in the works?  Who's the point person for GO authentication?

- Mike


----- Original Message -----
> From: "Ian Foster" <foster at anl.gov>
> To: "Jonathan Monette" <jonmon at mcs.anl.gov>
> Cc: "Michael Wilde" <wilde at mcs.anl.gov>, "Swift Devel" <swift-devel at ci.uchicago.edu>
> Sent: Monday, January 16, 2012 10:38:38 AM
> Subject: Re: [Swift-devel] askpass for command line ssh provider?
> I wonder if we can leverage what Globus Online is doing for this
> purpose?
> 
> On Jan 16, 2012, at 10:31 AM, Jonathan Monette wrote:
> 
> > I always thought the solution to the OTP situation was to set up a
> > master channel. Inside a portal this is easy. The portal knows which
> > sites are used and which sites require a OTP. The portal can then
> > set up a master channel. For the situation for the agents, the
> > portal can always create the agent itself after prompting for a
> > password once can't it? In both scenarios the portal creates the
> > mechanisms to limit the number of passwords that are required.
> >
> > For Swift, I do not think that these solutions work since Swift
> > needs to be more general(maybe creating agent approach but that
> > won't work for OTP situations).
> >
> > On Jan 16, 2012, at 10:07 AM, Michael Wilde wrote:
> >
> >> Was: Re: [Swift-devel] command line ssh provider...
> >>
> >> After a bit more thought, it seems that enabling the ssh-cl
> >> provider to prompt for passwords is perhaps not a required feature.
> >>
> >> We will for example need to access many systems that needs a one
> >> time password.
> >>
> >> But its likely that such mechanisms need to be set up outside of
> >> Swift (or at least outside the main line of the provider), using
> >> agents or master channels, else the user would get multiple
> >> password prompts per endpoint.
> >>
> >> For now, we can do this outside of Swift proper (ie in the various
> >> portals, ideally via scripts that we package in swift/bin which can
> >> be used by both command line users and by portal code).
> >>
> >> Later we can consider if its reasonable to make the ssh-cl provider
> >> smart enough to invoke such channel or agent setup scripts
> >> automatically when needed.
> >>
> >> - Mike
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> >>> To: "Michael Wilde" <wilde at mcs.anl.gov>
> >>> Cc: "Ben Clifford" <benc at hawaga.org.uk>, "Swift Devel"
> >>> <swift-devel at ci.uchicago.edu>
> >>> Sent: Friday, January 13, 2012 6:09:18 PM
> >>> Subject: Re: [Swift-devel] command line ssh provider...
> >>> On Fri, 2012-01-13 at 18:00 -0600, Michael Wilde wrote:
> >>>> Another good test is to access eg surveyor, and intrepid using an
> >>>> OTP via ssh-cl.
> >>>
> >>> A word of caution there: if the ssh client asks for the password
> >>> on
> >>> the
> >>> command line (instead of through ssh-askpass or some other gui),
> >>> things
> >>> won't work very well. It might be possible to add some detection
> >>> for
> >>> that in the provider, but that's not a high priority given that
> >>> there
> >>> is
> >>> a workaround (askpass).
> >>
> >> --
> >> Michael Wilde
> >> Computation Institute, University of Chicago
> >> Mathematics and Computer Science Division
> >> Argonne National Laboratory
> >>
> >> _______________________________________________
> >> Swift-devel mailing list
> >> Swift-devel at ci.uchicago.edu
> >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> >
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory