Re: Authentication for telnet.
On Thu 10 Oct 2019 at 19:34:26 (+0100), Brian wrote:
> On Thu 10 Oct 2019 at 06:48:16 -0700, peter@easthope.ca wrote:
> > From: David Wright, Thu, 10 Oct 2019 00:18:34 -0500
> > > telnetd is ancient ...
I wrote "sshd is modern and secure. telnetd is ancient and insecure …"
with the two sentences in apposition in order to contrast the choices
you said you have available: "Protocols Telnet and SSH are available;…"
Maybe sometime you'd explain why you prefer telnet to ssh.
Perhaps you could also restate where you had got to in this thread.
I assumed that by 4th October you had solved your difficulty with
options like -L and -a when trying to use your telnet client, and
that you had managed to authenticate yourself: "Solved now."
But I also thought you said that you didn't want to have to type a
password: "… once a user is logged in to the system, a shell session
is opened without a password", so I indicated how you might solve
that. Does "Solved now" mean that you had done so already when
using telnet? Perhaps I missed it with the threading the way it was.
> > Recency of development is a criterion for choosing a tool. (?)
>
> I think that depends on the tool. If telnetd works for you and you are
> cognisant of its drawbacks, why not use it?
>
> > The ball-peen hammer as we know it would have been developed before 1900.
> > Might have been prior to 1800. The pneumatic hammer was developed in the
> > 1920s and '30s. ( https://en.wikipedia.org/wiki/Air_hammer_(fabrication) )
> > Therefore we should always choose the pneumatic rather than the ball-peen.
>
> I'm unsure whether the analogy works. One can always choose to pick
> holes in an analogy and neglect the essential argument. The converstion
> then revolves round a different topic rather than getting to the guts of
> any issue.
The guts of my post was avoiding the password dialogue by adding
the user's own public key to the list of authorised keys. Perhaps
I shouldn't have bothered to pose the first question. Too distracting.
> > Recency is minded but shouldn't dictate.
>
> Fair enough.
I would counter with a different analogy. Houses in Britain used to have
3-lever locks, adequate at the time. Modern 5-lever ones were expensive
and only available in more limited styles. Nowadays, better security is
required, so attractive 5-lever locks are more available, relatively
cheaper (as the market is larger), and demanded by most insurance
companies or else you're not covered.
> > > sshd is ... secure.
> >
> > This scenario is in one machine which is running shorewall. The LAN
> > has another firewall. What are the risks to the telnet protocol in
> > this case?
I don't know what your configuration or risks are, but why not go
for security in depth? I would have thought you were also more likely
to meet ssh than telnet in other situations nowadays.
> netcat (which I use very frequently) might be subject to the same
> criticisms. If I were to use it outside my LAN, I'd be inclined to
> use cryptcat.
>
> Kneejerk reactions against telnetd are not unknown. telnetd is not
> insecure; its use might be. But I think you are aware of that.
I don't understand the point you're trying to make. By telnetd, do
you just mean strictly the security of daemon program, or the
end-to-end communication via the telnet protocol? (BTW I am assuming
that by the term telnet people have meant vanilla telnet and not
something like telnet-ssl.)
Cheers,
David.
Reply to: