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