I have a couple of nodes at locations where I have access to internet but I don’t have administrative access to do port forwarding in the router to allow for accessing them via ssh. My work around for this in the past was to use reverse ssh tunneling which worked great. Recently however I am no longer able to make this technique work. I am able to make the forward connection work from the client end (at the remote site) back to my server, but when I try initiating the return tunnel from my home server I get the following;
kex_exchange_identification: read: Connection reset by peer
Connection reset by ::1 port 2295 (…note - port 2295 is the port I’m using as the localhost connection)
Any suggestion on how to resolve this issue?
The reverse tunnels I had established prior to a couple months ago still work as they should. I’m just not able to make it work on any new ones I’m setting up now.
You'd have to explain more of your configuration. What I THINK you're saying is:
You have a system running at a remote site running ASL3 (is this the appliance or something you built?)
The remote server(s) SSH outbound from the remote site to some sort of server/head-end.
Each SSH connection terminates on the server with what exactly? And it's bringing along a forwarded port back to localhost on the originating connection?
So then on the server/head-end you're trying to establish an SSH connection on localhost port whatever which should be tunneled back to the server but it's failing?
Connection reset by ::1 port 2295 is telling you either the tunneled port isn't really listening on your server on port 2295 or the tunnel is up but nothing on the other end is listening on port 2295 (or whatever you've tunneled to). But you'd need to explain more about your topology and configuration for me to do more than guess.
However this doesn't sound like an ASL3 Appliance issue. We're not doing any management of SSH configurations.
Yes - all systems running at the remote sites are running ASL3 on a Raspberry Pi with the most recent updates applied.
Yes - the remote server’s outbound SSH are to a Raspberry Pi running ASL3 that is also being used as an active node… head-end as you mentioned.
The SSH connection from the remote site specifies the desired port on localhost of the server at the head-end. I then connect to the remote server by porting thru that “listening” port on localhost of the head-end server.
Yes - you have it correct… the error message I am now getting occurs on the head-end server when I try to make the tunnel back to the remote server through the port that was assigned for listening on the head-end’s local host.
I was leaning toward the notion that perhaps my issue has something to do with the firewall for ivp6. Admittedly, it likely isn’t directly an ASL3 appliance issue but it is a feature of Linux I’ve successfully used. The feature has certainly came in handy by keeping me from driving out to a distant repeater site whenever I want to make a change to any of the ASL3 settings or to run updates.