Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. This file is usually found in the user's home directory under <user-home>/.ssh/authorized_keys (or, on ESXi, /etc/ssh/keys-<username>/authorized_keys).^[1] Users may edit the system’s SSH config file to modify the directives PubkeyAuthentication and RSAAuthentication to the value yes to ensure public key and RSA authentication are enabled, as well as modify the directive PermitRootLogin to the value yes to enable root authentication via SSH.^[2] The SSH config file is usually located under /etc/ssh/sshd_config.

Adversaries may modify SSH authorized_keys files directly with scripts or shell commands to add their own adversary-supplied public keys. In cloud environments, adversaries may be able to modify the SSH authorized_keys file of a particular virtual machine via the command line interface or rest API. For example, by using the Google Cloud CLI’s “add-metadata” command an adversary may add SSH keys to a user account.^[3],[4] Similarly, in Azure, an adversary may update the authorized_keys file of a virtual machine via a PATCH request to the API.^[5] This ensures that an adversary possessing the corresponding private key may log in as an existing user via SSH.^[6],[7] It may also lead to privilege escalation where the virtual machine or instance has distinct permissions from the requesting user.

Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve privilege escalation on the target virtual machine if they add a key to a higher-privileged user.

SSH keys can also be added to accounts on network devices, such as with the ip ssh pubkey-chain Network Device CLI command.^[8]

References

1. ssh.com. (n.d.). Authorized_keys File in SSH. Retrieved June 24, 2020.
2. Broadcom. (2024, December 12). Allowing SSH access to VMware vSphere ESXi/ESX hosts with public/private key authentication. Retrieved March 26, 2025.
3. Google Cloud. (2022, March 31). gcloud compute instances add-metadata. Retrieved April 1, 2022.
4. Chris Moberly. (2020, February 12). Tutorial on privilege escalation and post exploitation tactics in Google Cloud Platform environments. Retrieved April 1, 2022.
5. Microsoft. (n.d.). Virtual Machines - Update. Retrieved April 1, 2022.
6. Blachman, Y. (2020, April 22). Growing Abuse of SSH Keys: Commodity Malware Campaigns Now Equipped with SSH Capabilities. Retrieved June 24, 2020.
7. Cybereason Nocturnus. (2019, June 13). New Pervasive Worm Exploiting Linux Exim Server Vulnerability. Retrieved June 24, 2020.
8. Cisco. (2021, August 23). ip ssh pubkey-chain. Retrieved July 13, 2022.

Propojené úkoly

• MITREATTACK -

  © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. https://attack.mitre.org/

  Terms of Use

  LICENSE

  The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK^® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy.

  "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation."

  DISCLAIMERS

  MITRE does not claim ATT&CK enumerates all possibilities for the types of actions and behaviors documented as part of its adversary model and framework of techniques. Using the information contained within ATT&CK to address or cover full categories of techniques will not guarantee full defensive coverage as there may be undisclosed techniques or variations on existing techniques not documented by ATT&CK.

  ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  See our FAQ for more information on how to use and represent the ATT&CK name.