[Swift-user] Question re: reliance on proxy cert

[Michael Wilde]

Tom, for now, this means that when using automatic coasters over ssh, you need to (manually, out of band) create an x509 proxy on both sides. Either securely copy one, or run grid-proxy-init on both the client side (where you are running Swift) and on each site on which Swift will start a coaster service.

One can bypass the need for proxies when setting up manual coaster configurations with the -nosec argument to the coaster-service command.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Thomas Uram" <turam at mcs.anl.gov>
> Cc: "swift user" <swift-user at ci.uchicago.edu>
> Sent: Wednesday, January 18, 2012 12:43:40 PM
> Subject: Re: [Swift-user] Question re: reliance on proxy cert
> On Wed, 2012-01-18 at 12:33 -0600, Thomas Uram wrote:
> > I'm using coasters with ssh:pbs and have the proper bits in
> > ~/.ssh/auth.defaults to support authentication, but when I run the
> > script it fails due to a missing or expired proxy cert:
> 
> [...]
> 
> > Why does it fail when an alternative authentication mechanism is
> > available that would succeed? Is there an option to control this?
> 
> It fails because while ssh is used to start the coaster service
> executable, the connection between client and service is secured by
> GSI.
> 
> This model was just peachy in the Globus scenario, where you would
> need
> a proxy anyway to start the service and delegation could be used to
> supply credentials to the coaster service.
> 
> Not so much with ssh. I've been thinking about a way to deal with
> this,
> and I think I'm leaning towards some shared secret that could be used
> as
> a one-time authentication token by the service. The problem is making
> sure that whatever provider is used to communicate said secret to the
> service remains a secret (i.e. passing it on any command line is out
> of
> the question). But that seems to require the use of an encrypted file
> transfer provider, which breaks the abstraction we have a bit, so it
> might require more changes than I want to see.
> 
> So suggestions are welcome.
> 
> Mihael
> 
> _______________________________________________
> Swift-user mailing list
> Swift-user at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-user

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