[I wasn't sure whether this is more suited to comp.os.linux.misc
or comp.os.linux.networking ]
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach and
my questions are:
1. Which packages need to be installed on the computers ?
2. What should I enter into which configuration files for A to
only accept connections from B ?
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
[I wasn't sure whether this is more suited to comp.os.linux.misc
or comp.os.linux.networking ]
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach and
my questions are:
1. Which packages need to be installed on the computers ?
2. What should I enter into which configuration files for A to
only accept connections from B ?
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
I can read man pages but some pointers on what terms or files I
should look for would be useful.
On 11/06/2023 11:11, Spiros Bousbouras wrote:
I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
On 2023-06-11 12:47, The Natural Philosopher wrote:
On 11/06/2023 11:11, Spiros Bousbouras wrote:
You can also reduce overhead using the compression flag:I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
[I wasn't sure whether this is more suited to comp.os.linux.misc
or comp.os.linux.networking ]
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach and
my questions are:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
1. Which packages need to be installed on the computers ?
2. What should I enter into which configuration files for A to
only accept connections from B ?
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
On Sun, 11 Jun 2023 06:11:48 -0400, Spiros Bousbouras <spibou@gmail.com> wrote:
[I wasn't sure whether this is more suited to comp.os.linux.misc
or comp.os.linux.networking ]
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach and
my questions are:
For computers accessed over the internet, I use ssh with X forwarding, and within my lan where I want the program running on one computer with the gui displayed on another.
For sharing files within my lan, I use sshfs.
On 2023-06-11 12:47, The Natural Philosopher wrote:
I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
On 2023-06-11, Computer Nerd Kev wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
On Sun, 11 Jun 2023 13:34:51 +0200, Carlos E.R. wrote:
On 2023-06-11 12:47, The Natural Philosopher wrote:
I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
And add an app. Like
ssh -X username@192.168.2.18 firefox
On the other side X must be allowed. Suppose that's default though.
On 2023-06-11, Computer Nerd Kev wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
"Deprecated," but so far as I can tell, not "unsupported."
For details, refer to the Cipher and HostKeyAlgorithms options
description in ssh_config(5) and sshd_config(5).
On Sun, 11 Jun 2023 13:34:51 +0200, Carlos E.R. wrote:
On 2023-06-11 12:47, The Natural Philosopher wrote:
I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
And add an app. Like
ssh -X username@192.168.2.18 firefox
On the other side X must be allowed. Suppose that's default though.
On Sun, 11 Jun 2023 06:11:48 -0400, Spiros Bousbouras <spibou@gmail.com> wrote:[...]
[I wasn't sure whether this is more suited to comp.os.linux.misc
or comp.os.linux.networking ]
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I also use synergy. I log in on both computers and start synergy on both.
The server is the one which has the keyboard/mouse I prefer connected,
the other is the client. Both computers must be running the same version
of synergy.
Note the program synergy-gui which can be used to create config files is payware, but it's not needed as the config files can be created manually.
The actual synergy server/client programs are open source.
Creating the config file manually is a bit of a pain, but there are examples available on the net. The synergy program allows me to move the mouse to the right of my main screen to the second computer's screen. The keyboard input goes to which ever computer's screen the mouse pointer is on. The clipboard is shared, so I can copy/paste text and pictures between the two computers.
Regards, Dave Hodgins
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
On 2023-06-12, Andreas Kohlbach wrote:
On Sun, 11 Jun 2023 16:16:58 -0400, David W. Hodgins wrote:
For computers accessed over the internet, I use ssh with X
forwarding, and within my lan where I want the program running
on one computer with the gui displayed on another.
You could also use VNC or RDP. But I suppose SSH has the least
overhead, thus is fastest.
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
For this reason on my home LAN, which I know nobody is snooping
on, I avoid SSH wherever possible and use Telnet instead (usually
the GNU Inetutils implementation).
2. What should I enter into which configuration files for A to
only accept connections from B ?
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
If you want this, then you'll have to give up on the old Debian
version either now or sometime later. If you're willing to compile
newer versions of OpenSSH yourself then you might be able to delay
this for many years though. Other options are setting up a
physically secure network connection from the old Debian system to
a newer computer, using SSH to connect to the newer system, which
runs a script that connects to the older system via Telnet. The
"newer computer" might even be a virtual machine running on the old
system with the emulated network interface in Bridge mode so that
it appears as a unique IP on your LAN.
But life is much easier if you can trust that nobody is snooping on
your LAN in the first place.
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Thanks for all the replies everyone. That's a lot to read on.
Assuming I go the SSH route , I would need to make sure that the SSH daemon runs on computer A. Does installing the correct package (it seems to be openssh-server) make sure that the server gets started on boot or do I also need to edit something in the start-up scripts ?
But life is much easier if you can trust that nobody is snooping on
your LAN in the first place.
Ok , lets focus on whether I have a physically secure network connection
and whether anyone can snoop on my LAN. I'm not sure which are the
relevant factors but I will give some information which hopefully is relevant. Noone but me has physical access to the 2 computers or the
router. The wireless signal on the router is turned off most of the time
but I turn it on occasionally. I believe the password for wireless
connection to be secure. I seed some torrents from computer B so the
router accepts connections for those. As I've said , computers A and B
would be connected through cable to the router. With that in mind ,
could an attacker connect to the router and intercept communications
between A and B ? Is the attack surface greater with wireless signal on ?
To return to what you say above :
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to the router through a cable" ? Can the router itself be tricked in that
regard ? Is there no standard way for the router to pass the information
to the computer accepting connections ? Is the point to defend from bugs
in the router software ?
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to
the router through a cable" ?
Thanks for all the replies everyone. That's a lot to read on.
Assuming I go the SSH route , I would need to make sure that the SSH daemon runs on computer A. Does installing the correct package (it seems to be openssh-server) make sure that the server gets started on boot or do I also need to edit something in the start-up scripts ?
But life is much easier if you can trust that nobody is snooping on
your LAN in the first place.
Ok , lets focus on whether I have a physically secure network connection
and whether anyone can snoop on my LAN. I'm not sure which are the
relevant factors but I will give some information which hopefully is relevant. Noone but me has physical access to the 2 computers or the
router. The wireless signal on the router is turned off most of the time
but I turn it on occasionally. I believe the password for wireless
connection to be secure. I seed some torrents from computer B so the
router accepts connections for those. As I've said , computers A and B
would be connected through cable to the router. With that in mind ,
could an attacker connect to the router and intercept communications
between A and B ? Is the attack surface greater with wireless signal on ?
To return to what you say above :
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to the router through a cable" ? Can the router itself be tricked in that
regard ? Is there no standard way for the router to pass the information
to the computer accepting connections ? Is the point to defend from bugs
in the router software ?
Thanks for all the replies everyone. That's a lot to read on.
Assuming I go the SSH route , I would need to make sure that the SSH daemon runs on computer A. Does installing the correct package (it seems to be openssh-server) make sure that the server gets started on boot or do I also need to edit something in the start-up scripts ?
On 12 Jun 2023 09:38:19 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
Debian 5. If there is no incompatibility issue now then one won't arise if I don't upgrade the newer system.
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think
I'm missing your point.
If you want this, then you'll have to give up on the old Debian
version either now or sometime later. If you're willing to compile
newer versions of OpenSSH yourself then you might be able to delay
this for many years though. Other options are setting up a
physically secure network connection from the old Debian system to
a newer computer, using SSH to connect to the newer system, which
runs a script that connects to the older system via Telnet. The
"newer computer" might even be a virtual machine running on the old
system with the emulated network interface in Bridge mode so that
it appears as a unique IP on your LAN.
But life is much easier if you can trust that nobody is snooping on
your LAN in the first place.
Ok , lets focus on whether I have a physically secure network connection
and whether anyone can snoop on my LAN. I'm not sure which are the
relevant factors but I will give some information which hopefully is relevant. Noone but me has physical access to the 2 computers or the
router. The wireless signal on the router is turned off most of the time
but I turn it on occasionally. I believe the password for wireless
connection to be secure. I seed some torrents from computer B so the
router accepts connections for those. As I've said , computers A and B
would be connected through cable to the router. With that in mind ,
could an attacker connect to the router and intercept communications
between A and B ?
Is the attack surface greater with wireless signal on ?
To return to what you say above :
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to the router through a cable" ?
Can the router itself be tricked in that regard ?
Is there no standard way for the router to pass the information
to the computer accepting connections ? Is the point to defend
from bugs in the router software ?
On 12/06/2023 00:38, Computer Nerd Kev wrote:
"deprecated"
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
Like telnet is
On 2023-06-12 04:10, Andreas Kohlbach wrote:
On Sun, 11 Jun 2023 13:34:51 +0200, Carlos E.R. wrote:
And add an app. Like
On 2023-06-11 12:47, The Natural Philosopher wrote:
I am not up to day on X fowarding, so I will pass on that. I believe
that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
ssh -X username@192.168.2.18 firefox
That can be done later, typing on the terminal, if you want.
Notice, though, that firefox is "different" in this respect.
Now, I don't have any measurements to back this claim, but
note that while /classic/ X software sends short commands
to the X server (draw a line here, render a string there),
/modern/ software mostly just pushes pre-rendered pixmaps
to the server. There, VNC protocol may have an advantage,
as it's pretty much dedicated to shoving image data around,
and does not support requests such as drawing polygons on
the server, which modern software won't use anyway.
If you mostly want to use modern software (Darktable, Chromium,
Libreoffice, Merkaartor, that sort of thing) it's worth trying
VNC, which may happen to have less overhead in this case.
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older version
of Debian. I want to connect from B to A and execute shell commands
on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long you
intend to keep using it without upgrading, my recommendation would be
to not use SSH because either now or later it will be unable to
connect with the newer Devuan system because all the supported
authentication or encryption systems will be depreciated in the newer software.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 12/06/2023 00:38, Computer Nerd Kev wrote:
"deprecated"
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
Like telnet is
No it isn't. Debian even has multiple implementations to choose
from as packages, and there's no indication that they're all going
to go away any time soon.
Using it over the internet certainly isn't recommended anymore, but
that's not what was being discussed.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place? Forget falling back to Telnet, I'd
start with it and not have to worry about ciphers in the first
place.
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place?
On 12/06/2023 23:19, Computer Nerd Kev wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:See Mr Kettlewell's observation. Deprecated doesn't mean obsolete, or
On 12/06/2023 00:38, Computer Nerd Kev wrote:
Without knowing how old your old version of Debian is and how long"deprecated"
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
Like telnet is
No it isn't. Debian even has multiple implementations to choose
from as packages, and there's no indication that they're all going
to go away any time soon.
even obsolescent, it means simply 'no longer recommended'. Like cross
ply tyres.
You can still buy them, but radials are better.
Using it over the internet certainly isn't recommended anymore, but
that's not what was being discussed.
It was, the moment you said 'depreciated' when you meant 'deprecated'.
I used to run telnet on my internal network, but its no longer installed
by default and given today's CPU power ssh completely replaces its functionality, and in fact adds more, like sshfs etc etc.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 12/06/2023 23:19, Computer Nerd Kev wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:See Mr Kettlewell's observation. Deprecated doesn't mean obsolete, or
On 12/06/2023 00:38, Computer Nerd Kev wrote:
Without knowing how old your old version of Debian is and how long"deprecated"
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
Like telnet is
No it isn't. Debian even has multiple implementations to choose
from as packages, and there's no indication that they're all going
to go away any time soon.
even obsolescent, it means simply 'no longer recommended'. Like cross
ply tyres.
You can still buy them, but radials are better.
Actually I linked to an example earlier in this thread.
The IETF recommends not implementing some old key exchange
algorithms for SSH: https://datatracker.ietf.org/doc/id/draft-ietf-curdle-ssh-kex-sha2-13.html
"The purpose of this RFC is to recommend that some published key
exchanges be deprecated as well as recommending some that SHOULD
and one that MUST be adopted."
[snip]
"The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1,
gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be
implemented."
Using it over the internet certainly isn't recommended anymore, but
that's not what was being discussed.
It was, the moment you said 'depreciated' when you meant 'deprecated'.
Yes may never one of my frequent word mix-ups get past the vigilant
readers of the comp.* groups.
I used to run telnet on my internal network, but its no longer installed
by default and given today's CPU power ssh completely replaces its
functionality, and in fact adds more, like sshfs etc etc.
It's still easier for interoperability with old systems such as the
Debian 5 one that the OP wants to use. There's just lots more to go
wrong with SSH.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place? Forget falling back to Telnet, I'd
start with it and not have to worry about ciphers in the first
place.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think
I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
On Mon, 12 Jun 2023 10:53:44 +0200, Carlos E.R. wrote:
On 2023-06-12 04:10, Andreas Kohlbach wrote:
On Sun, 11 Jun 2023 13:34:51 +0200, Carlos E.R. wrote:
And add an app. Like
On 2023-06-11 12:47, The Natural Philosopher wrote:
I am not up to day on X fowarding, so I will pass on that. I believe >>>>> that too can pass over ssh.
Yes.
You do:
ssh -X username@192.168.2.18
ssh -X username@192.168.2.18 firefox
That can be done later, typing on the terminal, if you want.
Notice, though, that firefox is "different" in this respect.
ssh -X 192.168.2.18
without an app should just drop you on a shell.
Suppose you could give an argument like "mate-session" to get into the
MATE GUI.
On 2023-06-13 01:11, Computer Nerd Kev wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think
I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many aspects. Anyone with access to the LAN can see anything inside the
telnet session.
There is a user/password prompt, asked by the "other" computer.
On 13/06/2023 14:08, Computer Nerd Kev wrote:
It's still easier for interoperability with old systems such as theIve not ever had anything go wrong with it, once set up.
Debian 5 one that the OP wants to use. There's just lots more to go
wrong with SSH.
Computer Nerd Kev <not@telling.you.invalid> wrote:
It's two computers on his home network connected via Ethernet, why
use SSH in the first place?
Because:
1) In 2023, most Linux installs will have ssh installed (and often
listening for connections).
2) Using ssh public keys, it is trivial to setup passwordless login
between the local lan connected machines (I do not believe telnet ever allowed "passwordless login", that would have been rsh, which ssh
replaced long ago).
3) Using ssh provides for port forwarding between the machines (in case
one wants to do that).
4) Ssh provides scp and sftp for quick "file transfers" between the computers.
5) Ssh provides the -X and -Y "remote X" transport, which should automatically setup for running X apps remotely (i.e. he does not have
to understand how to setup DISPLAY manually nor how to allow access
locally (xhost))
6) Ssh access allows for using sshfs to "network file system" access
the other machine(s) disks, without having to setup NFS proper (much
more effort to setup than sshfs). This goes well beyond "scp and sftp"
file transfers.
On Tue, 13 Jun 2023 07:31:39 -0400, Computer Nerd Kev <not@telling.you.invalid> wrote:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place? Forget falling back to Telnet, I'd
start with it and not have to worry about ciphers in the first
place.
It's one layer of security. If one user gets hacked the other users
on that computer are slightly more protected and the systems they can
access are also more protected.
Reasonably good security practices include having many levels of security
so that one level or user getting hacked doesn't result in full lan access.
No matching ciphers. No matching key algorithums.^^^^^^^^^^^
On 2023-06-13 03:51, Andreas Kohlbach wrote:
On Mon, 12 Jun 2023 10:53:44 +0200, Carlos E.R. wrote:
On 2023-06-12 04:10, Andreas Kohlbach wrote:
ssh -X 192.168.2.18And add an app. Like
ssh -X username@192.168.2.18 firefox
That can be done later, typing on the terminal, if you want.
Notice, though, that firefox is "different" in this respect.
without an app should just drop you on a shell.
And once there you can type "firefox &" and get firefox, or anything else.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think
I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many
aspects. Anyone with access to the LAN can see anything inside the
telnet session.
Apart from WiFi
On 2023-06-12, Computer Nerd Kev wrote:
Ivan Shmakov <ivan@siamics.netnospam.invalid> wrote:
On 2023-06-11, Computer Nerd Kev wrote:
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
"Deprecated," but so far as I can tell, not "unsupported."
For details, refer to the Cipher and HostKeyAlgorithms options
description in ssh_config(5) and sshd_config(5).
Yes I answered the question in a generic sense assuming computer B
could be running _any_ older version of Debian because the version
wasn't specified.
I'm posting from Debian version 3 right now, so that makes sense
to me, but it did occur to me afterwards that the OP may have
meant an old but still supported Debian version.
The IETF recommends not implementing some old key exchange
algorithms for SSH:
https://datatracker.ietf.org/doc/id/draft-ietf-curdle-ssh-kex-sha2-13.html
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is
at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 July 2021.
But indeed up to a point you can enable many depreciated options
with the "ciphers" and "KexAlgorithms" settings in
/etc/ssh/sshd_config on "computer A".
But if you can just use Telnet happily on a secure LAN, then this
is all lots of unnecessary work
(especially because SSH isn't very helpful with its error messages,
and old versions don't support the -Q option).
On 6/13/23 6:36 PM, The Natural Philosopher wrote:
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on
B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because
"safely" probably means that you don't want plain-text passwords
and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think
I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many
aspects. Anyone with access to the LAN can see anything inside the
telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
Telnet is of the same generation as POP - a kinder
and gentler era where 'security'/encryption was
not considered a big deal (we're all pals here,
right ?). It's BEST not to use Telnet - indeed
block its port in your router.
Did have some fun lately though using Telnet to
log into a mail server, you can select an alt port.
Had to type weird stuff into prompts - but you COULD
connect/receive/send.
David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
On Tue, 13 Jun 2023 07:31:39 -0400, Computer Nerd Kev <not@telling.you.invalid> wrote:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible >>>> thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place? Forget falling back to Telnet, I'd
start with it and not have to worry about ciphers in the first
place.
It's one layer of security. If one user gets hacked the other users
on that computer are slightly more protected and the systems they can
access are also more protected.
Reasonably good security practices include having many levels of security
so that one level or user getting hacked doesn't result in full lan access.
That logic is general enough that it can be taken as far as you
want it to go. For two computers on a home network connected via
Ethernet I think the extra risk of using Telnet vs SSH is marginal
at best.
Computer Nerd Kev <not@telling.you.invalid> wrote:Very much so, yes.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The sensible
thing to do at that point is upgrade the older endpoints, rather than
falling back to telnet.
It's two computers on his home network connected via Ethernet, why
use SSH in the first place?
Because:
1) In 2023, most Linux installs will have ssh installed (and often
listening for connections).
2) Using ssh public keys, it is trivial to setup passwordless login
between the local lan connected machines (I do not believe telnet ever allowed "passwordless login", that would have been rsh, which ssh
replaced long ago).
3) Using ssh provides for port forwarding between the machines (in case
one wants to do that).
4) Ssh provides scp and sftp for quick "file transfers" between the computers.
5) Ssh provides the -X and -Y "remote X" transport, which should automatically setup for running X apps remotely (i.e. he does not have
to understand how to setup DISPLAY manually nor how to allow access
locally (xhost))
6) Ssh access allows for using sshfs to "network file system" access
the other machine(s) disks, without having to setup NFS proper (much
more effort to setup than sshfs). This goes well beyond "scp and sftp"
file transfers.
In my opinion, #2 is a significant enough of a benefit (no need to
enter a password for each remote access) that years ago when ssh first appeared (and long before there was ever an "OpenSSH") I setup ssh
among all my local lan machines and dropped telnet use entirely for
remote access. And not because I 'needed' secure connections over my
local lan (I did not, and back then the encryption load was a
significant CPU hit) but because the convience factor of not needing to
type in passwords was so huge.
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in
many aspects. Anyone with access to the LAN can see anything inside
the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many
aspects. Anyone with access to the LAN can see anything inside the
telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
Spiros Bousbouras <spibou@gmail.com> wrote:
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept connections coming from a computer which is physically connected to
the router through a cable" ?
This is typically done by setting up a firewall rule.
For your stated
"rule" above, and assuming by 'router' you actually mean one of those
boxes that is both a router and a 4-port ethernet switch combination
box,
you would add a rule to the machine's firewall to only accept
packets with a source IP of the local LAN. Which is most likely a
/24, so X.Y.Z.??? where X.Y.Z are the first three octets of your LAN's
IP address range, and ??? is anything.
The exact way to formulate and install such a rule requires more
specifics than we are cognizant of over USENET.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
As I've said , computers A and B
would be connected through cable to the router. With that in mind ,
could an attacker connect to the router and intercept communications between A and B ?
Not unless they've found an exploit that allows them to control the
router, in which case you potentially have a lot of other problems
too.
Is the attack surface greater with wireless signal on ?
Yes but if you believe that the wireless is secure then it's not an
issue. Unless you're using an old encryption method for the
wireless network.
To return to what you say above :
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or whatever) something which tells the relevant server "Only accept connections coming from a computer which is physically connected to the router through a cable" ?
You can, but it's your firewall's configuration that you need to
edit on the computer running the SSH server (or the router, as some
have suggested, but many cheap routers don't come with firewall
software).
What/how you edit depends on the firewall you're
running. If you're not running one, then pick one and this should
be a basic thing described in its documentation.
Can the router itself be tricked in that regard ?
Only if people can get onto your LAN.
In which case odds are
they'll be more interested in stealing access to your internet
connection than hacking into your old Debian machine anyway.
Is there no standard way for the router to pass the information
to the computer accepting connections ? Is the point to defend
from bugs in the router software ?
The firewall suggestion protects against potential devices on your
network that are already infected by some sort of malware. If the
router is infected then it won't help.
On 13 Jun 2023 09:11:14 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
This thread has got a lot more popular than what I expected it to be.
To return to what you say above :
With Telnet I think this would need to be done in firewall settings
on the computers or a router.
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or
whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to the
router through a cable" ?
You can, but it's your firewall's configuration that you need to
edit on the computer running the SSH server (or the router, as some
have suggested, but many cheap routers don't come with firewall
software).
I think my router has firewall functionality. But the router only has a web interface whereas I much prefer to use the command line so I'd rather do things on the computers rather on the router. Plus , computer settings can
go on my back-ups.
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only has a web interface whereas I much prefer to use the command line so I'd rather do things on the computers rather on the router. Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document them.
But you are forgetting the computer firewall.
On 2023-06-14 10:23, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in
many aspects. Anyone with access to the LAN can see anything inside
the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established
MAC addresses are used to limit propagation to only the segment where
the target machine resides. Thats what a switch *does*.
So?
The switch can put ports in mirror mode,
inserted in the cable.
he will.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many >>>>> aspects. Anyone with access to the LAN can see anything inside the
telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC
addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
That is the normal state. But an active attacker can use a MAC
flooding attack (https://en.wikipedia.org/wiki/MAC_flooding) on the
switch to try to get it to trip into unicast flooding mode, at which
point the switch degrades to a hub (all packets broadcast on all
ports).
This is likely more effective on common 4-port switches for home use
vs. on 'enterprise grade' high end managed switches.
On 14/06/2023 12:52, Rich wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>>> I'm missing your point.3. Can it be done safely without having to enter a password on >>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH. >>>>>>>>
Yeah, any secure passwordless authentication system has the same >>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many >>>>>> aspects. Anyone with access to the LAN can see anything inside the >>>>>> telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC >>> addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
That is the normal state. But an active attacker can use a MAC
flooding attack (https://en.wikipedia.org/wiki/MAC_flooding) on the
switch to try to get it to trip into unicast flooding mode, at which
point the switch degrades to a hub (all packets broadcast on all
ports).
This is likely more effective on common 4-port switches for home use
vs. on 'enterprise grade' high end managed switches.
There is no one in my house except me, and I have an ancient 24 port
switch feeding my network.
On Mon, 12 Jun 2023 17:05:50 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
Perhaps I'm asking a very naive question but why is it not enough to
enter into some configuration file (whether one for telnet or SSH or
whatever) something which tells the relevant server "Only accept
connections coming from a computer which is physically connected to
the router through a cable" ?
This is typically done by setting up a firewall rule.
I assume it's possible to set different restrictions for different internet ports , otherwise it seems like a much too crude solution.
For your stated "rule" above, and assuming by 'router' you actually
mean one of those boxes that is both a router and a 4-port ethernet
switch combination box,
Yes , that's what I mean.
you would add a rule to the machine's firewall to only accept
packets with a source IP of the local LAN. Which is most likely a
/24, so X.Y.Z.??? where X.Y.Z are the first three octets of your LAN's
IP address range, and ??? is anything.
The exact way to formulate and install such a rule requires more
specifics than we are cognizant of over USENET.
Something about your choice of words makes it sound very complicated !
On 13 Jun 2023 09:11:14 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
What/how you edit depends on the firewall you're running. If you're
not running one, then pick one and this should be a basic thing
described in its documentation.
So there are different firewall choices ? Ok , this is getting too
far from my present knowledge for me for now. So I think that for
the time being I will go with SSH *with* password and not worry about firewalls.
So with such a set up , I'm guessing that anyone will be able to try
and connect to computer A but , as long as my password is secure
enough , then it shouldn't be a problem. I'm guessing that it's
possible to configure SSH to log all attempts to log in (both
successful and not) and also have a delay after an unsuccessful
attempt.
Do I have all this right ?
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
But you are forgetting the computer firewall.
I'd still much prefer to explore the router's capabilities through
the command line rather than through a web interface.
On 14/06/2023 12:02, Carlos E.R. wrote:
On 2023-06-14 10:23, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>>> I'm missing your point.3. Can it be done safely without having to enter a password on >>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH. >>>>>>>>
Yeah, any secure passwordless authentication system has the same >>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in
many aspects. Anyone with access to the LAN can see anything
inside the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established
MAC addresses are used to limit propagation to only the segment where
the target machine resides. Thats what a switch *does*.
So?
The switch can put ports in mirror mode,
Not unless its managed and you have password access.
or a rogue switch can be
inserted in the cable.
In what cable?
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only has a web >>> interface whereas I much prefer to use the command line so I'd rather do >>> things on the computers rather on the router. Plus , computer settings can >>> go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document them.
Is there a way to find out if mine does ?
But you are forgetting the computer firewall.
I'd still much prefer to explore the router's capabilities through the command line rather than through a web interface.
Spiros Bousbouras <spibou@gmail.com> wrote:
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
Run a nmap scan against the router from one of the internal machines.
If you find it does, then you'll have to experiment with how, exactly,
to log in.
On Wed, 14 Jun 2023 16:31:04 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
Run a nmap scan against the router from one of the internal machines.
If you find it does, then you'll have to experiment with how, exactly,
to log in.
nmap 192.168.1.1
Interesting ports on 192.168.1.1:
Not shown: 1708 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open https
5000/tcp open upnp
8080/tcp open http-proxy
8443/tcp open https-alt
So I guess this means that the router is listening for SSH connections. So the idea is to experiment with logging in and , if I manage to do this , try to explore what I can do through the command line.
What do the other stuff mean ? I guess 80/tcp and 443/tcp are for
the web interface. Anyone knows or can guess what the rest is for ?
Spiros Bousbouras <spibou@gmail.com> wrote:You can supply your own router.
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
Run a nmap scan against the router from one of the internal machines.
If you find it does, then you'll have to experiment with how, exactly,
to log in.
But you are forgetting the computer firewall.
I'd still much prefer to explore the router's capabilities through
the command line rather than through a web interface.
If the router your ISP supplies does not give you a CLI interface
option, you are out of luck there with that desire.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/06/2023 12:52, Rich wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>>>> I'm missing your point.3. Can it be done safely without having to enter a password on >>>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>>>> and anything else will mean raising version incompatibility >>>>>>>>>> problems with authentication systems such as are used by SSH. >>>>>>>>>
Yeah, any secure passwordless authentication system has the same >>>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in many >>>>>>> aspects. Anyone with access to the LAN can see anything inside the >>>>>>> telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC >>>> addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
That is the normal state. But an active attacker can use a MAC
flooding attack (https://en.wikipedia.org/wiki/MAC_flooding) on the
switch to try to get it to trip into unicast flooding mode, at which
point the switch degrades to a hub (all packets broadcast on all
ports).
This is likely more effective on common 4-port switches for home use
vs. on 'enterprise grade' high end managed switches.
There is no one in my house except me, and I have an ancient 24 port
switch feeding my network.
Agreed, if you have an "active attacker" in your house, you have much
bigger problems than the possibility of overflowing the switch's mac
address lookup tables.
My point was that a switch is not always a "segment isolator". Some of
them can be tricked into degrading into hubs.
On 2023-06-14 17:26, The Natural Philosopher wrote:
On 14/06/2023 12:02, Carlos E.R. wrote:
On 2023-06-14 10:23, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
Ideally , I don't want passwords at all , as I've said. But I >>>>>>>>> think3. Can it be done safely without having to enter a password on >>>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>>>> and anything else will mean raising version incompatibility >>>>>>>>>> problems with authentication systems such as are used by SSH. >>>>>>>>>
I'm missing your point.
Yeah, any secure passwordless authentication system has the same >>>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in >>>>>>> many aspects. Anyone with access to the LAN can see anything
inside the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established
MAC addresses are used to limit propagation to only the segment
where the target machine resides. Thats what a switch *does*.
So?
The switch can put ports in mirror mode,
Not unless its managed and you have password access.
or a rogue switch can be
inserted in the cable.
In what cable?
What cable do you think it would be? :-)
Richard Kettlewell <invalid@invalid.invalid> wrote:
Eventually older ciphers do get disabled, for good reason. The
sensible thing to do at that point is upgrade the older endpoints,
rather than falling back to telnet.
It's two computers on his home network connected via Ethernet, why use
SSH in the first place? Forget falling back to Telnet, I'd start with
it and not have to worry about ciphers in the first place.
On Wed, 14 Jun 2023 16:31:04 -0000 (UTC)DNS. If you set the router to be a local DNS proxy in your DHCP
Rich <rich@example.invalid> wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
Run a nmap scan against the router from one of the internal machines.
If you find it does, then you'll have to experiment with how, exactly,
to log in.
nmap 192.168.1.1
Interesting ports on 192.168.1.1:
Not shown: 1708 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open httpGaming protocol IIRC. It is generally regarded by geeks as insecure and
443/tcp open https
5000/tcp open upnp
8080/tcp open http-proxy
8443/tcp open https-alt
So I guess this means that the router is listening for SSH connections. So the idea is to experiment with logging in and , if I manage to do this , try to explore what I can do through the command line.
What do the other stuff mean ? I guess 80/tcp and 443/tcp are for
the web interface. Anyone knows or can guess what the rest is for ?
On 2023-06-14 21:07, The Natural Philosopher wrote:
On 14/06/2023 17:46, Carlos E. R. wrote:
On 2023-06-14 17:26, The Natural Philosopher wrote:I have no idea. All my cables are buried in the walls.
On 14/06/2023 12:02, Carlos E.R. wrote:
On 2023-06-14 10:23, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:...
Thanks for all the replies everyone. That's a lot to read on. >>>>>>>>>
Ideally , I don't want passwords at all , as I've said. But I >>>>>>>>>>> think3. Can it be done safely without having to enter a password on >>>>>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you >>>>>>>>>>>> because
"safely" probably means that you don't want plain-text >>>>>>>>>>>> passwords
and anything else will mean raising version incompatibility >>>>>>>>>>>> problems with authentication systems such as are used by SSH. >>>>>>>>>>>
I'm missing your point.
Yeah, any secure passwordless authentication system has the same >>>>>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe" >>>>>>>>>> against all attacks. Probably safe against any attacks that >>>>>>>>>> you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe >>>>>>>>> in many aspects. Anyone with access to the LAN can see anything >>>>>>>>> inside the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once
established MAC addresses are used to limit propagation to only
the segment where the target machine resides. Thats what a switch
*does*.
So?
The switch can put ports in mirror mode,
Not unless its managed and you have password access.
or a rogue switch can be
inserted in the cable.
In what cable?
What cable do you think it would be? :-)
Mine aren't.
Except where they emerge and go into my computers. And I would notice
in 5 seconds if they had a switch dangling off them.
I wouldn't, I don't inspect the 50 metres every day. There is furniture
in the way.
I mean, aliens could land and probe my brain, do you think I need a
firewall for that, too?
An aluminum foil hat is said to help :-D
On 14/06/2023 17:31, Rich wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:You can supply your own router.
On Wed, 14 Jun 2023 16:34:52 +0200
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2023-06-14 16:26, Spiros Bousbouras wrote:
I think my router has firewall functionality. But the router only
has a web interface whereas I much prefer to use the command line
so I'd rather do things on the computers rather on the router.
Plus , computer settings can go on my back-ups.
Often routers have a telnet or ssh terminal, but do not document
them.
Is there a way to find out if mine does ?
Run a nmap scan against the router from one of the internal machines.
If you find it does, then you'll have to experiment with how, exactly,
to log in.
But you are forgetting the computer firewall.
I'd still much prefer to explore the router's capabilities through
the command line rather than through a web interface.
If the router your ISP supplies does not give you a CLI interface
option, you are out of luck there with that desire.
However the default situation is that unless you specifically enable
port forwarding there will be none, and inbound access from the
internet to machines behind the router will be blocked.
Why you don't want to use the routers web interface is beyond me.
their CLI interfaces are out of the ark usually. I only use mine
because there is one piece of data I cant get out of it using snmp
On 14/06/2023 17:46, Carlos E. R. wrote:
On 2023-06-14 17:26, The Natural Philosopher wrote:I have no idea. All my cables are buried in the walls.
On 14/06/2023 12:02, Carlos E.R. wrote:
On 2023-06-14 10:23, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:So?
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:...
Thanks for all the replies everyone. That's a lot to read on. >>>>>>>>
Ideally , I don't want passwords at all , as I've said. But I >>>>>>>>>> think3. Can it be done safely without having to enter a password on >>>>>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>>>>> and anything else will mean raising version incompatibility >>>>>>>>>>> problems with authentication systems such as are used by SSH. >>>>>>>>>>
I'm missing your point.
Yeah, any secure passwordless authentication system has the same >>>>>>>>> issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A >>>>>>>>> over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe" >>>>>>>>> against all attacks. Probably safe against any attacks that you're >>>>>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in >>>>>>>> many aspects. Anyone with access to the LAN can see anything
inside the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once
established MAC addresses are used to limit propagation to only the
segment where the target machine resides. Thats what a switch *does*. >>>>
The switch can put ports in mirror mode,
Not unless its managed and you have password access.
or a rogue switch can be
inserted in the cable.
In what cable?
What cable do you think it would be? :-)
Except where they emerge and go into my computers. And I would notice in
5 seconds if they had a switch dangling off them.
I mean, aliens could land and probe my brain, do you think I need a
firewall for that, too?
Is there anything in it worth stealing?
On 13 Jun 2023 09:11:14 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
What/how you edit depends on the firewall you're
running. If you're not running one, then pick one and this should
be a basic thing described in its documentation.
So there are different firewall choices ? Ok , this is getting too far from my present knowledge for me for now. So I think that for the time being I will go with SSH *with* password and not worry about firewalls.
So with such a set up , I'm guessing that anyone will be able to try
and connect to computer A but , as long as my password is secure enough , then it shouldn't be a problem. I'm guessing that it's possible to
configure SSH to log all attempts to log in (both successful and not)
and also have a delay after an unsuccessful attempt.
Do I have all this right ?
At least , it will be somewhat interesting to see how many random attempts
I get of people trying to log in to the computer.
Can the router itself be tricked in that regard ?
Only if people can get onto your LAN.
You mean physically get onto the LAN ?
The firewall suggestion protects against potential devices on your
network that are already infected by some sort of malware. If the
router is infected then it won't help.
By the way , is the book "Linux firewalls" by Michael Rash still
considered relevant enough ?
On 2023-06-12, Computer Nerd Kev wrote:
I'm posting from Debian version 3 right now, so that makes sense
to me, but it did occur to me afterwards that the OP may have
meant an old but still supported Debian version.
While I'm no stranger to running unmaintained software (or
versions thereof) myself, I'm curious what could be the reason
to run a no longer supported version of Debian specifically?
(With i686 in User-Agent:, I'd venture to guess it's not a
matter of having hardware no longer supported by Debian?)
But indeed up to a point you can enable many depreciated options
with the "ciphers" and "KexAlgorithms" settings in
/etc/ssh/sshd_config on "computer A".
But if you can just use Telnet happily on a secure LAN, then this
is all lots of unnecessary work
Not everyone of us can quite 'afford' a secure LAN. Some of
us use 'insecure' computers, be that Windows laptops, Android
TVs, or Wi-Fi-connected smartphones; or have family members
who use those. And while it /might/ be 'physically' possible
to have two LANs, one secure and one not, such a solution
increases maintenance burden.
More to the point is that Telnet is a poor substitute for the
'remote shell' function. I have scripts that will run
ssh -- REMOTE COMMAND for a given REMOTE, and I'd rather not
specialcase 'REMOTE is on secure LAN' vs. 'REMOTE is Internet.'
I have scripts where REMOTE = HOSTNAME is specialcased, though.
There, COMMAND would be passed to sh -c instead.
I use 'remote shell' for running all sorts of commands remotely.
I will $ ssh -- REMOTE tar --lzip -c -- . > REMOTE-backup.tar.lz
one day, and I will $ ssh -- REMOTE mpg123 -q -- - < FILE.mp3
another. (Or, rather, I will run a script that runs $MPG123
with MPG123="ssh -- REMOTE mpg123" set in its environment.)
And of course I use Rsync over SSH extensively, be that for
backups or for pushing new versions of ~/.bashrc et al. from
my primary box to every other *nix home directory I have.
I suppose with some 'necessary work' I can do the things
above with Telnet as well, but I'd think that by that point,
resurrecting RSH would be a more straightforward solution.
(especially because SSH isn't very helpful with its error messages,
and old versions don't support the -Q option).
Well, cannot quite argue with that. If anything, I haven't yet
figured out how to connect to my OpenSSH instances with SSH2DOS.
On 14/06/2023 21:27, Carlos E. R. wrote:
On 2023-06-14 21:07, The Natural Philosopher wrote:
It's 'aluminium' over here.
I mean, aliens could land and probe my brain, do you think I need a
firewall for that, too?
An aluminum foil hat is said to help :-D
And I suspect it would help just as much as configuring my computer to
reject addresses from some random Internet routing block when they cant
get past the NAT router anyway.
On 2023-06-14 22:51, The Natural Philosopher wrote:
On 14/06/2023 21:27, Carlos E. R. wrote:
On 2023-06-14 21:07, The Natural Philosopher wrote:
...
It's 'aluminium' over here.
I mean, aliens could land and probe my brain, do you think I need a
firewall for that, too?
An aluminum foil hat is said to help :-D
The spell checker says 'aluminium' is wrong :-p
Spiros Bousbouras <spibou@gmail.com> wrote:
On 13 Jun 2023 09:11:14 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
So with such a set up , I'm guessing that anyone will be able to try
and connect to computer A but , as long as my password is secure enough , then it shouldn't be a problem. I'm guessing that it's possible to configure SSH to log all attempts to log in (both successful and not)
and also have a delay after an unsuccessful attempt.
Do I have all this right ?
Sure. The log-in retry delay is default.
At least , it will be somewhat interesting to see how many random attempts I get of people trying to log in to the computer.
Unless you've set up port forwarding to the internet for computer A
then I don't think you'll ever see anyone but yourself trying to
log in.
Can the router itself be tricked in that regard ?
Only if people can get onto your LAN.
You mean physically get onto the LAN ?
I mean be able to connect to your router via Ethernet or WiFi.
Physical access is obviously required for Ethernet. WiFi should be
OK if the encryption is, or nobody else is ever anywhere within
range.
By the way , is the book "Linux firewalls" by Michael Rash still
considered relevant enough ?
You don't need a book.
ufw seems popular for Debian/Devuan and should be set up to do what
you want with just a few short commands: https://wiki.debian.org/Uncomplicated%20Firewall%20%28ufw%29
On 14/06/2023 17:31, Rich wrote:
If the router your ISP supplies does not give you a CLI interface
option, you are out of luck there with that desire.
You can supply your own router.
However the default situation is that unless you specifically enable
port forwarding there will be none, and inbound access from the internet
to machines behind the router will be blocked.
If you are excessively paranoid you can configure sshd to only respond
to local IP addresses only, which is another layer of (effective)
firewall,
and for a third you can setup a linux firewall as well, to do
the same.
Why you don't want to use the routers web interface is beyond me. their
CLI interfaces are out of the ark usually. I only use mine because there
is one piece of data I cant get out of it using snmp
On 15 Jun 2023 09:04:58 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
At least , it will be somewhat interesting to see how many random attempts >>> I get of people trying to log in to the computer.
Unless you've set up port forwarding to the internet for computer A
then I don't think you'll ever see anyone but yourself trying to
log in.
Still , I can get SSH to log them , yes ?
On 14/06/2023 19:16, Spiros Bousbouras wrote:
On Wed, 14 Jun 2023 16:31:04 -0000 (UTC)DNS. If you set the router to be a local DNS proxy in your DHCP configuration, yiour local lAN machines will use this port to do DNS queries
nmap 192.168.1.1
Interesting ports on 192.168.1.1:
Not shown: 1708 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open httpGaming protocol IIRC. It is generally regarded by geeks as insecure and
443/tcp open https
5000/tcp open upnp
a security risk, and by many other people as indispensable to run peer
to peer games over. It allows applications to open up port forwarding to themselves so other people can connect to them from the internet.
Ive got it enabled. I cant even remember why I needed to
8080/tcp open http-proxy
Web proxy server. Probably completely useless.
8443/tcp open https-alt
Probably an alternative to port 80 for the management web server in case
you want to redirect port 80 to an internal web server on your LAN
So I guess this means that the router is listening for SSH connections. So the idea is to experiment with logging in and , if I manage to do this , try
to explore what I can do through the command line.
Generally typing a question mark is a good place to start. Most of these routers run a stripped down linux with busybox on them as a shell
Maybe -- or maybe not -- it depends upon the configuration of the box
you are referring to as "the router".
If it is a typical ISP provided combo box
Note that "IP address of 10.0.0.X" is not 100% identical to "only
connected to router by cable" as there is no mechanism at the
networking layer for IP packets to know they are traversing cables
"only connected to the router". So doing your actual ask is
impossible. But denying any source IP other than the IP range used for
the local LAN is the closest possibility.
On Wed, 14 Jun 2023 16:18:51 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Note that "IP address of 10.0.0.X" is not 100% identical to "only
connected to router by cable" as there is no mechanism at the
networking layer for IP packets to know they are traversing cables
"only connected to the router". So doing your actual ask is
impossible. But denying any source IP other than the IP range used for
the local LAN is the closest possibility.
Let me ask something for my general education. The router can know whether some packets came from the part of its hardware which deals with WiFi as opposed to ethernet ports. So would it be possible to have a router based firewall which has different restrictions for WiFi accesses vs ethernet accesses ?
On 15 Jun 2023 09:04:58 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
Spiros Bousbouras <spibou@gmail.com> wrote:
On 13 Jun 2023 09:11:14 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
So with such a set up , I'm guessing that anyone will be able to try
and connect to computer A but , as long as my password is secure enough , >> > then it shouldn't be a problem. I'm guessing that it's possible to
configure SSH to log all attempts to log in (both successful and not)
and also have a delay after an unsuccessful attempt.
Do I have all this right ?
Sure. The log-in retry delay is default.
At least , it will be somewhat interesting to see how many random attempts >> > I get of people trying to log in to the computer.
Unless you've set up port forwarding to the internet for computer A
then I don't think you'll ever see anyone but yourself trying to
log in.
Still , I can get SSH to log them , yes ?
Can the router itself be tricked in that regard ?
Only if people can get onto your LAN.
You mean physically get onto the LAN ?
I mean be able to connect to your router via Ethernet or WiFi.
Physical access is obviously required for Ethernet. WiFi should be
OK if the encryption is, or nobody else is ever anywhere within
range.
Since the router is recent enough , hopefully encryption is ok.
I see plenty
of (not my) signals on wireless devices so I assume that other
people can see my wireless signal when it's on.
By the way , is the book "Linux firewalls" by Michael Rash still
considered relevant enough ?
You don't need a book.
I want it for general knowledge too. Every time I see networks discussion online , there are many terms I'm not familiar with and I don't seem to
learn this stuff by osmosis either. So I want a more systematic approach.
Spiros Bousbouras <spibou@gmail.com> wrote:
On Wed, 14 Jun 2023 16:18:51 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Note that "IP address of 10.0.0.X" is not 100% identical to "only
connected to router by cable" as there is no mechanism at the
networking layer for IP packets to know they are traversing cables
"only connected to the router". So doing your actual ask is
impossible. But denying any source IP other than the IP range used for
the local LAN is the closest possibility.
Let me ask something for my general education. The router can know whether >> some packets came from the part of its hardware which deals with WiFi as
opposed to ethernet ports. So would it be possible to have a router based
firewall which has different restrictions for WiFi accesses vs ethernet
accesses ?
Assuming a /typical/ setup, the WiFi would be a separate network
interface (i.e., wlan0 instead of eth0) and therefore you can filter
(at least with Linux's firewall) based on the network interface the
packet arrived on, or is going towards.
If the WiFi assigned IP addresses are separate from the wired ethernet addresses, then you can also filter on the IP addresses (as source, destination, or both).
If WiFi shares a common pool of IP addresses with wired, and a given IP
might be handed out to WiFi one day, and a wired device the next, then filtering on IP would not work (as the IP would not say where the
packet came from or is going to).
As to what capabilities might be exposed by the firmware in your ISP's router, none of us know. But it is a reasonable assumption to state
that what the firmware might expose is likely only a small subset of
what the full Linux firewall can perform.
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're
likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in
many aspects. Anyone with access to the LAN can see anything inside
the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
BTDTGTTS
You can only see broadcast traffic on other segments.
That might tell you a connection is being made, but once established MAC addresses are used to limit propagation to only the segment where the
target machine resides. Thats what a switch *does*.
Telnet is of the same generation as POP - a kinder
and gentler era where 'security'/encryption was
not considered a big deal (we're all pals here,
right ?). It's BEST not to use Telnet - indeed
block its port in your router.
Did have some fun lately though using Telnet to
log into a mail server, you can select an alt port.
Had to type weird stuff into prompts - but you COULD
connect/receive/send.
Been doing that for years.
And I still use POP to download my mail from my internet based server.
Old school. Only this networks IP address can do that.
On Wed, 14 Jun 2023 16:18:51 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Note that "IP address of 10.0.0.X" is not 100% identical to "only
connected to router by cable" as there is no mechanism at the
networking layer for IP packets to know they are traversing cables
"only connected to the router". So doing your actual ask is
impossible. But denying any source IP other than the IP range used for
the local LAN is the closest possibility.
Let me ask something for my general education. The router can know whether some packets came from the part of its hardware which deals with WiFi as opposed to ethernet ports. So would it be possible to have a router based firewall which has different restrictions for WiFi accesses vs ethernet accesses ?
On 6/14/23 4:23 AM, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
On 6/13/23 6:36 PM, The Natural Philosopher wrote:No, you cant.
On 13/06/2023 21:25, Carlos E.R. wrote:
On 2023-06-13 01:11, Computer Nerd Kev wrote:Incorrect. Not since switches replaced hubs.
Spiros Bousbouras <spibou@gmail.com> wrote:
Thanks for all the replies everyone. That's a lot to read on.
...
3. Can it be done safely without having to enter a password on >>>>>>>>> B when I want to connect to A ?
If you care about this then perhaps Telnet isn't for you because >>>>>>>> "safely" probably means that you don't want plain-text passwords >>>>>>>> and anything else will mean raising version incompatibility
problems with authentication systems such as are used by SSH.
Ideally , I don't want passwords at all , as I've said. But I think >>>>>>> I'm missing your point.
Yeah, any secure passwordless authentication system has the same
issues as SSH. Telnet itself only supports not having any
authentication, or passwords. If only computer B can connect to A
over Telnet due to firewall settings then going without
authentication should be OK, but it's not necessarily "safe"
against all attacks. Probably safe against any attacks that you're >>>>>> likely to experience in many cases though.
Telnet is an ancient protocol, and is considered to be unsafe in
many aspects. Anyone with access to the LAN can see anything inside
the telnet session.
Apart from WiFi
Mostly correct ... but you can still poll addresses
looking for Telnet activity and then go from there.
Switches don't/can't hide EVERYTHING ... there are
numerous utilities that can still see a LOT going
on in the local network. Try WireShark ...
Did it last Thursday.
Switches do NOT hide all activity not directed
to your specific PCs IP.
They do REDUCE it a bit though. I kept a traditional
HUB I can put right after the router to monitor ALL
activity, just in case. Has a big label saying "NEVER
THROW THIS AWAY" :-)
BTDTGTTS
You can only see broadcast traffic on other segments.
But most places only have ONE segment ...
Did have some fun lately though using Telnet to
log into a mail server, you can select an alt port.
Had to type weird stuff into prompts - but you COULD
connect/receive/send.
Been doing that for years.
Not exactly "user friendly" though ...
And I still use POP to download my mail from my internet based server.
Old school. Only this networks IP address can do that.
Try POP ... or even IMAP ... with M$ mail servers.
Last week they CUT THAT OFF. Only OAuth2 connections
still work. Thunderbird can do it, but not everything.
Mostly they want to force you to their online version
of Outlook ... my guess is that it spies on all your
other activity ....... more $$$ for M$
OK .. face the awful awful Truth - THERE IS NO REAL
"Protection". There are a zillion ways to tap your
traffic, sneak into your boxes, trick your users. It's
TOO MANY to cope with. Your best defense is obscurity,
being beneath notice, having nothing of value.
All the "wonderful" stuff you can do with modern networking
comes at a PRICE. It's all deep, Deep, DEEP - endless hooks
for evil-doers. M$ is so fucked up that it makes things
even EASIER for the bastards - stick to Linux/Unix as much
as you can.
On Wed, 14 Jun 2023 16:18:51 -0000 (UTC)
Rich <rich@example.invalid> wrote:
Note that "IP address of 10.0.0.X" is not 100% identical to "only
connected to router by cable" as there is no mechanism at the
networking layer for IP packets to know they are traversing cables
"only connected to the router". So doing your actual ask is
impossible. But denying any source IP other than the IP range used for
the local LAN is the closest possibility.
Let me ask something for my general education. The router can know whether some packets came from the part of its hardware which deals with WiFi as opposed to ethernet ports. So would it be possible to have a router based firewall which has different restrictions for WiFi accesses vs ethernet accesses ?
On 6/14/23 4:23 AM, The Natural Philosopher wrote:
On 14/06/2023 05:01, 24D.245 wrote:
And I still use POP to download my mail from my internet based server.
Old school. Only this networks IP address can do that.
Try POP ... or even IMAP ... with M$ mail servers.
Last week they CUT THAT OFF. Only OAuth2 connections
still work. Thunderbird can do it, but not everything.
Mostly they want to force you to their online version
of Outlook ... my guess is that it spies on all your
other activity ....... more $$$ for M$
On Wed, 14 Jun 2023 20:04:58 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 14/06/2023 17:31, Rich wrote:
If the router your ISP supplies does not give you a CLI interface
option, you are out of luck there with that desire.
Why you don't want to use the routers web interface is beyond me. their
CLI interfaces are out of the ark usually. I only use mine because there
is one piece of data I cant get out of it using snmp
In general , I prefer CLIs than <point and click>. For one thing , with a
CLI I can automatically record all the exchanges so that I will know in
the future what I did but with a <point and click> interface I would have
to keep notes ; something like ,
I chose menu ABC and from that submenu DEF and changed option 2 from
X to Y.
It's extra work and boring work to boot. Apart from that , my router not only seems to offer only a web interface but it requires javascript too for the login screen to function. I don't like complexity for the sake of complexity and obviously you don't need javascript to type a username and password. In addition , I normally do almost all my browsing using a text based browser. So instead I have to start a graphical browser just to inspect and possibly change some stupid router settings. I don't like to be made to jump through hoops and this whole thing very much makes me jump through hoops and I resent that.
Try POP ... or even IMAP ... with M$ mail servers.
Last week they CUT THAT OFF. Only OAuth2 connections
still work.
Thunderbird can do it, but not everything.
Mostly they want to force you to their online version
of Outlook ... my guess is that it spies on all your
other activity ....... more $$$ for M$
24D.245 wrote:
Try POP ... or even IMAP ... with M$ mail servers.
Last week they CUT THAT OFF. Only OAuth2 connections
still work.
That's been the direction of travel for gmail, outlook, 365 over the
last couple of years, IME thunderbird handles oAuth2 just fine.
Thunderbird can do it, but not everything.
Mostly they want to force you to their online version
of Outlook ... my guess is that it spies on all your
other activity ....... more $$$ for M$
On 16/06/2023 06:33, 24D.245 wrote:
OK .. face the awful awful Truth - THERE IS NO REALOh dear, the ArtStudent™ mind with its Boolean Logic Only mentailitry
"Protection". There are a zillion ways to tap your
traffic, sneak into your boxes, trick your users. It's
TOO MANY to cope with. Your best defense is obscurity,
being beneath notice, having nothing of value.
rears its ugly head...
Its not a matter of whether something *is* secure, its a matter of
*how* secure it is, but to assess that require Intelligence and Thinking
- qualities absolutely abhorrent to the modern social mind , as they
smell strongly of elitism, and probably Imperialism if not even Racism.
Today, you must be a good liitle child and believe in and do exactly
what you are told, or you will be cancelled.
On 6/16/23 2:57 AM, The Natural Philosopher wrote:
On 16/06/2023 06:33, 24D.245 wrote:
OK .. face the awful awful Truth - THERE IS NO REALOh dear, the ArtStudent™ mind with its Boolean Logic Only mentailitry
"Protection". There are a zillion ways to tap your
traffic, sneak into your boxes, trick your users. It's
TOO MANY to cope with. Your best defense is obscurity,
being beneath notice, having nothing of value.
rears its ugly head...
Sorry, was never good at 'art' :-)
And that was hardly boolean logic - just notice that
'security', esp computer security, is always a
dangerous illusion.
a lot of factors which influence your color.
Its not a matter of whether something *is* secure, its a matter of
*how* secure it is, but to assess that require Intelligence and
Thinking - qualities absolutely abhorrent to the modern social mind ,
as they smell strongly of elitism, and probably Imperialism if not
even Racism.
Today, you must be a good liitle child and believe in and do exactly
what you are told, or you will be cancelled.
News story yesterday - Amazon thought some guy said something
'racist' to a delivery guy and completely shut down his
Amazon-driven "smart"-home :-)
https://www.msn.com/en-us/news/technology/amazon-shuts-down-customer-s-smart-home-devices-after-delivery-driver-s-false-racism-claim/ar-AA1cBxsE
The STATE may have to give you (mostly) free speech, but
INDUSTRY is under no such obligation.
Spiros Bousbouras <spibou@gmail.com> wrote:
I have 2 Linux computers connected to the same router through
ethernet cables. Computer A runs Devuan , computer B an older
version of Debian. I want to connect from B to A and execute
shell commands on A. X11 forwarding would be a plus.
I assume that something SSH related is the right approach
Without knowing how old your old version of Debian is and how long
you intend to keep using it without upgrading, my recommendation
would be to not use SSH because either now or later it will be
unable to connect with the newer Devuan system because all the
supported authentication or encryption systems will be depreciated
in the newer software.
I had that problem recently connecting from Arch Linux to a 5 years old
LEDE router (BusyBox 1.25), which IIRC uses dropbear instead of OpenSSH.
It was quite hard to guess the right options to make the connection,
and the SSH documentation does not make it easy, but at the end I was
able to connect with
ssh -o"HostKeyAlgorithms=+ssh-rsa" \
root@192.168.1.1 "${@}"
I've had the same trouble the other way 'round with a non-OpenSSH
client failing to connect to a recent OpenSSH server
(with an error implying a problem with my public key,
rather than with the hash algorithm)
And once there you can type "firefox &" and get firefox, or anything else.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 304 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:54:05 |
| Calls: | 6,820 |
| Files: | 12,335 |
| Messages: | 5,407,120 |