The first thing is to find out which server is used. This can be done with banner grabbing. When you know the version, you can search for exploits.
Most current servers like OpenSSH does not have exploits, which can be used to compromise the serverside.
The first thing is to find out who owns the server. This can be done with CVE-2016-20012. With this exploit, you can compare known public keys with user accounts. For example, you can collect them from github.
When you know who owns the server, you can try a mitm attack and compromise the session. Since your target is tor you should try a phishing attack.
Note: This is, how I start an audit on ssh servers and clients. This is not Tor specific, but perhaps it will help you.
To find out, which version of ssh runs on the serverside, you should use banner grabbing. This can be done with netcat or telnet:
$ telnet serveraddress 22
In this example, OpenSSH with version 8.2 on the server side. Some SSH servers also adds more information. The ssh server is running under ubuntu. Perhaps this can help you when other services are running on the same server.
You should search for exploits, which are usable in the default configuration. If the exploits needs some special configuration it's unlikely that the exploit will work. Most users does not configure the server or client side except for publickey authentication.
The next step is to collect information. Don't expect to get the information in a few minutes. If you need to collect information in a local network this can take a few hours, but more realistic is that it takes some days. If you need to collect information on the internet, this can take weeks. I think, your service is a tor hidden service. So collecting relevant information takes even longer.
You should try to get some possible usernames. If the administrator is lacy, there is a good chance, that the root user is used but this is unlikely. Getting a valid username is one of the most important steps, if you want to compromise a server. The reason is, that a lot of information gathering and information leaks depends on a valid user. Perhaps you can use another service on the same server to get a valid ssh username.
If you got possible usernames, than the next step is to get public keys. Most ssh servers are configured to use publickey authentication. So you need to find a valid target.
You can collect publickeys from Github and Gitlab. Some companies are running a private/public gitlab server. Collect the publickeys from users, where you think, this could be a valid user on the server, which you audit. Perhaps the username from Gitlab/Github is a valid user for the ssh server too ;-)
After collecting the public keys, you can start to check if you already have a possible username/publickey combination.
To get this information, an exploit for CVE-2016-20012 can be used. An audit tool for this exploit is integrated in SSH-MITM.
To check if a username/publickey combination is valid, you can use the ssh-mitm-audit (python package) or ssh-mitm.audit (snap package) command:
ssh-mitm.audit check-publickey --host hostname --port 22 --username user --public-key /path/to/publickey
If you found a valid combination, you should check if the publickey is a weak key. Gitkraken had a vulnerability, where weak keys where generated: CVE-2021-41117. If you are lucky, you should generate the private key for the valid publickey.
If the valid key was not a weak key you have to gain access through other channels.
The best option is to start a phishing attack. In this case you have to setup your own server. I'm not an expert in phishing attacks, but the most common is sending emails, but it's up to you, how you start your phishing campaign.
You should use a man in the middle server, which is capable to intercept publickey authentication. At the moment (2021-11-01), the only server, which is able to intercept publickey authentication and abuse a forwarded agent is SSH-MITM
To intercept the session, all you have to do is starting ssh-mitm and redirect the traffic to your target server.
ssh-mitm --remote-host targetserver:22
In this scenario ssh-mitm does not exploit any vulnerabilities, except CVE-2016-20012.
disclosure: I'm the author of SSH-MITM