Re: The keychain package, its debconf templates, the security hole induced
Henrique de Moraes Holschuh <firstname.lastname@example.org> writes:
> On Fri, 21 Jan 2005, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh <email@example.com> writes:
>> > This can very well be a much bigger security risk than doing what you
>> > already do BUT using passphrases AND ssh-agent to reduce the window of
>> > opportunity.
>> Even if you get hold of the key all you can do with it is exactly what
>> the cron job is doing anyway. The worst you can do is flood the
>> destination system with jobs, e.g. start a daily cron job every
> That depends on what you're running on the other side, doesn't it? If it can
> be exploited depending on what you do with it...
The other side will be running sshd and with keys restricted to a
command the sshd strips away the command line and only executes the
command specified for the key.
If you add security holes into that command (like sloppy parsing of
the original command line) that is your own problem. You can always
leave the front door unlocked or the keys in the car.
I wish there would be more documentation on this subject in ssh and
maybe even save example code to extract options from the original
commandline. There could be an example for e.g. cvs or rsync.
>> Limiting an ssh key to a specific command severly limits the damage
>> you can do with it. This should be a must for any key that is to be
>> used non interactively.
> Agreed. But that is orthogonal to ssh-agent use, since ssh-agent use (and
> keychain use) does NOT preclude specific command limiting.
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
> Henrique Holschuh