Anydesk on raspi

Hello,
I have a raspi running in other country without GUI - only CLI.
Dyndns and other are not working because ipv4 over ipv6.
After installing anydesk i can connect to the raspi, but my client says
"display server not supported".
Is ther any chance to connect to the CLI of my raspi?
Jan
Reply to
Jan Novak
Loading thread data ...
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
Reply to
Chris Green
AnyDesk is a remote desktop viewer and doesn't do CLI.
el
--
If you want to email me, replace nospam with el
Reply to
Dr Eberhard Lisse
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
Reply to
Dr Eberhard Lisse
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
Reply to
Chris Green
Am 27.10.20 um 13:07 schrieb Dr Eberhard Lisse:
oha... ok, i was not shure about this feature.#. Thx.
Jan
Reply to
Jan Novak
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 
 Click to see the full signature
Reply to
Martin Gregorie
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?
Reply to
Björn Lundin
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
Reply to
The Natural Philosopher
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(
formatting link
Top-posting! \_^_/ >What's the most annoying thing on Usenet?
Reply to
Scott Alfter
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(
formatting link
Top-posting! \_^_/ >What's the most annoying thing on Usenet?
Reply to
Scott Alfter
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
Reply to
Martin Gregorie
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
Reply to
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
Reply to
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  
 Click to see the full signature
Reply to
The Natural Philosopher
Fair enough. Thanks to the answer.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
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 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
You have it exactly right! :-)
--
Chris Green
Reply to
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
Reply to
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
Reply to
druck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.