You are not logged in.
Hello guys,
I need telnet on my machine to interact with OpenOCD, so I followed the arch linux wiki page for telnet and installed:
sudo pacman -S inetutils
Then, to enable the server with systemd:
sudo systemctl enable telnet.socket
sudo systemctl restart telnet.socket
Now I try a basic self connection with:
telnet localhost
But I get a Login incorrect error 5x times in a row without me inputting any characters:
[stefano@jarvis ~]$ telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Linux 6.0.2-arch1-1 (jarvis) (pts/1)
Login incorrect
Login incorrect
Login incorrect
Login incorrect
Login incorrect
Connection closed by foreign host.
[stefano@jarvis ~]$
Apparently it's a common issue, about which the wiki states:
If the session disconnects before you receive a login prompt, try installing inetutils-gitAUR in place of the current inetutils and restarting telnet.socket.
Which I can't do because the website is not reachable at the moment (tried with yay and a manual git clone -> makepkg -si):
.
.
.
curl: (7) Failed to connect to projects.archlinux.org port 443 after 54 ms: Connection refused
==> ERROR: Failure while downloading https://projects.archlinux.org/svntogit/packages.git/plain/trunk/ftpd.service?h=packages/inetutils
Aborting...
[stefano@jarvis ~]$
I can ping projects.archlinux.org from cmd, but from browser I'm unable to connect.
At this point I'm stuck with the original issue, any idea why the telnet connection doesn't give me a chance to login?
Thanks
Offline
You don't need to run a telnet server to connect to other devices.
Offline
For the server issue see https://bbs.archlinux.org/viewtopic.php … 0#p1905140
Online
For the server issue see https://bbs.archlinux.org/viewtopic.php … 0#p1905140
What we missed in that thread is login -h changes the pam service used to remote which Arch does not ship so the fallback which rejects everything is used, that also explains why inetutils-git from AUR works as that rewrites other to use pam_unix.so.
Edit:
Which raises the question what is pam_securetty.so in /etc/pam.d/login protecting against? https://bugs.archlinux.org/task/45903
Last edited by loqs (2022-10-23 20:43:25)
Offline
For context:
-h
Used by other servers (such as telnetd(8) to pass the name of the remote host to login
so that it can be placed in utmp and wtmp. Only the superuser is allowed use this
option.Note that the -h option has an impact on the PAM service name. The standard service
name is login, but with the -h option, the name is remote. It is necessary to create
proper PAM config files (for example, /etc/pam.d/login and /etc/pam.d/remote).
pam_securetty is a PAM module that allows root logins only if the user is logging in on a
"secure" tty, as defined by the listing in the securetty file. pam_securetty checks at
first, if /etc/securetty exists. If not and it was built with vendordir support, it will
use <vendordir>/securetty. pam_securetty also checks that the securetty files are plain
files and not world writable. It will also allow root logins on the tty specified with
console= switch on the kernel command line and on ttys from the
/sys/class/tty/console/active.This module has no effect on non-root users and requires that the application fills in the
PAM_TTY item correctly.
And indeed:
% strings /usr/bin/telnetd | grep -i login
exec-login
can't expand login command line
set program to be executed instead of /usr/bin/login
do not print host information before login has been completed
/usr/bin/login -p -h %h %?u{-f %u}{%U}
I'll discount lennarts position as inherently invalid because lennarts position is always to introduce broken stuff and claim that the rest of the world has a bug, but will look through the 7 year old arch bug for a more informed opinion
Online
On topic: copying /etc/pam.d/login to /etc/pam.d/remote (w/ securetty, that's completely orthogonal) indeed fixes the telnet problem, so util-linux should™ probably ship etc/pam.d/remote
So the bug starts out as 'securetty "breaks" containers' but then moves on to "how do we get rid of inetutils".
Why?
1. You're not getting rid of telnet - the client will be relevant for pretty much ever
2. There's /etc/pam.d/rlogin and /etc/pam.d/rsh and they can perfectly rely on securetty w/o breaking container
3. rlogind has "-o, --allow-root / allow uid 0 to login, disabled by default"
4. keep securetty in pam.d/remote and drop it from pam.d/login and rely on login being invoked correctly (as telnet does) - pam.d/remote wants to include system-login, not system-local-login
5. still yell out a security warning announcement w/ the update and the mailing list and everywhere, h4ck0rz are gonna figure that anyway, you only care about sys admins and assume perfect knowledge among hostile players.
When comparing other distros nb. that THEY MIGHT USE LOGIN FROM SHADOW and not util-linux!
idk. why arch opted out of shadow and into util-linux, but the login manpage from the shadow git does not mention a login/remote pam separation and that might also inform the presence of securetty in their pam.d/login
Online