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 12/06/2023 23:19, Computer Nerd Kev wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 12/06/2023 00:38, 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"
>>
>> 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.
>
See Mr Kettlewell's observation. Deprecated doesn't mean obsolete, or
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. As well as man
in the middle attack reduction. Although given no one uses coaxial
ethernet on campus networks, that's pretty much a non staerter on a
local network, unless its using wifi.

--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp

On 13/06/2023 12:31, Computer Nerd Kev 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.
>
For one simple reason. Its no longer a default option. Nearly all the
distros in the last few years I have come across will have ssh by
default, but not telnet.
Not being a default means its less well documented, and marginally
harder to get working, and still requires a login password which ssh
does not.

IIRC the totally insecure passwordless option was 'rsh' ...if that's
what you want, but its the first time I typed that in two decades

--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s
agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

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?

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.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 12/06/2023 23:19, Computer Nerd Kev wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 12/06/2023 00:38, 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"
>>>
>>> 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.
>>
> See Mr Kettlewell's observation. Deprecated doesn't mean obsolete, or
> 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.

--
__ __
#_ < |\| |< _#

On 13/06/2023 14:08, Computer Nerd Kev wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 12/06/2023 23:19, Computer Nerd Kev wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 12/06/2023 00:38, 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"
>>>>
>>>> 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.
>>>
>> See Mr Kettlewell's observation. Deprecated doesn't mean obsolete, or
>> 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.
>
Ive not ever had anything go wrong with it, once set up.

--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.

Anon.

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.

Regards, Dave Hodgins

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.

--
Cheers, Carlos.

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:
>>> 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
>>
>> 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.

And once there you can type "firefox &" and get firefox, or anything else.

>
> Suppose you could give an argument like "mate-session" to get into the
> MATE GUI.

--
Cheers, Carlos.

On 13/06/2023 21:25, Carlos E.R. wrote:
> 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.
>
Incorrect. Not since switches replaced hubs.
Apart from WiFi

> There is a user/password prompt, asked by the "other" computer.
>

--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 13/06/2023 14:08, Computer Nerd Kev wrote:
>> 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.
>>
> Ive not ever had anything go wrong with it, once set up.

That's lucky for you.

No matching ciphers. No matching key algorithums. Changed host keys
causing automated tasks to fail (yes there's an option to disable
host key checking burried in the clumbsy OpenSSH docs, but one has
to think of it). SCP command failing because SCP has been disabled
for security reasons and the Dropbear client in use doesn't have
SFTP support.

I know there are good answers to all those, and I've already
followed them myself. But if it's just for connecting two computers
together via Ethernet at home, then why should one have to fix
these things when they're protecting against attacks that aren't
going to happen in that circumstance?

--
__ __
#_ < |\| |< _#

Rich <rich@example.invalid> wrote:
> 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.

Yes I know that there's an SSH and a non-SSH way to do everything
(ftpfs more than NFS for the last one). The SSH ways are much
appreciated over the internet but on a secure network they're just
a long list of extra things to go wrong. I guess the value that you
assign to that is a matter of personal opinion.

--
__ __
#_ < |\| |< _#

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:
>
> No matching ciphers. No matching key algorithums.
^^^^^^^^^^^
"algorithms", before you jump on it.

--
__ __
#_ < |\| |< _#

On Tue, 13 Jun 2023 22:30:16 +0200, Carlos E.R. wrote:
>
> 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:
>
>>>> And 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.
>> ssh -X 192.168.2.18
>> without an app should just drop you on a shell.
>
> And once there you can type "firefox &" and get firefox, or anything else.

Ah! Didn't knew that. Although it's obvious.
--
Andreas

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:
>>> 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.
>>
> Incorrect. Not since switches replaced hubs.
> 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.

>>>>> 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'd think that 'any /supported/ version' (which, I gather,
means 'Buster or newer' currently) would be a safer assumption
generally.

I'm quite surprised to learn that OP intends to use Debian 5.

> 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?)

> 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

To quote:

ID> This Internet-Draft is submitted in full conformance with the
ID> provisions of BCP 78 and BCP 79.

ID> Internet-Drafts are working documents of the Internet Engineering Task
ID> Force (IETF). Note that other groups may also distribute working
ID> documents as Internet-Drafts. The list of current Internet-Drafts is
ID> at https://datatracker.ietf.org/drafts/current/.

ID> Internet-Drafts are draft documents valid for a maximum of six months
ID> and may be updated, replaced, or obsoleted by other documents at any
ID> time. It is inappropriate to use Internet-Drafts as reference material
ID> or to cite them other than as "work in progress."

ID> This Internet-Draft will expire on 18 July 2021.

The document that contains actual IETF recommendations on the
matter would be RFC 9142, http://rfc-editor.org/rfc/rfc9142.txt .

... And my opinion is that while IETF may withdraw its past
recommendation of one feature or another, recommending against
/implementation/ of any previously documented feature would
be 'overstepping its authority,' so to say. In no small part
because it tends to lead to discussions like the present one.

> 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.

--
FSF associate member #7257 np. COMMAND.COM by Master Boot Record

On 14/06/2023 00:21, Computer Nerd Kev wrote:
> 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.
>
Indeed. As has been stated, the real reason to use ssh is not security,
but utility. Passwordless access, better control over which machine/user
can access, availability of remote shell and file transfer, better
support...

And anyone who cant set up ssh properly probably belongs on an Apple Mac...

--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential
survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.

On 14/06/2023 05:01, 24D.245 wrote:
> 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:
>>>> 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.
>>>
>> Incorrect. Not since switches replaced hubs.
>> 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 ...
>
No, you cant.

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.

--
No Apple devices were knowingly used in the preparation of this post.

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:
>>> On 13/06/2023 21:25, Carlos E.R. wrote:
>>>> 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.
>>>>
>>> Incorrect. Not since switches replaced hubs.
>>> 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 ...
>>
> No, you cant.
>
> 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, or a rogue switch can be
inserted in the cable. If someone has the intent to look into traffic,
he will.

--
Cheers, Carlos.

On 2023-06-13 15:05, Rich wrote:
> 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?
>
> 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.
Very much so, yes.

--
Cheers, Carlos.

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:
>>> On 13/06/2023 21:25, Carlos E.R. wrote:
>>>> 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.
>>>>
>>> Incorrect. Not since switches replaced hubs.
>>> 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 ...
>>
> No, you cant.
>
> 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 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 !

--
vlaho.ninja/prog

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.

[...]

>> 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.

I have taken no explicit steps to address the wireless encryption method
so I assume it is what came as a default with the router. The router
is what I received from my ISP in November 2021 so it should be recent enough.

> > 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.

> 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 ?

> 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.

By the way , is the book "Linux firewalls" by Michael Rash still
considered relevant enough ?

--
I am writing this mail to you with serious tears in my eyes and great
sorrow in my heart
An email offering me 30% of $7,200,200

On 2023-06-14 16:26, Spiros Bousbouras wrote:
> 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.

Often routers have a telnet or ssh terminal, but do not document them.

But you are forgetting the computer firewall.

--
Cheers,
Carlos E.R.