Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #274436 > unrolled thread
| Started by | peter@easthope.ca |
|---|---|
| First post | 2024-11-10 04:20 +0100 |
| Last post | 2024-12-07 20:50 +0100 |
| Articles | 6 on this page of 26 — 11 participants |
Back to article view | Back to linux.debian.user
utelnetd peter@easthope.ca - 2024-11-10 04:20 +0100
Re: utelnetd Jeffrey Walton <noloader@gmail.com> - 2024-11-10 04:50 +0100
Re: utelnetd from 2012 and `make DEBUG=1` Geert Stappers <stappers@stappers.nl> - 2024-11-10 08:40 +0100
Re: utelnetd peter@easthope.ca - 2024-11-10 17:30 +0100
Re: utelnetd <tomas@tuxteam.de> - 2024-11-10 17:40 +0100
Re: utelnetd peter@easthope.ca - 2024-11-10 19:30 +0100
Re: utelnetd <tomas@tuxteam.de> - 2024-11-10 19:40 +0100
Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-10 19:50 +0100
Re: utelnetd peter@easthope.ca - 2024-11-14 20:00 +0100
Re: utelnetd Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-11-14 20:30 +0100
Re: utelnetd peter@easthope.ca - 2024-11-15 18:20 +0100
Re: utelnetd debian-user@howorth.org.uk - 2024-11-15 18:30 +0100
Re: utelnetd Stefan Monnier <monnier@iro.umontreal.ca> - 2024-11-15 18:50 +0100
Re: utelnetd peter@easthope.ca - 2024-11-15 20:30 +0100
Re: utelnetd Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-11-15 23:00 +0100
Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-15 23:10 +0100
Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-10 21:20 +0100
Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-10 21:30 +0100
Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-10 21:40 +0100
Re: utelnetd Geert Stappers <stappers@stappers.nl> - 2024-11-10 22:30 +0100
Re: utelnetd peter@easthope.ca - 2024-11-24 18:30 +0100
Re: utelnetd Max Nikulin <manikulin@gmail.com> - 2024-11-25 03:30 +0100
Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-25 04:10 +0100
[SOLVED] Re: utelnetd peter@easthope.ca - 2024-12-07 18:00 +0100
Re: [SOLVED] Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-12-07 19:20 +0100
Re: utelnetd David Wright <deblis@lionunicorn.co.uk> - 2024-12-07 20:50 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | peter@easthope.ca |
|---|---|
| Date | 2024-11-24 18:30 +0100 |
| Message-ID | <JMoAN-bhFs-7@gated-at.bofh.it> |
| In reply to | #274456 |
From: Greg Wooledge <greg@wooledge.org>
Date: Sun, 10 Nov 2024 15:23:38 -0500
> ... inetutils-telnetd which should work out of the box.
Of course. Used for years and working now.
From: Greg Wooledge <greg@wooledge.org>
Date: Sun, 10 Nov 2024 13:41:11 -0500
> Now, I have absolutely no idea what this "utelnetd" does, ...
Google utelnetd.
https://boxmatrix.info/wiki/Property:utelnetd
https://wiki.gentoo.org/wiki/Utelnetd
https://public.pengutronix.de/software/utelnetd/
A glance at boxmatrix reveals "... ideal for use on embedded systems ... "
and "AN INTERNET SUPERSERVER DAEMON IS NOT REQUIRED."
telnetd developed when multiple terminals connected to a time shared
mainframe. https://en.wikipedia.org/wiki/Telnet#Historical_uses
Yes in the present world a security hazard is possible.
https://en.wikipedia.org/wiki/Telnet#Security_vulnerabilities
An embedded system may have one terminal connected. A connection to
an external network is not necessary for communication between
utelnetd and telnet client.
If the connected system is also connected to an external network, a
firewall can prevent illicit access.
https://en.wikipedia.org/wiki/Firewall
So server terminal access and embedded cases distinct.
My original question is restated here.
https://lists.debian.org/debian-gcc/2024/11/msg00059.html
If I'm lucky, clarification will surface among the compiler people.
Regards, ... P.
--
VoIP: +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-11-25 03:30 +0100 |
| Message-ID | <JMx1n-bmQX-1@gated-at.bofh.it> |
| In reply to | #274846 |
On 24/11/2024 23:11, peter@easthope.ca wrote: > An embedded system may have one terminal connected. A connection to > an external network is not necessary for communication between > utelnetd and telnet client. > > If the connected system is also connected to an external network, a > firewall can prevent illicit access. [...] > My original question is restated here. > https://lists.debian.org/debian-gcc/2024/11/msg00059.html I would still consider dropbear - a SSH server implementation suitable for embedded systems. It is used e.g. by OpenWRT or to unlock encrypted disks from initrd. Perhaps you do not need network at all. I am not sure, but perhaps an application might just create a pty, a VM might expose a virtual serial port.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-11-25 04:10 +0100 |
| Message-ID | <JMxE5-bniQ-1@gated-at.bofh.it> |
| In reply to | #274436 |
peter wrote:
> Retrieved utelnetd 0.1.11 from here.
> https://public.pengutronix.de/software/utelnetd/
OK, let's look at this thing. The tarball from the above web site
contains:
hobbit:~/tmp$ tar tzvf ~/Downloads/utelnetd-0.1.11.tar.gz
drwxr-xr-x frogger/frogger 0 2008-08-11 05:44 utelnetd-0.1.11/
-rw-r--r-- frogger/frogger 16430 2003-08-06 11:02 utelnetd-0.1.11/utelnetd.c
-rw-r--r-- frogger/frogger 17982 2000-03-06 05:39 utelnetd-0.1.11/LICENSE
-rw-r--r-- frogger/frogger 1120 2008-08-11 05:44 utelnetd-0.1.11/Makefile
-rw-r--r-- frogger/frogger 2545 2008-08-11 05:43 utelnetd-0.1.11/ChangeLog
-rw-r--r-- frogger/frogger 532 2003-08-08 03:26 utelnetd-0.1.11/README
Can't get much simpler than that. I extracted it, then ran "make"
as the instuctions said. The program built with a few warnings:
hobbit:~/tmp/utelnetd-0.1.11$ make
gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -fomit-frame-pointer -c -o utelnetd.o utelnetd.c
...
gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -fomit-frame-pointer utelnetd.o -o utelnetd
strip --remove-section=.comment --remove-section=.note utelnetd
hobbit:~/tmp/utelnetd-0.1.11$ ls -l utelnetd
-rwxr-xr-x 1 greg greg 22984 Nov 24 21:44 utelnetd*
I won't try to guess how important the warnings are.
The README file does not tell you how to *run* it. It only tells you
how to compile it.
For whatever it's worth, I also found what I'm guessing is a fork of
this project, at
<https://github.com/shalzz/aruba-ap-310/tree/master/utils/utelnetd-0.1.3>.
It credits the pengutronix site as the original source.
Unfortunately, the URL it points to is now gone.
So much for trying to find documentation that way.
In the .c file, there is the following function:
void show_usage(void)
{
printf("Usage: telnetd [-p port] [-i interface] [-l loginprogram] [-d]\n");
printf("\n");
printf(" -p port specify the tcp port to connect to\n");
printf(" -i interface specify the network interface to listen on\n");
printf(" (default: all interfaces)\n");
printf(" -l loginprogram program started by the server\n");
printf(" -d daemonize\n");
printf("\n");
exit(1);
}
I will assume this is the full documentation. There doesn't appear to be
any more.
So, then the question becomes: do you *trust* this program? Do you think
it's safe to run this thing, as root, on your system? And have it
read your username and password, and create a login session for you?
If your answer is "yes", then read that show_usage function's output,
and act accordingly. If you omit the -d option, it should be simple
to write a systemd unit file for this. Or you could go old school
and use the -d option from rc.local. Or anything else you want to do.
Personally, I would never choose to run this program on my system.
Even if I trust the program not to do anything malicious, even assuming it
has no bugs or back doors or anything like that, the thing it's *trying to
do* is just a bad idea. Unencrypted login sessions, with passwords being
sent in the clear over a network, are inherently insecure. This is 2024.
You can run an sshd on the oldest, cheapest computer you can possibly
find that actually powers up. Running a telnet daemon shouldn't even
be considered a real choice.
Anyway, the program compiles just fine on Debian 12. There is no need
to complain to the Debian GCC maintainers that their compiler has a
problem just because you don't know how "make" works.
[toc] | [prev] | [next] | [standalone]
| From | peter@easthope.ca |
|---|---|
| Date | 2024-12-07 18:00 +0100 |
| Subject | [SOLVED] Re: utelnetd |
| Message-ID | <JR6jT-esxf-3@gated-at.bofh.it> |
| In reply to | #274856 |
Thanks for looking at the problem. You hit on the solution.
From: Greg Wooledge <greg@wooledge.org>
Date: Sun, 24 Nov 2024 22:07:16 -0500
> Anyway, the program compiles just fine on Debian 12.
Bingo. For an independent difficulty, was in Debian 11 here.
A wild guess: some procedure names changed from 11 to 12.
Booted Debian 12, made utelnetd and tested. Works as indicated in
various Web pages.
> I won't try to guess how important the warnings are.
I'd expect a compiler guru to say they're critically important and
revealing and valuable!
> There is no need to complain to the Debian GCC maintainers ...
Yah, they ignored the question.
> So much for trying to find documentation ...
Someone else noted the same and posted the man 8 here.
https://boxmatrix.info/wiki/Property:utelnetd#Details
> Unencrypted login sessions, with passwords being > sent in the clear
over a network, are inherently insecure.
You give a password every time a xterm or similar is opened? To my
understanding, most users just open the term and go at the command line.
If you can break into my system, shorewall needs a bug report.
Thx, ... P.
--
VoIP: +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-12-07 19:20 +0100 |
| Subject | Re: [SOLVED] Re: utelnetd |
| Message-ID | <JR7zk-etvc-7@gated-at.bofh.it> |
| In reply to | #275380 |
Hi, On Sat, Dec 07, 2024 at 08:39:54AM -0700, peter@easthope.ca wrote: > > Unencrypted login sessions, with passwords being > sent in the clear > > over a network, are inherently insecure. > > You give a password every time a xterm or similar is opened? As has been noted multiple times in this thread already, you do not need a telnetd (nor an sshd) to open a local terminal. As far as I can tell still nobody has any idea why you need this software. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-12-07 20:50 +0100 |
| Message-ID | <JR8Yp-eumU-1@gated-at.bofh.it> |
| In reply to | #275380 |
On Sat 07 Dec 2024 at 08:39:54 (-0700), peter@easthope.ca wrote: > > Unencrypted login sessions, with passwords being > > sent in the clear over a network, are inherently insecure. > > You give a password every time a xterm or similar is opened? To my > understanding, most users just open the term and go at the command line. You don't open the xterm on the remote system, but on your own local system, which requires no password. In that xterm, you then use ssh to login on the remote computer, and that's when you either type a password or rely on the exchange of ssh keys. Everything in the session that passes across the network is encrypted by ssh. If, in that remote shell, you open a graphical program that wants to display on your screen, it connects to a proxy X server on the remote machine, which forwards the connection to your local machine through an encrypted channel provided by the ssh. This all happens automatically, because ssh sets the variable DISPLAY on the remote system to a string like localhost:10.0, rather than the :0 that you normally see on the local system. Cheers, David.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.debian.user
csiph-web