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?
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
Jan Novak <repcom@gmail.com> wrote:[...]
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.
On 27/10/2020 12:28, Chris Green wrote:
Jan Novak <repcom@gmail.com> wrote:[...]
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.
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?
AnyDesk is a remote desktop viewer and doesn't do CLI.
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.
Dr Eberhard Lisse <nospam@lisse.na> wrote:
In various places, it's not really "all in one place".
On 27/10/2020 12:28, Chris Green wrote:
Jan Novak <repcom@gmail.com> wrote:[...]
So you need to set up reverse tunnel outgoing connections from yourI might have use for something like this (for a host which I can access
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.
via AnyDesk, but not SSH, at the moment.
Where can one read up on how to do this?
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@<myhost>
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.
On Tue, 27 Oct 2020 12:34:48 +0000, Chris Green wrote:
Dr Eberhard Lisse <nospam@lisse.na> wrote:
In various places, it's not really "all in one place".
On 27/10/2020 12:28, Chris Green wrote:
Jan Novak <repcom@gmail.com> wrote:[...]
So you need to set up reverse tunnel outgoing connections from yourI might have use for something like this (for a host which I can access
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.
via AnyDesk, but not SSH, at the moment.
Where can one read up on how to do this?
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@<myhost>
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,
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 doHeck I run NFS over the internet with just access allowed from my
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.
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?
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...
In article <rn9f0q$kc6$1@dont-email.me>,
Martin Gregorie <martin@mydomain.invalid> wrote:
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?
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.
Chris,
Why not simply run sshd on the RPi?
In article <rn9fus$ags$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
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.
_/_Usenet?
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on
Martin Gregorie <martin@mydomain.invalid> wrote:
Chris,Because there's no "way in" from the outside, it's behind several layers
Why not simply run sshd on the RPi?
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.
Den 2020-10-27 kl. 16:40, skrev Martin Gregorie:
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.
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?
No port forwarding is needed, that's much of the point. The
connection goes 'back' through the standard outward ssh connection.
On Tue, 27 Oct 2020 16:25:47 +0000, Scott Alfter wrote:
In article <rn9f0q$kc6$1@dont-email.me>,
Martin Gregorie <martin@mydomain.invalid> wrote:
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?
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.
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.
In article <rn9f0q$kc6$1@dont-email.me>,
Martin Gregorie <martin@mydomain.invalid> wrote:
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?
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.
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@<myhost>
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.
So you <myhost> should always be up, right? Or is this robust enough to reconnect within reasonable time of <myhost> is down for a while?
On 27/10/2020 16:35, Scott Alfter wrote:
In article <rn9fus$ags$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
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.
I use that mostly, yes. But I leave the odd backdoor open for when I am
away from all devices that I own...
Also, if you don't already have it, set up fail2ban. It'll ban IPs that
hammer your SSH server.
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.
On 27/10/2020 17:53, The Natural Philosopher wrote:
On 27/10/2020 16:35, Scott Alfter wrote:
In article <rn9fus$ags$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
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.
Seconded.
I use that mostly, yes. But I leave the odd backdoor open for when I
am away from all devices that I own...
Also, if you don't already have it, set up fail2ban. It'll ban IPs that >>> hammer your SSH server.
A lighter weight alternative if you only have a limited set of ports
exposed to the world is sshguard.
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.
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.
I make a point of not fixing problems I don't have.
See how big your auth log can get to if you don't.
---druck
On 27-10-2020 13:34, Chris Green wrote:
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@<myhost>
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.
Ah yes, I always wanted to look into this for a Raspberry Pi I have
somewhere else behind double NAT (carrier grade NAT). Thanks!
So you <myhost> should always be up, right? Or is this robust enough to reconnect within reasonable time of <myhost> is down for a while?
On Tue, 27 Oct 2020 17:39:51 +0000
Chris Green <cl@isbd.net> wrote:
No port forwarding is needed, that's much of the point. The
connection goes 'back' through the standard outward ssh connection.
This is why places that really care about security block outgoing ssh.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Tue, 27 Oct 2020 17:39:51 +0000 Chris Green <cl@isbd.net> wrote:So use another port that isn't blocked.
No port forwarding is needed, that's much of the point. The
connection goes 'back' through the standard outward ssh connection.
This is why places that really care about security block
outgoing
ssh.
If you're really concerned about security then you don't allow *any* connections to the outside world. If you do allow connections then ssh
is likely the least of your worries! :-)
On 28/10/2020 08:22, druck wrote:
On 27/10/2020 17:53, The Natural Philosopher wrote:
On 27/10/2020 16:35, Scott Alfter wrote:
In article <rn9fus$ags$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
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.
Seconded.
I use that mostly, yes. But I leave the odd backdoor open for when I
am away from all devices that I own...
Also, if you don't already have it, set up fail2ban. It'll ban IPs
that hammer your SSH server.
A lighter weight alternative if you only have a limited set of ports
exposed to the world is sshguard.
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.
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.
I make a point of not fixing problems I don't have.
See how big your auth log can get to if you don't.
Again, there is no shortage of disk space and it gets rotated.
---druck
Den 2020-10-28 kl. 09:28, skrev A. Dumas:
So you <myhost> should always be up, right? Or is this robust enough
to reconnect within reasonable time of <myhost> is down for a while?
That is why he wrote he uses autossh
<https://linux.die.net/man/1/autossh>
It reestablished the tunnel if needed
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Tue, 27 Oct 2020 17:39:51 +0000
Chris Green <cl@isbd.net> wrote:
No port forwarding is needed, that's much of the point. The
connection goes 'back' through the standard outward ssh connection.
This is why places that really care about security block
outgoing ssh.
So use another port that isn't blocked.
If you're really concerned about security then you don't allow *any* connections to the outside world. If you do allow connections then
ssh is likely the least of your worries! :-)
On Wed, 28 Oct 2020 08:54:44 +0000, The Natural Philosopher wrote:
On 28/10/2020 08:22, druck wrote:
On 27/10/2020 17:53, The Natural Philosopher wrote:
On 27/10/2020 16:35, Scott Alfter wrote:
In article <rn9fus$ags$1@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:
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...
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.
Seconded.
I use that mostly, yes. But I leave the odd backdoor open for when I
am away from all devices that I own...
Also, if you don't already have it, set up fail2ban. It'll ban IPs >>>>> that hammer your SSH server.
A lighter weight alternative if you only have a limited set of ports
exposed to the world is sshguard.
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.
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.
I make a point of not fixing problems I don't have.
See how big your auth log can get to if you don't.
Again, there is no shortage of disk space and it gets rotated.
---druck
Failtoban effectively shuts the port, which, if the hacker is monitoring
what is happening lets him know that he cannot make any further attempts which will stop him bothering your system & move on.
This should reduce the amount of waisted traffic your network has to deal with.
it also reduces the time available for the hacker to identify any ssh exploits that may have been discovered
Security in depth.
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?
Am 27.10.20 um 16:40 schrieb Martin Gregorie:
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?
Because it is not available.
ipv4 over ipv6.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:29:23 |
| Calls: | 6,648 |
| Files: | 12,198 |
| Messages: | 5,329,988 |