• utelnetd

    From peter@easthope.ca@21:1/5 to All on Sun Nov 10 04:20:01 2024
    Retrieved utelnetd 0.1.11 from here. https://public.pengutronix.de/software/utelnetd/

    Installed gcc and tried make.
    # make DEBUG=1 -f ./Makefile
    make: Nothing to be done for 'all'.
    #

    This is the "all" stanza in Makefile.

    all: $(PROGS)

    $(PROGS): $(OBJS)
    $(CC) $(LDFLAGS) $(CFLAGS) $^ $(LDLIBS) -o $@
    $(STRIP) --remove-section=.comment --remove-section=.note $@

    Is the problem in all? Elsewhere?

    Thanks, ... P.

    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Sun Nov 10 17:30:01 2024
    Jeffrey, thanks for the reply. Decades since I've looked at a makefile. Understanding is marginal.

    From: Jeffrey Walton <noloader@gmail.com>
    Date: Sat, 9 Nov 2024 22:39:32 -0500
    My guess is $PROGS is empty. But it is only a guess since the message
    is missing so much information.

    Maybe add a $(info $(PROGS)) before the 'all' recipe to see:

    $(info PROGS: $(PROGS))
    all: $(PROGS)

    Inserted line "$(info PROGS: $(PROGS))" ahead of "all: $(PROGS)". That's
    what you intended, correct?

    Got this.
    # make DEBUG=1 -f ./Makefile
    PROGS: utelnetd
    make: Nothing to be done for 'all'.

    Confirms the assignment earlier in Makefile.

    # grep utelnetd Makefile
    # Makefile for utelnetd
    CORE := utelnetd.core
    PROGS = utelnetd
    OBJS = utelnetd.o

    According to this, libc.so is the only dependancy. https://boxmatrix.info/wiki/Property:utelnetd

    /usr# find . -type f -name "libc.so"
    ./lib/x86_64-linux-gnu/libc.so

    Seems OK.

    Something elementary and critical missing?

    Thanks, ... P.

    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tomas@tuxteam.de@21:1/5 to peter@easthope.ca on Sun Nov 10 17:40:01 2024
    On Sun, Nov 10, 2024 at 08:07:23AM -0700, peter@easthope.ca wrote:
    Jeffrey, thanks for the reply. Decades since I've looked at a makefile. Understanding is marginal.

    From: Jeffrey Walton <noloader@gmail.com>
    Date: Sat, 9 Nov 2024 22:39:32 -0500
    My guess is $PROGS is empty. But it is only a guess since the message
    is missing so much information.

    Maybe add a $(info $(PROGS)) before the 'all' recipe to see:

    $(info PROGS: $(PROGS))
    all: $(PROGS)

    Inserted line "$(info PROGS: $(PROGS))" ahead of "all: $(PROGS)". That's what you intended, correct?

    Got this.
    # make DEBUG=1 -f ./Makefile
    PROGS: utelnetd
    make: Nothing to be done for 'all'.

    That would mean that some "utelnetd" is there and is as young or
    younger than its dependencies, so Make concludes that it has nothing
    to do.

    Perhaps you need a "make clean" before, to force Make to actually
    do its thing? Missing that target, you might want to remove utelned,
    and perhaps utelnetd.o.

    But perhaps Make is right and utelnetd is built and ready to go?

    What evidence would you have that it is not so?

    Cheers
    --
    tomás

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZzDfqwAKCRAFyCz1etHa Rra4AKCAAUkInEzfxhP5tGObdqRZ5PaX4gCeNEabHwk8IApQ7wanxp8rz9M1IOs=
    =5PDx
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Sun Nov 10 19:30:02 2024
    From: <tomas@tuxteam.de>
    Date: Sun, 10 Nov 2024 17:30:42 +0100
    But perhaps Make is right and utelnetd is built and ready to go?

    What evidence would you have that it is not so?

    # ls -ld /usr/local/bin/u*
    ls: cannot access '/usr/local/bin/u*': No such file or directory

    # cd /usr
    # find . -type f -name "utelnetd"
    #

    Perhaps you need a "make clean" before, to force Make to actually
    do its thing? Missing that target, you might want to remove utelned,
    and perhaps utelnetd.o.

    # make clean
    PROGS: utelnetd
    rm -f utelnetd *.o core

    Now make gives a flock of complaints. See below. Eg. grantpt vs.
    getpt.

    The problem is Debian differing from the system where where the
    developer worked? I need to change some names?

    Thanks, ... P.

    # make DEBUG=1 -f ./Makefile
    PROGS: utelnetd
    gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os -c -o utelnetd.o utelnetd.c
    utelnetd.c: In function ‘getpty’:
    utelnetd.c:232:13: warning: implicit declaration of function ‘grantpt’; did you mean ‘getpt’? [-Wimplicit-function-declaration]
    232 | if (grantpt(p)<0 || unlockpt(p)<0) {
    | ^~~~~~~
    | getpt
    utelnetd.c:232:29: warning: implicit declaration of function ‘unlockpt’ [-Wimplicit-function-declaration]
    232 | if (grantpt(p)<0 || unlockpt(p)<0) {
    | ^~~~~~~~
    utelnetd.c:237:44: warning: implicit declaration of function ‘ptsname’; did you mean ‘ptsname_r’? [-Wimplicit-function-declaration]
    237 | DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
    | ^~~~~~~
    utelnetd.c:112:40: note: in definition of macro ‘DEBUG_OUT’
    112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
    | ^~~~~~~~~~~
    utelnetd.c:237:19: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
    237 | DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
    | ^~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
    | |
    | int
    utelnetd.c:112:40: note: in definition of macro ‘DEBUG_OUT’
    112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
    | ^~~~~~~~~~~
    utelnetd.c:237:39: note: format string is defined here
    237 | DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
    | ~^
    | |
    | char *
    | %d
    utelnetd.c:238:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    238 | strcpy(line, (const char*)ptsname(p));
    | ^
    utelnetd.c: In function ‘main’:
    utelnetd.c:561:7: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness [-Wpointer-sign]
    561 | &salen)) < 0) {
    | ^~~~~~
    | |
    | int *
    In file included from utelnetd.c:45: /usr/include/x86_64-linux-gnu/sys/socket.h:233:28: note: expected ‘socklen_t * restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
    233 | socklen_t *__restrict __addr_len);
    | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
    utelnetd.c:597:32: warning: pointer targets in passing argument 1 of ‘remove_iacs’ differ in signedness [-Wpointer-sign]
    597 | ptr = remove_iacs(ts->buf1 + ts->wridx1, maxlen,
    | ~~~~~~~~~^~~~~~~~~~~~
    | |
    | char *
    utelnetd.c:190:28: note: expected ‘unsigned char *’ but argument is of type ‘char *’
    190 | remove_iacs(unsigned char *bf, int len, int *processed, int *num_totty) {
    | ~~~~~~~~~~~~~~~^~
    gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os utelnetd.o -o utelnetd
    # --remove-section=.comment --remove-section=.note utelnetd
    #
    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tomas@tuxteam.de@21:1/5 to peter@easthope.ca on Sun Nov 10 19:40:02 2024
    On Sun, Nov 10, 2024 at 10:08:47AM -0700, peter@easthope.ca wrote:
    From: <tomas@tuxteam.de>
    Date: Sun, 10 Nov 2024 17:30:42 +0100
    But perhaps Make is right and utelnetd is built and ready to go?

    What evidence would you have that it is not so?

    # ls -ld /usr/local/bin/u*
    ls: cannot access '/usr/local/bin/u*': No such file or directory

    # cd /usr
    # find . -type f -name "utelnetd"
    #

    Perhaps you need a "make clean" before, to force Make to actually
    do its thing? Missing that target, you might want to remove utelned,
    and perhaps utelnetd.o.

    # make clean
    PROGS: utelnetd
    rm -f utelnetd *.o core

    Now make gives a flock of complaints. See below. Eg. grantpt vs.
    getpt.

    The problem is Debian differing from the system where where the
    developer worked? I need to change some names?

    Thanks, ... P.

    # make DEBUG=1 -f ./Makefile
    PROGS: utelnetd
    gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os -c -o utelnetd.o utelnetd.c
    utelnetd.c: In function ‘getpty’:
    utelnetd.c:232:13: warning: implicit declaration of function ‘grantpt’; did you mean ‘getpt’? [-Wimplicit-function-declaration]
    232 | if (grantpt(p)<0 || unlockpt(p)<0) {
    | ^~~~~~~
    | getpt

    [...]

    Hm. No. This function should exist. Either your compile process is hitting
    the wrong libc headers, or something else is amiss.

    The error message just means that the compiler hasn't seen a declaration
    for grantpt. It /should/ have seen one.

    (the other error messages are in the same ballpark).

    Now if the header file was just missing, the complaints would be different,
    I guess.

    Cheers
    --
    tomás

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZzD8EQAKCRAFyCz1etHa RpMAAJ987NrwTVYMu1Pl81B16cfo7Q5n9gCbBHwxoU2RWZvzSy6ADEdy2qovvA0=
    =hmDm
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to peter@easthope.ca on Sun Nov 10 19:50:01 2024
    On Sun, Nov 10, 2024 at 10:08:47 -0700, peter@easthope.ca wrote:
    From: <tomas@tuxteam.de>
    Date: Sun, 10 Nov 2024 17:30:42 +0100
    But perhaps Make is right and utelnetd is built and ready to go?

    What evidence would you have that it is not so?

    # ls -ld /usr/local/bin/u*
    ls: cannot access '/usr/local/bin/u*': No such file or directory

    Is this your first time building software from source code? Normally
    there are three steps:

    1) Configure it to build on your system; this may involve running a
    shell script or a perl script, or editing files manually. This
    is normally done as yourself.

    2) Run "make" or "cmake" or some equivalent program. This is normally
    done as yourself. This builds the program(s) in the current directory,
    or some subdirectory.

    3) Run "make install" or something equivalent, to copy the program(s)
    to the system directories. This usually requires root privileges.

    # cd /usr
    # find . -type f -name "utelnetd"
    #

    So what you're telling us is that you've done the first two steps, and
    utelnetd has been built in the build directory, but you haven't
    installed it into /usr/local/bin yet.

    Now, I have absolutely no idea what this "utelnetd" does, other than what
    I can guess from its name. But if it's supposed to be a *telnet daemon*
    that you run and connect to, then installing it in /usr/local/bin (or somewhere) is only going to be one step among several. You'd also need
    to arrange for it to be run as a service.

    If you're struggling with understanding the difference between "make"
    and "make install", then getting this third party program running as a
    service is going to have quite a learning curve for you.

    The first question I had when I saw this thread was "Why on *earth* is
    he trying to run a third party telnet daemon?" What's wrong with the
    telnet daemon that's included in Debian? Why would you even want a
    telnet daemon in 2024? It's so incredibly insecure!

    But hey, maybe the name is a red herring, and it does something else
    entirely. Who knows.

    Anyway, I suggest you read the documentation more closely. If the documentation isn't adequate for someone with your skill set (which
    is quite probable with third party programs), then please explain
    to us what you're *trying to do*. We'll probably tell you to throw
    this thing away and use something else.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Andy Smith on Sun Nov 10 21:30:01 2024
    On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
    There is also a telnetd packaged in Debian but I think that one needs to
    be run under an inetd so you'd have to install one of those as well.

    Fortunately, the inetutils-telnetd package in Debian depends on
    inetutils-inetd | inet-superserver, so it should bring in an inetd automatically if one isn't already present.

    I'd really like to hear why the OP is trying to build a third-party
    telnet daemon instead of simply installing inetutils-telnetd which
    should work out of the box.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to peter@easthope.ca on Sun Nov 10 21:20:01 2024
    On Sat, Nov 09, 2024 at 07:02:12PM -0700, peter@easthope.ca wrote:
    Hi,

    Retrieved utelnetd 0.1.11 from here. https://public.pengutronix.de/software/utelnetd/

    This is really old software that you're trying to build from source and
    while that should still be possible, it seems it's not something that
    you're very familiar with so could be a lot of work to learn what needs
    to be fixed to make that work on up to date Debian.

    Is there some specific reason why you need a very minimal telnet
    server?

    If the machine is capable of running openssh or dropbear then normally
    anything you would want to do through telnet could be done through ssh,
    with the advantage that these are packaged in Debian already.

    There is also a telnetd packaged in Debian but I think that one needs to
    be run under an inetd so you'd have to install one of those as well.

    Thanks,
    Andy

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to Greg Wooledge on Sun Nov 10 21:40:01 2024
    Hi,

    On Sun, Nov 10, 2024 at 03:23:38PM -0500, Greg Wooledge wrote:
    On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
    There is also a telnetd packaged in Debian but I think that one needs to
    be run under an inetd so you'd have to install one of those as well.

    Fortunately, the inetutils-telnetd package in Debian depends on inetutils-inetd | inet-superserver, so it should bring in an inetd automatically if one isn't already present.

    Sure, but I was wondering if the reason not to run the packaged telnetd
    was because it would mean running an inetd as well.

    Just struggling to find the point of utelnetd existing I suppose.

    Thanks,
    Andy

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Geert Stappers@21:1/5 to Greg Wooledge on Sun Nov 10 22:30:01 2024
    On Sun, Nov 10, 2024 at 03:23:38PM -0500, Greg Wooledge wrote:
    On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
    There is also a telnetd packaged in Debian but I think that one needs to
    be run under an inetd so you'd have to install one of those as well.

    Fortunately, the inetutils-telnetd package in Debian depends on inetutils-inetd | inet-superserver, so it should bring in an inetd automatically if one isn't already present.

    I'd really like to hear why the OP is trying to build a third-party
    telnet daemon instead of simply installing inetutils-telnetd which
    should work out of the box.

    Original Poster now in Cc: And I have the awark feeling that OP
    missed https://lists.debian.org/debian-user/2024/11/msg00217.html


    Groeten
    Geert Stappers
    --
    Silence is hard to parse

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Thu Nov 14 20:00:01 2024
    From: Greg Wooledge <greg@wooledge.org>
    Date: Sun, 10 Nov 2024 13:41:11 -0500
    Is this your first time building software from source code?

    Haven't thought about make since about 1993 and my exposure then was
    minimal. Remember "make"; not "install".

    3) Run "make install" or something equivalent, to copy the program(s)
    to the system directories. This usually requires root privileges.

    Thanks. Was oblivious to that. "man make" gives no mention of install but TLDP helps.
    https://tldp.org/HOWTO/Software-Building-HOWTO-3.html https://tldp.org/LDP/LG/current/smith.html
    etc.

    Now, I have absolutely no idea what this "utelnetd" does, ...

    Found it about a week ago.
    https://wiki.gentoo.org/wiki/Utelnetd https://boxmatrix.info/wiki/Property:utelnetd https://public.pengutronix.de/software/utelnetd/ https://sourceforge.net/projects/utelnetd/
    The boxmatrix and pengutronix pages suggest that it was developed
    primarily to allow a console on an embedded system.

    If you're struggling with understanding the difference between "make"
    and "make install", then getting this third party program running as a service is going to have quite a learning curve for you.

    If all else fails, may ask another question.

    What's wrong with the telnet daemon that's included in Debian?

    Used it for years. When multiple terminals connected to a central
    mainframe it was appropriate. My application is software (embedded)
    in a Debian system. Only 2 or 3 telnet consoles needed.

    Gruesome details here. https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Telnet_Console https://en.wikibooks.org/wiki/Oberon/A2#User_Level_Applications

    inetd/telnetd is rather overkill and utelned should suffice.

    Regards, ... P.

    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Fri Nov 15 18:20:01 2024
    Extremely long References header shortened. =8~/

    From: Timothy M Butterworth <timothy.m.butterworth@gmail.com>
    Date: Thu, 14 Nov 2024 14:21:20 -0500
    SSHD is packaged and available on Debian.

    Timothy, for a console on localhost do you use ssh exclusively? Never
    xterm or similar? You authenticate every connection to localhost?

    SSH encrypts the traffic but telnet is plain text.

    I don't know the implementation of xterm and etc. Is an xterm
    connection to localhost direct or under TLS? Naively, I wouldn't
    expect TLS to be necessary for localhost. When a miscreant has access
    to a machine, TLS on a local console connection probably won't help.
    =8~/

    You should look into Secure Shell SSH instead of telnet.

    Used it in A2.

    ETHO would require significant updating. (Project for my next life.)
    Details available via my previous message.

    Thx, ... P.

    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From debian-user@howorth.org.uk@21:1/5 to peter@easthope.ca on Fri Nov 15 18:30:01 2024
    peter@easthope.ca wrote:
    Extremely long References header shortened. =8~/

    From: Timothy M Butterworth <timothy.m.butterworth@gmail.com>
    Date: Thu, 14 Nov 2024 14:21:20 -0500
    SSHD is packaged and available on Debian.

    Timothy, for a console on localhost do you use ssh exclusively?
    Never xterm or similar? You authenticate every connection to
    localhost?

    SSH encrypts the traffic but telnet is plain text.

    I don't know the implementation of xterm and etc. Is an xterm
    connection to localhost direct or under TLS? Naively, I wouldn't
    expect TLS to be necessary for localhost. When a miscreant has
    access to a machine, TLS on a local console connection probably won't
    help. =8~/

    You should look into Secure Shell SSH instead of telnet.

    Used it in A2.

    ETHO would require significant updating. (Project for my next life.)
    Details available via my previous message.

    Thx, ... P.

    I'm thoroughly confused. What are you actually trying to do?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Fri Nov 15 18:50:01 2024
    SSHD is packaged and available on Debian.
    Timothy, for a console on localhost do you use ssh exclusively? Never
    xterm or similar? You authenticate every connection to localhost?

    Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside*
    `xterm`, no *instead of* `xterm`.

    Naively, I wouldn't expect TLS to be necessary for localhost.

    When you want to "log into localhost" you can usually use `su` instead
    of `ssh/telnet`. This said, I sometimes use `ssh` anyway (typically in scripts) so it works the same for local and non-local connections.
    Presumably encryption is not needed for localhost (tho I'm not
    completely sure to what extent there could be non-root processes which
    could listen on the connection via the loopback device), but as long as
    you're not transferring large amounts of data the overhead of encryption
    should be lost in the noise.


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Fri Nov 15 20:30:02 2024
    From: Stefan Monnier <monnier@iro.umontreal.ca>
    Date: Fri, 15 Nov 2024 12:45:14 -0500
    Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside*
    `xterm`, no *instead of* `xterm`.

    OK, I understand that. If X11 is running you use xterm or similar. If
    X11 is not running you can do "ssh localhost" on the command line of a
    virtual console.

    When you want to "log into localhost" you can usually use `su` instead
    of `ssh/telnet`. This said, I sometimes use `ssh` anyway (typically in scripts) ...

    I considered only the live interactive case. Not a script.

    Presumably encryption is not needed for localhost ...

    Exactly what I meant with "Naively, I wouldn't expect TLS to be
    necessary for localhost. When a miscreant has access to a machine,
    TLS on a local console connection probably won't help."

    Thx, ... P.

    --
    VoIP: +1 604 670 0140
    work: https://en.wikibooks.org/wiki/User:PeterEasthope

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to peter@easthope.ca on Fri Nov 15 23:10:02 2024
    Hi,

    On Fri, Nov 15, 2024 at 11:11:49AM -0700, peter@easthope.ca wrote:
    Exactly what I meant with "Naively, I wouldn't expect TLS to be
    necessary for localhost.

    This utelnetd is also not necessary for localhost. And if telnet was
    actually a requirement, I'm fairly confident that the telnetd that is
    already packaged in Debian would suffice for your purposes on all but
    the most tiny of systems. If you have been able to boot Debian on it,
    probably Debian's telnetd is okay.

    It seems really really unlikely that working out how to compile this
    ancient telnetd variant is what you actually want to do here.

    Put simply, if there is no IP network involved then you do not need an
    sshd or telnetd.

    If there is am IP network involved then you probably want sshd.

    If you have really unusual requirements like one end or the other not
    being up to the task of even running ssh, then MAYBE you could try
    telnet, in which case Debian's telnetd is right there.

    I think the time has past that even telnetd has to be cut down, which
    I think probably reflects the last date that utelnetd received an
    update.

    Thanks,
    Andy

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Sun Nov 24 18:30:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to peter on Mon Nov 25 04:10:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From peter@easthope.ca@21:1/5 to All on Sat Dec 7 18:00:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to peter@easthope.ca on Sat Dec 7 19:20:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to peter@easthope.ca on Sat Dec 7 20:50:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)