Anydesk on raspi

I'm not sure what anydesk does but I connect to a remote Beaglebone Black (much like a Pi, SBC running Linux) using ssh via reverse tunnel ssh set up on the remote Beaglebone.

So you need to set up reverse tunnel outgoing connections from your Pi, this you have to do with access to it of course. Then, once that's done you can access it using ssh from 'outside'.

If you want to know more then just ask.

--
Chris Green

AnyDesk is a remote desktop viewer and doesn't do CLI.

el

--
If you want to email me, replace nospam with el

Chris,

I might have use for something like this (for a host which I can access via AnyDesk, but not SSH, at the moment.

Where can one read up on how to do this?

el

[...]

--
If you want to email me, replace nospam with el

In various places, it's not really "all in one place".

If you look for 'ssh reverse tunnel' you will find how to do the ssh bit. Basically it uses the -R option of ssh so that a 'remote' system you have connected to from your Pi using ssh can connect back through the same connection *to* the Pi.

The ssh man page explains it moderately well but you might want to try searching for some examples as well, you do need a clear mind to set it up right. :-)

My Beaglebone Black (the system like a Pi) is on a boat in France behind a commercial WiFi system, so I run the following on it:-

ssh -nNT -R 51236:localhost:22 chris@

This connects port 22 (the sshd server port) on the Beaglebone to port

51236 on myhost. Then all you need to do is connect to port 51236 on myhost and you actually connect to the Beaglebone. I.e. you just do 'ssh -p 51236 localhost' on myhost to connect through the reverse tunnel. The 51236 is just a random port number, greater than 1024 so that it can be used by a non-root process.

To make this more robust I use a litte utility called autossh on the Beaglebone to make the outgoing connections, this restarts ssh if it dies, etc. You can find out about that by searching too and it's rather less confusing so I won't say any more here.

--
Chris Green

Am 27.10.20 um 13:07 schrieb Dr Eberhard Lisse:

oha... ok, i was not shure about this feature.#. Thx.

Jan

Chris,

Why not simply run sshd on the RPi?

I do that on my LAN. ssh, git and gftp (using sftp protocol) all connect to my RPi successfully. Presumable

So, why use the reverse SSH setup rather than running sshd behind a firewall on the RPi with the firewall configured to only accept connections from your other systems?

Or configure the sshd server to only accept connections from IP addresses and/or hostnames that you control rather than using the firewall to do that?

I'm not knocking your approach, simply curious about what problems reverse SSH solves that using a firewall or a suitably configured copy of sshd can't handle.

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

Den 2020-10-27 kl. 16:40, skrev Martin Gregorie:

To setup a ssh-tunnel like that could be a way of fighting ISIT/admins? Usually you can break out from a network, but you need someone else to do NAT/port forwarding if network owned by someone else. And they might refuse?

I have sshd running wide open on two public servers. Although they are attacked constantly - several per second attempts - no one has ever guessed my username and password, which is the only one that allows a login...

..and if someone does, then I will restore from backup and change them....

People are too precious about security.

Heck I run NFS over the internet with just access allowed from my private IP range

I don't see why if he wants to see a desktop on the Pi remotely he does not just run an X server to a remote client. Its slow, but it does work.

Or build a web app that allows you do to what you need on the remote systems

Essentially that's how I run my servers - web apps, NFS and in extremis ssh and su - root...

I think that you can tell sshd to reject name/password in favour of some massive length key...that is more secure than a password...

--
"When one man dies it's a tragedy. When thousands die it's statistics." 

Josef Stalin

It sounded like he had things set up like that because the system in question is behind a firewall that he doesn't control. I didn't know ssh could be used in that way...clever. I don't have anything positioned where such a trick would be useful (I have control of firewall settings at home and at work, so I just forward an external port to port 22 on the device and call it good), but when you need it, you *need* it.

_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(

Top-posting! \_^_/ >What's the most annoying thing on Usenet?

If you're logging into a public-facing server with your password, you're doing it wrong. Read up on SSH public-key authentication, and set it up. It's easy, and it's more secure than passwords.

Also, if you don't already have it, set up fail2ban. It'll ban IPs that hammer your SSH server.

_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(

Top-posting! \_^_/ >What's the most annoying thing on Usenet?

I meant a local firewall on the RPi - the fact that he can make the connection at all means, I think, that any sitewide firewall between him and the RPi must understand references to machines behind it in order to pass incoming ssh connection requests to the appropriate machine on the remote LAN.

So, I'm still curious because regardless of whether the RPi is doing the 'ssh -R' trick or running an sshd server, its still only advertising an open ssh port (22) and the system running Anydesk still has to know the IP of the RPi or access it via some sort of address translation mechanism which hasn't been described so far.

-- Martin | martin at Gregorie | gregorie dot org

Because there's no "way in" from the outside, it's behind several layers of NAT (or NAT alike) firewall that you (or I) have no control over. Therefore there is no hostname or IP address to connect to from outside.

--
Chris Green

No port forwarding is needed, that's much of the point. The connection goes 'back' through the standard outward ssh connection.

--
Chris Green

I use that mostly, yes. But I leave the odd backdoor open for when I am away from all devices that I own...

To be honest, I am not sure that the fail2ban uses any less cycles than sshd when rejecting rubbish

Let's put it this way. The amount of CPU and RAM used in rejecting ratware is less than is used in rejecting attempts to sntp relay and so on.

I make a point of not fixing problems I don't have.

--
Labour - a bunch of rich people convincing poor people to vote for rich  
people by telling poor people that "other" rich people are the reason  
they are poor. 

Peter Thompson

Fair enough. Thanks to the answer.

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

This is why places that really care about security block outgoing ssh.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

You have it exactly right! :-)

--
Chris Green

Using an ssh reverse tunnel will get one through just about *any* firewall. All the firewall/routers can see is ssh traffic going the 'normal way' from the client behind the firewall to wherever the server is.

It's advertising an sshd server port but that port is 'exported' via the reverse tunnel which is created by an ssh *client* running on the same system. So when a remote client is trying to connect it doesn't need to know anything about the RPi system at all, only a port number on 'localhost' of the system where it is.

--
Chris Green

e

re

t it up.

Seconded.

Ps that

A lighter weight alternative if you only have a limited set of ports exposed to the world is sshguard.

on.

Rejecting the connection at IP firewall level takes far less resources then allowing an ssh session to be negotiated then failing after the other end tries to login as root with a number of different common passwords.

See how big your auth log can get to if you don't.

---druck