Hi!
There's been talk about switching away from netkit-telnet and
netkit-telnetd as the default implementations for some time now,
and replacing them with the ones from inetutils, which is a maintained project and does see releases (even though with a long cadence).
This has been discussed somehow in #982253 and #987729.
These packages currently use a pair of virtual packages to denote
that they are a telnet or telnetd implementation (telnet-client and telnet-server). One problem is that currently the netkit implementations
use the generic telnet and telnetd package names, which is a clear way
to mark them as the default implementations (instead of say the other convention of naming or providing a default-foo package). Another is
that several packages depend on these generic names instead of the
virtual packages, see below for a list that would deserve a non-blocking "mass" bug filing, which I can handle as part of the switch.
The inetutils-telnet recently got support for the missing «-b» option
for compatibility with netkit-telnet.
The inetutils-telnetd and netkit-telnetd have diverging options and some conflicting ones, but after pondering about it I don't think this should
be a major issue, as the daemon does not tend to get called by users from scripts and similar. For completeness the divergences are these:
inetutils-telnetd netkit-telnetd
----------------- --------------
short and long options short options
<missing> -D (unimplemented «exercise» mode)
-D (debug modes «auth», «encr») -edebug
-S, --server-principal -S (used to set the IP TOS)
-E, --exec-login -L
-l, --linemode <missing>
-U, --reverse-lookup -N (related but not exactly the same)
Simon Josefsson (CCed), who is one of the inetutils upstream maintainers, recently adopted the netkit-telnet source package in Debian, which he'd prefer to keep around for a smoother transition period, in case users
want or need to revert back.
So, the idea would be for src:inetutils to take over the telnet and
telnetd binary packages and make them transitional packages depending
on the inetutils variants, for a smooth upgrade, and in addition also
start providing them by the inetutils-<name> packages.
The src:netkit-telnet would then switch to ship netkit-telnet and netkit-telnetd binary packages (this would ideally be uploaded to experimental first, so that once ACCEPTED it can be uploaded to sid
once we start the switch, with no missing implementation in between).
I'm inclined to do it in this order to potentially avoid two trips over
NEW, and to reduce any potential disruption period.
In the future (after the next stable release) the telnet/telnetd
packages could be switched to be pure virtual packages, taking the role
of denoting the current default implementation, instead of introducing default-<foo> variants, as that's what users are currently used to, and
it would keep working even if the depending packages below do not update their dependencies.
We'd file an override request against ftp.debian.org to get the inetutils-telnet Priority bumped to standard to match the current
telnet package (which could get then its Priority lowered to optional).
Currently inetutils and netkit have the same alternative priority
for telnet, I'd probably bump it also to 150 for inetutils to take precedence.
If there are no objections, we could probably start working on this
switch in a couple of weeks or so.
List of packages depending on telnet (but not telnet-client):
forensics-extra (Depends)
lava (Depends)
live-task-standard (Depends)
mininet (Depends)
vland (Depends)
zssh (Depends)
dish (Recommends against all current implementations)
lava-dev (Recommends)
lava-dispatcher (Recommends)
live-task-extra (Recommends)
pdudaemon (Recommends)
libtelnet-dev (Suggests)
libtelnet-utils (Suggests)
procserv (Suggests)
ser2net (Suggests)
tucnak (Suggests)
List of packages depending on telnetd (but not telnet-server):
telnetd-ssl (Conflicts)
nyancat-server (Conflicts)
Thanks,of packaging a Telnet daemon when everyone should be using SSH. Telnet
Guillem
Telnet is old, insecure and should not be used any more. What is the point
Telnet is old, insecure and should not be used any more. What is
the point of packaging a Telnet daemon when everyone should be
using SSH. Telnet Client I can see because a person may need to
connect to a router or switch that is still using telnet or hasn't
had SSH Certificates generated yet.
Telnet is old, insecure and should not be used any more. What is the point of >packaging a Telnet daemon when everyone should be using SSH. Telnet Client I >can see because a person may need to connect to a router or switch that is >still using telnet or hasn't had SSH Certificates generated yet.
On Sun, Jul 17, 2022 at 01:49:53AM -0400, Timothy M Butterworth wrote:
Telnet is old, insecure and should not be used any more. What is theI personally use telnet to connect to systems whose ssh implementations
point of
packaging a Telnet daemon when everyone should be using SSH. Telnet
Client I
can see because a person may need to connect to a router or switch
that is
still using telnet or hasn't had SSH Certificates generated yet.
are old enough that they are no longer interoperable with current ssh.
Every system will eventually become an old system, and telnet has a much better record of working over the long term than does ssh. Security
concerns have a place in determining defaults, but not in banning
software that other people find useful in a context that might not
matter to you.
I found the client-side very tolerant of ancient server-side
implementations when the right kinds of switches are passed to it
(e.g. KexAlgorithms and HostKeyAlgorithms). I have yet to be
unable to actually connect to a target - even if it means fiddling increasingly with flags.
This is getting increasingly off-topic, but you're able to get a
modern SSH client to successfully connect to an old device which
only speaks SSHv1 protocol?
"Guillem" == Guillem Jover <[email protected]> writes:
Guillem> Hi! There's been talk about switching away from"Guillem" == Guillem Jover <[email protected]> writes:
Guillem> netkit-telnet and netkit-telnetd as the default
Guillem> implementations for some time now, and replacing them with
I've reviewed your plan. Over the years I've maintained a telnet
upstream so I have some familiarity with the space even though I am no
longer involved in the telnet server universe.
I definitely think Debian should still have a telnet server, although it
is very much a niche application
Available in the archive yes, installed by default no way.
That makes this current thread mostly moot, as when not installed by
default (or a metapackage) you don't need any particular implementation
to be blessed.
There's been talk about switching away from netkit-telnet and
netkit-telnetd as the default implementations for some time now,
and replacing them with the ones from inetutils, which is a maintained project and does see releases (even though with a long cadence).
There's been talk about switching away from netkit-telnet and
netkit-telnetd as the default implementations for some time now,
and replacing them with the ones from inetutils, which is a maintained project and does see releases (even though with a long cadence).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 157:56:08 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,755 |