EISNER access will be SSH-only

[Robert A. Brooks]

Hunter Goatley posted this a bit ago to the DECUServe (EISNER) mailing list . . .



Subject: [Eisner] TELNET access will be disabled Saturday
Date: Thu, 07 Jan 2021 09:36:53 -0600
From: Hunter Goatley <***@goatley.com>
Reply-To: ***@goatley.com
To: ***@goatley.com

We've discussed it before, but TELNET to EISNER will be disabled on
Saturday, 9-JAN-2021. No actual EISNER user has logged in via TELNET
since 1-DEC-2020, but there have been thousands of attempted logins via
TELNET. I discussed this with Dale, and he agreed that the time has
finally come to kill TELNET access.

SSH will now be required to log in.

[Roy Omond]

Post by Robert A. Brooks
Hunter Goatley posted this a bit ago to the DECUServe (EISNER) mailing list . . .
...
No actual EISNER user has logged in via TELNET
since 1-DEC-2020, but there have been thousands of attempted logins via
TELNET.

That's not true. I used telnet just now, and noted the last time I
accessed EISNER (via telnet) was 24-DEC-2020.

Username: omond
Password:
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L2 on
node EISNER
Last interactive login on Thursday, 24-DEC-2020 04:48:32.75

I'll switch to ssh now.

[Hunter Goatley]

That's not true.  I used telnet just now, and noted the last time I
accessed EISNER (via telnet) was 24-DEC-2020.

Yeah, I corrected myself on EISNER, but not here. My first check was
hurriedly done, and I got the results I deserved. I went back after I
had posted that and checked again and found several TELNET users. I sent
email to all of them letting them know about the change.

[Oleg P]

Post by Robert A. Brooks
Hunter Goatley posted this a bit ago to the DECUServe (EISNER) mailing list . . .
Subject: [Eisner] TELNET access will be disabled Saturday
Date: Thu, 07 Jan 2021 09:36:53 -0600
We've discussed it before, but TELNET to EISNER will be disabled on
Saturday, 9-JAN-2021. No actual EISNER user has logged in via TELNET
since 1-DEC-2020, but there have been thousands of attempted logins via
TELNET. I discussed this with Dale, and he agreed that the time has
finally come to kill TELNET access.
SSH will now be required to log in.
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
--
-- Rob

Hello!

I've got an issue while login:

***@eisner.decus.org's password:
Permission denied, please try again.
***@eisner.decus.org's password:

[Hunter Goatley]

Post by Oleg P
Permission denied, please try again.

Hi, Oleg.

Your account had expired. I've sent you email.

[Michael Moroney]

Post by Oleg P

Post by Robert A. Brooks
SSH will now be required to log in.

Hello!
Permission denied, please try again.

A later post shows that this was an expired account, however I do wish to
point out there is a certain knob that may need tuning on SSH. What
happens is, that depending on the setting, if the password (not account)
is expired, one of two things can happen. Either SSH logins aren't
allowed at all or SSH logins are allowed and you have to go through the
usual "your password has expired" routine which forces you to change it
immediately. Telnet always allows the login/forced change. There have
been many times I have had to login via telnet just to update an expired
password. (meaning both my old and new password went through the net in
cleartext!)

[Mark Daniel]

On 10/1/21 8:00 am, Michael Moroney wrote:
8< snip 8<

Post by Michael Moroney
immediately. Telnet always allows the login/forced change. There have
been many times I have had to login via telnet just to update an expired
password. (meaning both my old and new password went through the net in
cleartext!)

+1 to all applauding the closure of this service

For any occasion requiring non-SSH acccess, I'd remind EISNER users of
DCLinabox, which provides a functional terminal session over a
TLS-secured network connection using a modern browser.

[Steven Schweda]

[...] No actual EISNER user has logged in via TELNET
since 1-DEC-2020, but there have been thousands of attempted logins via
TELNET. [...]

It won't affect me, but why not just move Telnet from port 23 onto,
say, 2023 (or almost any unpopular port), and publicize it? I allow
wrong-port Telnet access on my server, and I see about four probes/year
(none of which is an actual log-in attempt).

I don't use 22 (externally) for SSH, either. Same reason, similar
results.

[Hunter Goatley]

Post by Steven Schweda
It won't affect me, but why not just move Telnet from port 23 onto,
say, 2023 (or almost any unpopular port), and publicize it? I allow
wrong-port Telnet access on my server, and I see about four probes/year
(none of which is an actual log-in attempt).
I don't use 22 (externally) for SSH, either. Same reason, similar
results.

I agree, but it's taken this long to get everyone to agree that it's
time to kill TELNET. ;-) Actually, I see no point in allowing TELNET
access at all. Sending passwords in the clear isn't good, even for hobby
accounts users don't care about.

I may lobby to move SSH to another port for the reason you stated. I
personally haven't run SSH on port 22 for many years.

[Phillip Helbig (undress to reply)]

Post by Hunter Goatley

Post by Steven Schweda
It won't affect me, but why not just move Telnet from port 23 onto,
say, 2023 (or almost any unpopular port), and publicize it? I allow
wrong-port Telnet access on my server, and I see about four probes/year
(none of which is an actual log-in attempt).
I don't use 22 (externally) for SSH, either. Same reason, similar
results.

I agree, but it's taken this long to get everyone to agree that it's
time to kill TELNET. ;-) Actually, I see no point in allowing TELNET
access at all. Sending passwords in the clear isn't good, even for hobby
accounts users don't care about.

Some people still run telnet because SSH refuses to connect if the
cipher is too old or whatever. Of course, it would be arguably more
secure than telnet.

It might be a problem for hobbyists to have a current enough ssh to
connect to wherever they want to connect.

When using certificates, the problem is worse: if the certificate is not
recognized, then the secure protocol won't work, so people keep the
unsecure one running. Even though the connection might not be
authenticated, it is still encrypted.

I understand why one wants to have both. But saying "if you can't do it
well, you can't do it at all" is probably the main reason the insecure
protocols are still found.

[Hunter Goatley]

Post by Phillip Helbig (undress to reply)
Some people still run telnet because SSH refuses to connect if the
cipher is too old or whatever. Of course, it would be arguably more
secure than telnet.

There's a reason they become unsupported....

Post by Phillip Helbig (undress to reply)
I understand why one wants to have both. But saying "if you can't do it
well, you can't do it at all" is probably the main reason the insecure
protocols are still found.

I understand it, too. And for local access, knock yourself out. I still
use DECnet and TELNET locally. But for a public-facing system that has
been a target for bots for years, there's plenty of reason for disabling
insecure protocols.

[Stephen Hoffman]

...for a public-facing system that has been a target for bots for
years, there's plenty of reason for disabling insecure protocols.

Allowing telnet access was a bad idea years ago.

Allowing privileged users access via telnet was not helpful.

All networks are best considered hostile, with the hazards varying only
by degree.