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

[Ben Clifford]

in the ssh case, you should have a secure standard in/standard out over which you can send securely and so do either something like a gsi delegation or a shared secret transmission or whatever.

that doesn't apply to arbitrary cog providers though, I think.

so maybe its yet another growth of the configuration option space...?

On Jan 18, 2012, at 7:43 PM, Mihael Hategan wrote:

> 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
>