This analysis is so spot on I don’t have much to contribute other than praise. I immediately applied a patch to my own codebase to clear an I/O buffer after a flush, based on this analysis.
A question:
I use ssh agents, and I get too much utility out of them to give them up entirely. I’m aware, but not to the degree I should be, over the danger posed by that tool when managing a fleet of servers: namely that a compromise of one can lead to a complete compromise of your fleet.
I’ve done barely adequate mitigation for this problem, and would like to do more. What’s the best practice here? @tedu suggests an agent process per remote–I’ll presume for my own issue that I’d have a unique key in each instance. Is there something easier to manage than that?
This analysis is so spot on I don’t have much to contribute other than praise. I immediately applied a patch to my own codebase to clear an I/O buffer after a flush, based on this analysis.
A question:
I use ssh agents, and I get too much utility out of them to give them up entirely. I’m aware, but not to the degree I should be, over the danger posed by that tool when managing a fleet of servers: namely that a compromise of one can lead to a complete compromise of your fleet.
I’ve done barely adequate mitigation for this problem, and would like to do more. What’s the best practice here? @tedu suggests an agent process per remote–I’ll presume for my own issue that I’d have a unique key in each instance. Is there something easier to manage than that?
I recommend adding keys to your agent with confirmation enabled. Then if anything calls back to your agent, you’ll be notified and/or can deny it.