Apache says improper restriction of SSH keys was a primary factor enabling a recent attack that took down one of...
its Web servers. How do SSH keys represent an attack vector and what are the most important factors in ensuring SSH keys are restricted appropriately?
Secure Shell keys protect communication between two networked devices, and they are often used for remote authentication.
Passwordless SSH keys used for automated processes represent an attack vector because their safety is determined by the security of the host. If the security of this host system is compromised, an attacker consequently has access to the SSH key.
In fact, the SSH key needs to not have a password so that the automated processes can run unattended. The SSH key can be password protected and the automated process can have the password embedded in it, but these settings only slow the attacker down.
Unrestricted SSH keys will also slow or restrict an attacker to only use the SSH key to connect from specified locations or from using specified commands. This will require the attacker to route his or her attack through these systems or be limited to the specific command. These restrictions can greatly improve the security of SSH keys, but one additional step that can be taken on the SSH server is to only enable an account used during the time necessary to set up a connection, thus further limiting access to the account.
For example, if you need to use rsync, a software application that synchronizes files from one location to another, over SSH, follow the recommendations from the Apache incident and restrict where a SSH key can be used from, what commands it can run, and additionally have an automated process that enables and disables the account used during the time window for the rsync. This limits an attacker to only using the SSH key from the specified host using the specified command at the specified time. The technique here isn't impervious from attack, but it is a definite improvement over unrestricted, passwordless SSH keys.