Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264104 > unrolled thread

Telnet

Back to article view | Back to linux.debian.user

Contents

  Telnet William Torrez Corea <willitc9888@gmail.com> - 2023-12-02 17:00 +0100
    Re: Telnet Marco Moock <mm@dorfdsl.de> - 2023-12-02 17:10 +0100
      Re: Telnet Greg Wooledge <greg@wooledge.org> - 2023-12-02 17:20 +0100
      Re: Telnet William Torrez Corea <willitc9888@gmail.com> - 2023-12-02 17:40 +0100
    Re: Telnet Andy Smith <andy@strugglers.net> - 2023-12-02 23:00 +0100
      Re: Telnet Michel Verdier <mv524@free.fr> - 2023-12-03 12:10 +0100
        Re: Telnet Marco Moock <mm@dorfdsl.de> - 2023-12-03 17:10 +0100
          Re: Telnet Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 20:00 +0100
            Re: Telnet Greg Wooledge <greg@wooledge.org> - 2023-12-03 20:10 +0100
              Re: Telnet Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 20:30 +0100
                Re: Telnet debian-user@howorth.org.uk - 2023-12-03 21:30 +0100
                  Re: Telnet Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-04 11:30 +0100
                    Re: Telnet gene heskett <gheskett@shentel.net> - 2023-12-04 12:40 +0100
                      Re: Telnet debian-user@howorth.org.uk - 2023-12-04 17:20 +0100
                        Re: Telnet Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-05 11:20 +0100
              Re: Telnet Tim Woodall <debianuser@woodall.me.uk> - 2023-12-04 11:40 +0100
                Re: Firefox, was: Telnet Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-12-04 13:10 +0100
                  Re: Firefox, was: Telnet Tim Woodall <debianuser@woodall.me.uk> - 2023-12-04 15:30 +0100
            Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 09:30 +0100
              Re: Telnet Marco Moock <mm@dorfdsl.de> - 2023-12-04 17:30 +0100
                Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 17:40 +0100
            Re: Telnet Marco Moock <mm@dorfdsl.de> - 2023-12-04 09:30 +0100
              Re: Telnet Curt <curty@free.fr> - 2023-12-04 17:30 +0100
                Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 17:40 +0100
                  Re: Telnet Curt <curty@free.fr> - 2023-12-04 17:50 +0100
                    Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 18:00 +0100
                  Re: Telnet <tomas@tuxteam.de> - 2023-12-04 18:40 +0100
                    Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 20:10 +0100
                      Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 20:30 +0100
                        Re: Telnet <tomas@tuxteam.de> - 2023-12-05 06:10 +0100
                          Re: Telnet Nicolas George <george@nsup.org> - 2023-12-05 08:50 +0100
                      Re: Telnet tomas@tuxteam.de - 2023-12-04 20:30 +0100
            Re: Telnet Nicolas George <george@nsup.org> - 2023-12-04 09:30 +0100
              Re: Telnet Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-04 17:20 +0100
              Look, ma no telnet [was: Telnet] <tomas@tuxteam.de> - 2023-12-04 20:00 +0100
                Re: Look, ma no telnet [was: Telnet] <tomas@tuxteam.de> - 2023-12-04 20:10 +0100
                Re: Look, ma no telnet [was: Telnet] Nicolas George <george@nsup.org> - 2023-12-04 20:10 +0100

Page 1 of 2  [1] 2  Next page →

#264104 — Telnet

[Multipart message — attachments visible in raw view] — view raw

My telnet not operate, try connect my laptop by means of telnet:

sudo telnet 192.168.1.1
> Trying 192.168.1.1...
> Connected to 192.168.1.1.
> Escape character is '^]'.
>
> Telnet connection from 192.168.1.5:55670 refused.
>
> Your IP address has been logged and reported.
>
>
> Your telnet session has expired due to inactivity...
> Connection closed by foreign host.
>


What happened?

-- 

With kindest regards, William.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [next] | [standalone]

#264106

Am 02.12.2023 um 09:50:00 Uhr schrieb William Torrez Corea:

> sudo telnet 192.168.1.1
> > Trying 192.168.1.1...
> > Connected to 192.168.1.1.
> > Escape character is '^]'.

That means that the telnet connection was successful

> > Telnet connection from 192.168.1.5:55670 refused.

That means that the remote system closed it.
Check the syslog/journalctl and check how telnet is implemented.
Are tcp-wrappers in inetd used?

Show you inetd config and 
cat /etc/hosts.allow
cat /etc/hosts.deny

[toc] | [prev] | [next] | [standalone]

#264107

On Sat, Dec 02, 2023 at 05:01:37PM +0100, Marco Moock wrote:
> Am 02.12.2023 um 09:50:00 Uhr schrieb William Torrez Corea:
> 
> > sudo telnet 192.168.1.1

Also, just for the record, there is *no* need to use sudo here.

[toc] | [prev] | [next] | [standalone]

#264110

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 2, 2023 at 10:02 AM Marco Moock <mm@dorfdsl.de> wrote:

> Am 02.12.2023 um 09:50:00 Uhr schrieb William Torrez Corea:
>
> > sudo telnet 192.168.1.1
> > > Trying 192.168.1.1...
> > > Connected to 192.168.1.1.
> > > Escape character is '^]'.
>
> That means that the telnet connection was successful
>
> > > Telnet connection from 192.168.1.5:55670 refused.
>
> That means that the remote system closed it.
> Check the syslog/journalctl and check how telnet is implemented.
> Are tcp-wrappers in inetd used?
>
> Show you inetd config and
> cat /etc/hosts.allow
> cat /etc/hosts.deny
>
>
*cat /etc/hosts.allow*

# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and
hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#

*cat /etc/hosts.deny*

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the
system.
#                  See the manual pages hosts_access(5) and
hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID




-- 

With kindest regards, William.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#264123

Hello,

On Sat, Dec 02, 2023 at 09:50:00AM -0600, William Torrez Corea wrote:
> My telnet not operate, try connect my laptop by means of telnet:

Can someone examine the list's configuration? This email from 1994
seems to have only just been delivered.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#264146

On 2023-12-02, Andy Smith wrote:

> Can someone examine the list's configuration? This email from 1994
> seems to have only just been delivered.

How do you find 1994? It seems to be a mail from yesterday:

Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (not verified))
	by bendel.debian.org (Postfix) with ESMTPS id 55BA920B9F
	for <debian-user@lists.debian.org>; Sat,  2 Dec 2023 15:50:17 +0000 (UTC)

[toc] | [prev] | [next] | [standalone]

#264152

Am 03.12.2023 um 12:06:40 Uhr schrieb Michel Verdier:

> On 2023-12-02, Andy Smith wrote:
> 
> > Can someone examine the list's configuration? This email from 1994
> > seems to have only just been delivered.  
> 
> How do you find 1994? It seems to be a mail from yesterday:

For me it sounded like a joke.

Telnet is unencrypted (although it is possible to run it over TLS to
encrypt it) and SSH exists more than 20 years.

[toc] | [prev] | [next] | [standalone]

#264154

On Sun, 3 Dec 2023 17:00:44 +0100
Marco Moock <mm@dorfdsl.de> wrote:

> > 
> > How do you find 1994? It seems to be a mail from yesterday:  
> 
> For me it sounded like a joke.
> 
> Telnet is unencrypted (although it is possible to run it over TLS to
> encrypt it) and SSH exists more than 20 years.

True. None the less, there is at least one perfectly good use for
telnet: testing connections to servers.

charles@hawk:~$ telnet hawk
Trying 127.0.1.1...
telnet: Unable to connect to remote host: Connection refused
charles@hawk:~$ telnet hawk 80
Trying 127.0.1.1...
Connected to hawk.localdomain.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
charles@hawk:~$ 

The first attempt shows that hawk does not have a telnet server on the
default port. The second shows that it does have a server of some sort
on port 80, which is assigned to http.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#264155

On Sun, Dec 03, 2023 at 11:52:51AM -0700, Charles Curley wrote:
> On Sun, 3 Dec 2023 17:00:44 +0100
> Marco Moock <mm@dorfdsl.de> wrote:
> 
> > > 
> > > How do you find 1994? It seems to be a mail from yesterday:  
> > 
> > For me it sounded like a joke.
> > 
> > Telnet is unencrypted (although it is possible to run it over TLS to
> > encrypt it) and SSH exists more than 20 years.
> 
> True. None the less, there is at least one perfectly good use for
> telnet: testing connections to servers.
> 
> charles@hawk:~$ telnet hawk
> Trying 127.0.1.1...
> telnet: Unable to connect to remote host: Connection refused
> charles@hawk:~$ telnet hawk 80
> Trying 127.0.1.1...
> Connected to hawk.localdomain.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
> charles@hawk:~$ 

Yes, there is plenty of use for the telnet *client*.  Nobody disputes this.

The question is whether anyone should be running a telnetd *server*.
On an isolated network, it might be acceptable.  But it's really a bad
habit that should be stomped out aggressively, as machines which are
currently on an isolated network might not remain there forever.

[toc] | [prev] | [next] | [standalone]

#264156

On Sun, 3 Dec 2023 14:01:38 -0500
Greg Wooledge <greg@wooledge.org> wrote:

> The question is whether anyone should be running a telnetd *server*.
> On an isolated network, it might be acceptable.  But it's really a bad
> habit that should be stomped out aggressively, as machines which are
> currently on an isolated network might not remain there forever.

I concur, and would add that even on an isolated network one should
prefer ssh. First, to be in the right habit. Second because it will do
things that telnet won't, like tunnel X.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#264160

Charles Curley <charlescurley@charlescurley.com> wrote:
> On Sun, 3 Dec 2023 14:01:38 -0500
> Greg Wooledge <greg@wooledge.org> wrote:
> 
> > The question is whether anyone should be running a telnetd *server*.
> > On an isolated network, it might be acceptable.  But it's really a
> > bad habit that should be stomped out aggressively, as machines
> > which are currently on an isolated network might not remain there
> > forever.  
> 
> I concur, and would add that even on an isolated network one should
> prefer ssh. First, to be in the right habit. Second because it will do
> things that telnet won't, like tunnel X.

Ah but will it tunnel wayland?? Enquiring minds want to know :)

[toc] | [prev] | [next] | [standalone]

#264200

debian-user@howorth.org.uk writes:

>> I concur, and would add that even on an isolated network one should
>> prefer ssh. First, to be in the right habit. Second because it will do
>> things that telnet won't, like tunnel X.
>
> Ah but will it tunnel wayland?? Enquiring minds want to know :)

Yes.

[toc] | [prev] | [next] | [standalone]

#264204

On 12/4/23 05:22, Anssi Saari wrote:
> debian-user@howorth.org.uk writes:
> 
>>> I concur, and would add that even on an isolated network one should
>>> prefer ssh. First, to be in the right habit. Second because it will do
>>> things that telnet won't, like tunnel X.
>>
>> Ah but will it tunnel wayland?? Enquiring minds want to know :)
> 
> Yes.
> 
yes here too.
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264222

gene heskett <gheskett@shentel.net> wrote:
> On 12/4/23 05:22, Anssi Saari wrote:
> > debian-user@howorth.org.uk writes:
> >   
> >>> I concur, and would add that even on an isolated network one
> >>> should prefer ssh. First, to be in the right habit. Second
> >>> because it will do things that telnet won't, like tunnel X.  
> >>
> >> Ah but will it tunnel wayland?? Enquiring minds want to know :)  
> > 
> > Yes.
> >   
> yes here too.

Thanks guys :)
I was under the impression wayland didn't do networks. I live and learn.

> Cheers, Gene Heskett.

[toc] | [prev] | [next] | [standalone]

#264280

debian-user@howorth.org.uk writes:

> gene heskett <gheskett@shentel.net> wrote:
>> On 12/4/23 05:22, Anssi Saari wrote:
>> > debian-user@howorth.org.uk writes:
>> >   
>> >>> I concur, and would add that even on an isolated network one
>> >>> should prefer ssh. First, to be in the right habit. Second
>> >>> because it will do things that telnet won't, like tunnel X.  
>> >>
>> >> Ah but will it tunnel wayland?? Enquiring minds want to know :)  
>> > 
>> > Yes.
>> >   
>> yes here too.
>
> Thanks guys :)
> I was under the impression wayland didn't do networks. I live and learn.

So was I but apparently things move along, even in Wayland. My
experience with Wayland is still only "it crashes". I think I last tried
in the summer, with up to date Arch Linux. I guess it's the NVidia
graphics but even then I should be able to get further than an instant
crash of the session and back to SDDM. Anyways, it's not a priority and
I'll see if I'll get around to trying it on a computer with Intel or AMD
graphics at some point.

Here's link with a small list of commands for variations on tunneling
X or Wayland or XWayland over ssh:

https://www.reddit.com/r/linux/comments/posuyb/comment/hd1c2fq/

[toc] | [prev] | [next] | [standalone]

#264201

On Sun, 3 Dec 2023, Greg Wooledge wrote:

> On Sun, Dec 03, 2023 at 11:52:51AM -0700, Charles Curley wrote:
>>
>> True. None the less, there is at least one perfectly good use for
>> telnet: testing connections to servers.
>>
>> charles@hawk:~$ telnet hawk
>> Trying 127.0.1.1...
>> telnet: Unable to connect to remote host: Connection refused
>> charles@hawk:~$ telnet hawk 80
>> Trying 127.0.1.1...
>> Connected to hawk.localdomain.
>> Escape character is '^]'.
>> ^]
>> telnet> quit
>> Connection closed.
>> charles@hawk:~$
>
> Yes, there is plenty of use for the telnet *client*.  Nobody disputes this.
>
> The question is whether anyone should be running a telnetd *server*.
> On an isolated network, it might be acceptable.  But it's really a bad
> habit that should be stomped out aggressively, as machines which are
> currently on an isolated network might not remain there forever.
>
>

Agree with all of the above. However, the op was connecting to what
looks like a router address. It's possibly hardware that cannot be
updated, only replaced. (and I'm not sure, therefore, if this is a
debian question at all)

I have some (post 2020) motherboards whose ipmi does not work with jvm
post stretch, nor firefox post buster. So I have to keep an old setup
around.

You should never put these sorts of devices on the internet anyway. It
might be *nice* if we didn't have to use old 'insecure' protocols but
it's not *insecure* to do so. The IPMI in question are only accessible
via physical access (so network encryption is hardly helpful) or VPN
(which is kept up to date)

It has frustrated me that the browser writers have refused to
distinguish between rfc1918 (and equivalent ipv6) addresses and
publically routable addresses when it comes to warnings and refusals to
connect.

Some years ago I abandoned firefox because there was no way to override
one of its 'I'm sorry Dave, I'm afraid I can't do that' spasms.

It's crazy that they make things like certificate pinning *impossible*
to override. Another one that bit me - again hardware where the only way
to use https was to have it generate its own self signed certificate
that expired after a year. You can 'work around' but it's *expensive*
the first time you hit it as you end up losing other config. Sure, the
hardware was buggy...

[toc] | [prev] | [next] | [standalone]

#264208 — Re: Firefox, was: Telnet

On 4 Dec 2023 10:29 +0000, from debianuser@woodall.me.uk (Tim Woodall):
> Some years ago I abandoned firefox because there was no way to override
> one of its 'I'm sorry Dave, I'm afraid I can't do that' spasms.
> 
> It's crazy that they make things like certificate pinning *impossible*
> to override.

Firefox deprecated support for HPKP in version 72 in January 2020, in
response to their issue 1412438. https://bugzilla.mozilla.org/show_bug.cgi?id=1412438

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/72#security

Looks like it was originally implemented in Firefox 35, which dates
back to January 2015. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/35#network_security

Apparently present-day versions allow _enabling_ HPKP by adding a
configuration setting which does not exist by default, but finding a
current MDN page even detailing the format of the HPKP HTTP header
appears non-trivial; the Wayback Machine has a copy, but going to the
current page by URL redirects to the one for Expect-CT which _too_ is
deprecated.
https://web.archive.org/web/20211104105929/https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Public-Key-Pins#browser_compatibility
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#264215 — Re: Firefox, was: Telnet

On Mon, 4 Dec 2023, Michael Kj?rling wrote:

> On 4 Dec 2023 10:29 +0000, from debianuser@woodall.me.uk (Tim Woodall):
>> Some years ago I abandoned firefox because there was no way to override
>> one of its 'I'm sorry Dave, I'm afraid I can't do that' spasms.
>>
>> It's crazy that they make things like certificate pinning *impossible*
>> to override.
>
> Firefox deprecated support for HPKP in version 72 in January 2020, in
> response to their issue 1412438. https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
>

Yes, I know. I don't recall now if this was the last straw that broke
the camel's back but firefox adopted a habit of deciding that things
'shouldn't be done' so leave no way to say 'yes, I know what I'm doing'

IIRC they did something daft with self-signed certificates as well.

chrome based browsers aren't much better but I've yet to be hit by going
from working to not working without an intervening 'are you sure'.

Anyway, I was a netscape/mozilla devotee since the 90s, but other than
those 'never update' VMs I don't use it now. I still use lynx - although
there is less and less that works, the browser itself has never failed
to 'do its best'

[toc] | [prev] | [next] | [standalone]

#264192

Marco Moock (12023-12-04):
> ncat also uses ^C to kill the process.

No, this effect of ^C is part of the operating system.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#264224

Am 04.12.2023 um 09:28:30 Uhr schrieb Nicolas George:

> Marco Moock (12023-12-04):
> > ncat also uses ^C to kill the process.  
> 
> No, this effect of ^C is part of the operating system.

Is that really the case?

Other applications like telnet or vi don't care about it, so I
assume(d), it is up to the application to handle it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web