> ssh-agent can be used if you really need to have multiple hops.
Possibly you mean, in one's ~/.ssh/config:
Host *.trusted.hosts another.one.trusted
ForwardAgent yes
Keep the keys where the users are
That's in the user's home directory. Which is stored on the network ...
The other antipattern is defining a passphraseless key for root@serverA and putting that in authorized_keys on serverB. This is trememdously useful but insecure.
> mesh of key-based access is so dense that it is highly likely that an attack can spread to nearly all servers in an organization
Why would you ever do that? Keep the keys where the users are. There is no mesh unless you distribute the private keys and you should never do that in the first place. ssh-agent can be used if you really need to have multiple hops.
> odds are the virus will infect nearly all servers [...] including disaster recovery and backup systems that are typically also managed using such keys
Why would you store private keys to your DR/backup servers all over the place? Backup is safer if it works via pull.
There are problems with SSH key management, but the situation they describe looks like there are issues with the design in general.
(as for the keys management - there are many solutions allowing reading public keys from ldap - that solves some of the problems)