Untracked Trust Relationships: Just as with any access method, not keeping an inventory of where SSH keys are installed and the trust relationships they establish between systems and accounts is a recipe for unauthorized access.Since many organizations don’t have centralized oversight and control of SSH, the risk of unauthorized access is increasing. In addition, there have been bugs in cryptographic libraries (e.g., Debian in 2006) that have resulted in weak, easily breakable keys being generated.īecause SSH provides remote access into systems, it is critical that access be tracked and controlled. Weak Keys: Because many SSH keys have not been changed in years, smaller length keys (e.g., 512 or 768-bit keys) are still in use, making it possible for a sophisticated attacker may derive the value of the private key.Administrators can make copies of those private keys and, if they’re reassigned or terminated, can use the key(s) to authenticate to the target servers. Administrator Turnover: When public key authentication is used for automated processes, one or more administrators for the process will be responsible for managing the process’ private key.
Careless Users: When users are authorized to use SSH public key authentication, they can be careless in their handling of their private keys, either placing them in insecure locations, copying them to multiple computers, and not protecting them with strong passwords.Here are some of the risks posed to SSH private keys: If a private key gets compromised, an attacker can authenticate into the account(s) where the private key is trusted. When you configure SSH for public key authentication, private keys then enable access to accounts. In addition, attackers avoid detection because they are operating over an encrypted SSH connection. By exploiting port forwarding, an attacker may bypass firewalls that have been setup to limit access to the server’s network.
If the user of an SSH client that has been granted SSH access to a server on the other side of a firewall is allowed to enable local port forwarding, they open the possibility that an attacker can gain access to systems and devices which might otherwise not be accessible. The challenge is that this provides the ability for unapproved communications to traverse firewalls. The traffic is forwarded through the encrypted SSH session to the SSH server or even beyond. In addition, if your users and administrators arbitrarily change those configurations without considering the security implications, they can open those systems to broader attacks.ĭating back to the days where encryption wasn’t available for all protocols, SSH features the ability to forward traffic sent to a local port on an SSH client. However, there are a couple of defaults, such as port forwarding and the location of authorized key files, that are not optimal.
Fortunately, over the years, most SSH implementation developers have selected default configurations that are more secure. Most SSH server and client implementations (e.g., OpenSSH) include a significant number of configuration parameters which impact operation and security, including options for authentication, root access, port forwarding, file locations, etc.
#SSH SHELL WITH OTHER PERSONS AUTHORIZED KEYS SOFTWARE#
If you have users and administrators enabling SSH server (sshd) access on systems where it isn’t required, you’re expanding your attack surface because attackers will have a greater possibility of remotely gaining access to those systems.įor the systems where SSH use is justified, if SSH server and client software is not kept up to date with fixes and updates, it can expose the systems and data it is designed to protect and make them vulnerable to compromise. As you can see, the risks span the SSH server and client, with most arising on the server-side. The diagram below provides a summary of SSH risks.
0 kommentar(er)
