[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Authentication for telnet.



From: David Wright <deblis@...co.uk>
Date: Fri, 11 Oct 2019 00:12:45 -0500
> Maybe sometime you'd explain why you prefer telnet to ssh.

Several years ago ssh was about 15-20 s connecting whereas telnet 
required less than a second.  Consequently I adopted the habit of using 
telnet with a password.  Recently I wondered about skipping the 
password and posted the original question about authentication.

After the suggestion to use SSH I tried it found it not working.  
A2 was being overhauled; I won't pursue SSH until that settles.

Superimposed on the authentication story was the broken threading 
causing annoyance to me and too many others.  Ideally the syntax 
required for correct threading would be posted in the debian site.   
Otherwise one should aim to study the source for MHonArc?  In dillo, a 
click on the MHonArc link at the foot of a list page gives "Unable to 
get a local issuer certificate.  The issuer certificate of an 
untrusted certificate cannot be found."

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

The telnet viewer pops open in a few ms with no password request.

> But I also thought you said that you didn't want to have to type a
> password: ...

Correct.  

> Does "Solved now" mean that you had done so already when
> using telnet? 

Yes.  It was solved by following the pointer from Reco.
telnet -a none ...

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

I'm watching for a new release of A2 from ETHZ. When that is working, 
will look at SSH again.  If it's fast enough for routine use, will try 
the public key.

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

I had to read the Wikipedia article about lever locks.  Interesting.  
Here pin tumbler deadbolts are common in older houses.  Upscale new 
construction might favour a newer technology; I know little about 
architecture.   Why do lever locks remain popular?  Pin tumbers 
should be cheaper and more difficult to pick.

> I would have thought you were also more likely
> to meet ssh than telnet in other situations nowadays.
 
Almost all my connections to the outside are via HTTPS.  Hypothetically, 
websitewelcome.com could offer scp but I've never seen it mentioned. 

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

That was from Brian.

> By telnetd, do
> you just mean strictly the security of daemon program, or the
> end-to-end communication via the telnet protocol?

I would refer to the daemon as telnetd and client as telnet.  I guess the 
protocol should always be capitalized, Telnet, but one of Yogi Bera's 
favoured quips will apply: in theory, theory and practice are the same; 
in practice they differ.

> BTW I am assuming that by the term telnet people have meant vanilla 
> telnet and not something like telnet-ssl. 

Sensible but isn't telnet-ssl almost extinct?

Regards,                       ... P.

-- 
https://en.wikibooks.org/wiki/Medical_Machines
Tel: +1 604 670 0140            Bcc: peter at easthope. ca


Reply to: