3 ms·

The system sounds very well thought-out, though probably not applicable at my $work location. > When an app on another server is started up, it must be done f

The system sounds very well thought-out, though probably not applicable at my $work location. > When an app on another server is started up, it must be done from a shell That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services. > When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent forwarded to it. In order for the app to get its database passwords and various other secrets, it makes a request to the secret server (over a TLS-encrypted socket), which checks your SSH identity against an ACL At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead?

jmillikin 12y ago
> That's a no-go for many setups. It doesn't integrate well > with how Linux distros usually start services (systemd, > upstart, sysv init, ...) Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial. > At this point you could have used ssh right away, no? > Any reason you used TLS + checking SSH agent instead? It sounds like they take an SSH identity certificate from the agent, send it via TLS, and then the remote process verifies it. This would have fewer potential security issues than trying to lock down a user's SSH login shell.
- perlgeek 12y ago
  > Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial. Well, the point is that the ssh needs to have forwarded agent from somewhere else. If the host on which the service is run can initiate it, the whole security aspect is gone. > This would have fewer potential security issues than trying to lock down a user's SSH login shell. Locking down a login shell (usually be not running a shell in the first place) is a solved problem, and for example gitolite uses it has the base of its architecture. Yes, you have to be careful, but you must also be careful when manually validating certificates.
ntucker 12y ago
> At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead? Yeah, using the SSH login method is actually quite slow for something you want to call at app startup on N instances during a push (at a minimum, your process responsible for whatever gatekeeping you do has to be respawned for every request, which necessarily puts a lower bound on the latency). I'm sure this could have been tracked down and optimized, but as jmillikin points out, another downside is that the additional per-user config can get kind of messy and error prone. Implementing logic like this at the .ssh/config level is (in my opinion) kind of easy to goof up and hard to test.

jmillikin 12y ago

> That's a no-go for many setups. It doesn't integrate well > with how Linux distros usually start services (systemd, > upstart, sysv init, ...) Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial. > At this point you could have used ssh right away, no? > Any reason you used TLS + checking SSH agent instead? It sounds like they take an SSH identity certificate from the agent, send it via TLS, and then the remote process verifies it. This would have fewer potential security issues than trying to lock down a user's SSH login shell.

perlgeek 12y ago
> Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial. Well, the point is that the ssh needs to have forwarded agent from somewhere else. If the host on which the service is run can initiate it, the whole security aspect is gone. > This would have fewer potential security issues than trying to lock down a user's SSH login shell. Locking down a login shell (usually be not running a shell in the first place) is a solved problem, and for example gitolite uses it has the base of its architecture. Yes, you have to be careful, but you must also be careful when manually validating certificates.

ntucker 12y ago

> At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead? Yeah, using the SSH login method is actually quite slow for something you want to call at app startup on N instances during a push (at a minimum, your process responsible for whatever gatekeeping you do has to be respawned for every request, which necessarily puts a lower bound on the latency). I'm sure this could have been tracked down and optimized, but as jmillikin points out, another downside is that the additional per-user config can get kind of messy and error prone. Implementing logic like this at the .ssh/config level is (in my opinion) kind of easy to goof up and hard to test.