A single key across multiple machines certainly reduces the amount of keys that a sysadmin needs to handle. I have five machines from which I might work (usually about three very active, but one might be in repair, another in very occasional use). If a company had eight people like me that makes 40 keys to administer instead of 8.
Yet the issue which Arcege has quite cleverly pointed out, albeit indirectly, is that if a single machine is compromised or even goes missing for a short period of time, that would mean I would no longer have access from any machine (as my key for all my machines would have to be pulled down). Surely the convenience of being able to remove a single key from a compromised or stolen laptop and to be able to keep working from another machine is worth the hassle of dealing with multiple keys.
In an even more extreme example, imagine that I'm the sysadmin and I have a laptop stolen or hacked. My key has to be removed yet I need access to all the systems to do so. While it's technically possible to replace and remove within a single session, when trying to move quickly and cover all one's bases, it considerably complicates the emergency scenario.
On the other hand, if I have unique keys for each workstation, if I can get to an alternative workstation, I can quickly and efficiently exclude the compromised key, without risking locking myself out.
As I delve more deeply into SSH keys approach to security, it's clear that for real security we should all be using both:
- what we have (SSH keys)
- what we know (password for the server)
Password requirement covers both access to the server and a password for the key. The hassle factor goes up but at the point we have all three in place (SSH keys, SSH key access password, server password) at that point there is no longer a single point of failure. A shared server password also protects your team against a very weak SSH key password (normally we don't have control over the level of password our colleagues generate - and a password admin in an enterprise situation where I have access to password auditing tools I can tell you even those who should know better sometimes create shockingly weak passwords).
An attacker would have to be determined and a successful attack might take months or even years. By changing the server password occasionally (every six months or so, server password shared with an enterprise level system like LastPass - remember there are SSH keys as well), at this point your servers enjoy reasonable security (as no one could combine a hot SSH key with an ancient password to break in).
One has to think of illegal insider access (Edward Snowden comes to mind, Ashley Madison hack comes second) as a primary risk. Only by using both keys and passwords would it be possible to really slow down an insider.
Other than the Ancient Chinese method: bury them alive when their job is finished.
After the burial, it was suggested that it would be a serious breach if the craftsmen who constructed the mechanical devices and knew of its treasures were to divulge those secrets. Therefore after the funeral ceremonies had completed and the treasures hidden away, the inner passageway was blocked, and the outer gate lowered, immediately trapping all the workers and craftsmen inside. None could escape.