There are two different methods to authenticate a user to establish an SSH connection:
The most common one is by entering a username and a password when asked by the remote ssh server. The other method is with ssh keys. It doesn't ask for a password when you authenticate with a key, but it may happen that you have somehow retrieved an ssh key, and in order to use it you first need to decrypt it with a password set by the user when the key was created. This password can be subject to a dictionary attack.
SSH private keys are stored by default in ~/.ssh/ (if we have retrieved one, we can save it there). There are actually two keys: id_rsa is the private key, which needs to exist in the computer trying to start the connection, and id_rsa.pub which is the public key and is in the server. "known_hosts" is a list containing known hosts that have connected by SSH in the past to a machine with SSH server enabled.
If we have a private key, login would be attempted as follows, from the directory containing the private key file:
ssh -i id_rsa email@example.com
This example is taken from vulnhub machine "covfefe", vulnerable to this authentication method. If the key is encrypted, it will ask us for the password for the private key. We can add the option "-v" to ssh to have verbose output of the steps taken during the ssh connection, to debug possible errors or get hints on what to try next.
With john the ripper this private key can be cracked, first adapting the file to john's format, and then passing it to john, for example with the rockyou.txt dictionary:
ssh2john id_rsa > shadow
cat /usr/share/wordlists/rockyou.txt | john --pipe --rules shadow
If we get a key, it has the default name id_rsa.key, or it can have the name: username.key for other keys. If this happens, we should try that key to login to username@IP, by default, if the key has one such name, it will be the username. Happens in Hackthebox's Valentine.
With ssh-keygen private keys are created. At the moment of creation, a this passphrase can be given, or the key can be created without passphrase if we hit "Return" twice when asked.
Another alternative to convert ssh keys to john format is the sshng2john python script
python sshng2john.py id_rsa > id_rsa.encrypted
john id_rsa.encrypted --wordlist=/usr/share/wordlists/rockyou.txt
The ssh server may also complain about the permissions of the private key, because it can "be accessed by others". In that case, change the permissions of the key with chmod to 600.
The authorized keys file contains the keys that can be used to connect to a certain user account. It is located in .ssh. It might be interesting to access this directory with some method (directory traversal, etc), and obtain the authrized keys, because for some openssl versions the keys are calculated from numbers between 1 and 256, and there exist 256 files with these pre calculated keys online. So with "grep -rl key *.pub" we would find the key we need to connect . Once we find the key, we connect with ssh -i.
The first time we connect to a host by SSH it gives us the server fingerprint (/etc/ssh/ssh_host_rsa_key.pub) which is stored locally in ~/.ssh/known_hosts. In the first lines there is a key identifier, a salt, and encrypted stuff. If the server key fingerprint changes with respect to our stored one (or viceversa) we will get a warning message the next try we try to connect, saying that someone may be doing "something nasty". This is typical when ssh is reinstalled in the server, we can erase the line corresponding to the old key fingerprint and a new one will be created when we reconnect.
The command "ssh-copy-id servername" can be used to let a remote host know about a client that will attempt to connect to it. The public key is copied on our attacking machine, in ~/.ssh/id_rsa.pub
In an SSH server we may modify options of the connection by editing the file /etc/ssh/sshd_config. For example, we can change the port used by SSH ("Port" option) or include the line "sshRootLogin no" to prevent anyone to connect to the root account by SSH.
If we have ssh access to a host, we can use scp to upload files to it. If the SSH server is operating in a non standard port, we need to specify it with the option -P (as opposed to -p, used for the ssh command).
scp -P 2022 local_file firstname.lastname@example.org:/path-for-uploads/
scp -P 2022 -r local_folder email@example.com:/path-for-uploads/
We can also transfer files from the victim:
scp -P 2022 firstname.lastname@example.org:/path-to-file/remote_file /local-path-to-file/
scp -P 2022 -r email@example.com:/path-to-remote-folder/ /local-path-to-folder/
To see the ascii art associated to a private key, use the following:
ssh-keygen -lv -f .ssh/id_rsa