On 2015-05-30 at 11:25 -0400, Nico Kadel-Garcia wrote: > The workable, but fugly solution is to load an ssh-agent with the keys > you want in environment two, keep a local unencrypted private key for > permiter access to environment one stored in a shielded, protected, > ideally locally disk partition encrypted location, and set up > $HOME/.ssh/config with a "Host" entry to specify that > non-standard-location unencrypted key location to use for accessing > that permiter host or those perimeter hosts. I don't like this > solution myself, but it satisfies all the stated requirements of "I > don't want to keep typing my perimeter key passphrase" This is what we do. The reliance upon disk encryption and loss of passphrase protection is ... "unfortunate". > Mind you, I've never been complete thrilled with ssh-agent. If you > really want to segregate credentials for different environments, you > might look into Kerberos based authentication, which can provide a > very different approach to finer grained credential management. I just > wish I could get it to work with Subversion..... Each environment is distinct, in locations where we don't fully control DNS and where Kerberos is not a plausible solution. At least, I haven't considered it seriously, but I'll think on it some more. >90% sure it's not, given that one of the things I've had to log into those setups to do was to fix messed up system clocks. A bit of a chicken/egg problem if that now requires Kerberos. When I used subversion with Kerberos, I only used it with https and was always fighting some aspect of the lack of consideration for this use-case. Neon would at least allow Kerberos via WWW-Negotiate, as long as HTTPS was in use, not HTTP. -Phil _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
