SSH Persistence
As another approach to gaining system access, we could insert our public key
into a user’s authorized_keys file.
This file is a list of all of the public keys permitted to access
the user’s account on the current machine
Adding our public key to a user’s authorized_keys file
will allow us to access the machine via SSH later on.
Normally, we might copy public keys from a remote system with ssh-copy-id,
which requires authentication.
However, if we have write access,
we could simply append a new line to authorized_keys.
Note that most Linux systems require 644 permissions on authorized_keys…
which means we that only the file owner and root can write to the file.
Let’s take a look at the linuxvictim machine in the lab.
If we’ve gained access as the linuxvictim user or as root,
we could write an SSH key to linuxvictim’s authorized_keys file to maintain access.
To do that, we’ll first create an SSH keypair on our Kali VM.
We can do this with ssh-keygen.
If we accept the default values for the file path,
the tool will create a pair of files in our .ssh/ directory.
It will create an id_rsa file containing the private key and an id_rsa.pub file
containing the public key.
We can then use xclip to copy the contents of the public key to the clipboard.
On the linuxvictim machine,
we can insert the public key into the linuxvictim user’s authorized_keys file.
We can then ssh from our Kali VM using our private key to the linuxvictim machine
and log in as the linuxvictim user without a password.
If we don’t specify an SSH private key
the SSH client will use the default id_rsa.
Backdooring authorized_keys files, stealing unprotected SSH keys,
and brute forcing SSH passphrases are all useful tactics during a penetration test.
In the next section, we’ll discuss some more advanced ways to abuse SSH.