On Sat, May 30, 2015 at 10:38 AM, Phil Pennock <phil.pennock at globnix.org> wrote:> On 2015-05-30 at 15:00 +0200, Kasper Dupont wrote: >> On my laptop I have key1 and key2. I can use key1 to log in >> on server1, and I can use key2 to log in on server2. I want >> neither key to leave the laptop, and only key2 is allowed >> to be forwarded to other hosts. > > As validation for what Kasper is saying, so that others know that it's > not just him: > > $work would use the feature you describe. At present, the key1 that you > describe is unencrypted :( but is used for perimeter access, while key2 > is used for intra-cluster access, but because it's forwarded onto less > trusted hosts, can't be allowed to be used for getting into the cluster > in the first place -- we constrain the impact of a breach. Not ideal. > > We'd like to move to using transient certificates issued for perimeter > access, using OpenSSH CA, but that requires that the key1 role be loaded > from an agent. If we move to the same transient certificate used for > the key2 role then we get all the benefits of short-lived proof, but we > lose our containment of impact of breach. > > So if you come up with a solution letting the ssh(1) command be told to > use one agent for auth to the remote host but to pass a different agent > as the forwarded auth signer, we would use it too.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" I'll also point out that with Gnome and KDE there are wallets to hold keys and to unlock them once in the wallet that might be useful. Another workaround is to set an ssh-agent with both keys and automatically delete that first key, if present, in your .bashrc or .login procedures in the remote account. That doesn't keep the first private key around for repeated logins, but that might be enough for some circumstances. 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.....
On Sat, May 30, 2015 at 11:25 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:> 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.....Sorry, should have said 'svn+ssh'.
Nico Kadel-Garcia wrote:> Mind you, I've never been complete thrilled with ssh-agent.Then look into extending it, or writing a new one which does what you want.> If you really want to segregate credentials for different environmentsThe agent knows who is asking it about using a key, so you could certainly have a single agent which applies a policy based on that. //Peter
On 30/05/15 20:41, Peter Stuge wrote:>> If you really want to segregate credentials for different environments > The agent knows who is asking it about using a key, so you could > certainly have a single agent which applies a policy based on that.No, it doesn't. For the ssh-agent, it's the same ssh(1) process both times. The difference lies in that the first time it is using it itself for authentication and the second one it is asking that on behalf of a remote untrusted process. (OTOH the proposal from February that suggested a "received parameter", would allow this kind of thing)
On Sat, May 30, 2015 at 2:41 PM, Peter Stuge <peter at stuge.se> wrote:> Nico Kadel-Garcia wrote: >> Mind you, I've never been complete thrilled with ssh-agent. > > Then look into extending it, or writing a new one which does what you > want.My underlying, long-term concern with ssh-agent is my underlying concern with private SSH keys. There's currently no way to enforce secure handling of them on the client side. The almost inevitable result is that people simply use unencrypted private keys, whether or not they're accumulated in an ssh-agent for access to multiple systems. And even intelligent, educated developers and sysadmins copy unencrypted private SSH keys around to remote hosts, wehter or not they are willing to use ssh-agent, because it's simpler. There are some helpful stopgaps to unlock and store access to a shareable ssh-agent for unattended system operations, such as using the 'keychain' perl script to configure and access SSH keys for an 'rsnapshot' or similar rsync over SSH based access. But the normal procedure is to not bother, and simply use unencryped private SSH keys. This is, in fact, written into dozens of "chef" and "puppet" system management cookbooks. I've been trying to spend time there trying to provide better handling of private keys, and boy, it's an uphill battle!!!>> If you really want to segregate credentials for different environments > > The agent knows who is asking it about using a key, so you could > certainly have a single agent which applies a policy based on that. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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
On Sun, May 31, 2015 at 2:29 AM, Phil Pennock <phil.pennock at globnix.org> wrote:> 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".Yeah. If you have to go that route, it's well worth the extra steps to restrict the operations available to the passphrase free key. But that's a whole separate artform. Hmm. Another fugly approach is to use the first connection, with a $HOME/.ssh/config set to not forward agents to the target host, perbaps with an alias of "target-tunnel", and set up an SSH tunnel on your local server to the remote SSH. Then set up a second entry for normal connection that goes through the designated local port but *does* activate ForwardAgent. I've actually recently done something similar with the 'autossh' toolkit, to tunnel rsync over SSH connections to where I wanted them, drilling through a "jumpgate" host. This is also one of those cases where the sometimes deprecated "chroot" cage approach running an SSH daemon can be helpful, to use the first access key to access just such a "jumpgate" server and segregate typical users from seeing each other's accounts or other system information. I publish updates for the autossh 'mkchroot.sh' tool at https://github.com/nkadel/rssh-chroot-tools>> Mind you, I've never been complete thrilled with ssh-agent. If yo >> 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.Well, yes. that's one of the "Just use NTP and use it correctly" situations pops up. But if the client host is a developer admin laptop or VM without good configuration management, yeah, life can get pretty confused. It's aggravated if the Kerberos server is on old, bog stable hardware on which the motherboard battery has expired, and you reboot it to migrate data centers, and NTP is not set to do a hard "I'm not kidding, actually reset this completely no matter how far off you are".> 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. > > -PhilYeah, I *wish* svn+ssh could work this way. The activation of a single user's access and credentials is currently done through "command" option among the received SSH keys. It would take an entirely different system to allow Kerberos to do this, but that's more code than I can take on.