You are not logged in.
Fellow Archers,
I am having trouble logging into an arch using Telnet. When I try telnet 127.0.0.1, the system doesn't even asks for username or password; it promptly responds with:
[user@server ~]$ telnet 192.168.11.74
Trying 192.168.11.74...
Connected to 192.168.11.74.
Escape character is '^]'.
Linux 5.6.3-arch1-1 (localhost) (pts/1)
Login incorrect
Login incorrect
Login incorrect
Login incorrect
Login incorrect
Connection closed by foreign host.
[user@server ~]$
Any ideas?
I've started the service with:
sudo systemctl start telnet.socket
Using systemctl, I can conform the service is indeed running without errors:
sudo systemctl start telnet.socket
telnet.socket - Telnet Server Activation Socket
Loaded: loaded (/usr/lib/systemd/system/telnet.socket; disabled; vendor pr>
Active: active (listening) since Thu 2020-05-14 13:33:19 EDT; 6min ago
Docs: man:telnetd(8)
Listen: [::]:23 (Stream)
Accepted: 1; Connected: 0;
Tasks: 0 (limit: 1159)
Memory: 60.0K
CGroup: /system.slice/telnet.socket
May 14 13:33:19 secOps systemd[1]: Listening on Telnet Server Activation Socket.
lines 1-11/11 (END)
Any help is very appreciated.
PS. I understand the risks with running telnet. No need to fret, though; this is a VM to be used in a security class, designed to show why one should NOT use telnet for server maintenance.
Offline
telnet --help
You probably want to use the "-l" switch, maybe the "-K" one.
Offline
Thanks for the suggestion, Seth. Unfortunately, been there, done that. No success.
I also tried telneting from another machine into this one; no luck. This makes me think this is a telnet server-related issue.
I really need this working.
Offline
Hoping someone more knowledgeable than me can come along, but could this be the same issue as mine - https://bbs.archlinux.org/viewtopic.php?id=255288
Which I haven't resolved yet. It's annoying that it's only one machine affected.
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
Just a guess, but I hope that PAM is not allowing this.
You might also ensure you followed the suggestion here: https://wiki.archlinux.org/index.php/Telnet
Check your journal to see if there are clues in there.
<soapbox> Please, please, please be advised that Telnet is not secure and really should not be used to log into the system, I use Telnet clients to talk to non-login services on ports, but nothing more. It is all clear text. </soapbox>
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
@ewaller,
ldd /usr/bin/telnetd
- no PAM…
Tried, the service really just quits too fast - you cannot get any login shell and at times it doesn't connect at all.
I could get to succeed (90% of the time) by editing "/usr/lib/systemd/system/telnet@.service" and replace
ExecStart=-/usr/bin/telnetd
with
ExecStart=-/usr/bin/telnetd -E "/bin/login -H"
You can also try the git version (as suggested in the wiki) or telnet-bsd (also AUR, incompatible w/ the inetutils package)
Edit: I initially thought only
ExecStart=-/usr/bin/telnetd -E "/bin/login -f -H"
worked fastenough™ but on subsequent tests, the regular login (-f disables the password query) seems to be just as half-reliable.
What a fuck.
Last edited by seth (2020-05-15 19:41:32)
Offline
Just a guess, but I hope that PAM is not allowing this.
You might also ensure you followed the suggestion here: https://wiki.archlinux.org/index.php/TelnetCheck your journal to see if there are clues in there.
<soapbox> Please, please, please be advised that Telnet is not secure and really should not be used to log into the system, I use Telnet clients to talk to non-login services on ports, but nothing more. It is all clear text. </soapbox>
Thanks, @ewaller.
I had already looked over the two links you provided before posting here. The main issue(s) to me are:
1. logs don't seem very helpful. I will look again, though.
2. I can telnet to other ports (SSH, HTTP, etc). The Telnet server seems to be the one acting up.
3. The behavior *seems* to show that the Telnet client is sending login info on its own, without giving me the chance to enter username or password. The server refuses it, of course.
Still looking into this...
Offline
Did you look into my last post? ;-)
Offline
Did you look into my last post? ;-)
I did but didn't have the chance to try it yet. I am giving it a go today and will report back.
I want to:
1. remove the current telnetd binary (or at least change its name)
2. install the alternative package you mentioned (telnetd-bsd, from AUR).
3. pray for the best.
I don't use telnet for server administration; I just need this working so I can show folks why they should NOT use it either.
I will report back the results.
Thanks again, seth.
Last edited by cantBelieveItAintButter (2020-05-19 14:31:00)
Offline
You want to first and foremost try to edit /usr/lib/systemd/system/telnet@.service to lean down the login command because the telnet daemon bails out too fast.
Offline
You want to first and foremost try to edit /usr/lib/systemd/system/telnet@.service to lean down the login command because the telnet daemon bails out too fast.
Success!
Telling telnet to run login upon execution did the trick for me. It's a hack, make no mistake, but a beautiful and elegant one. Thank you, sir.
I will flag this thread as SOLVED because my problem is solved. However, I would LOVE to know what the hell telnetd is doing that doesn't even care to listen to input before dropping the connection.
-rod
Offline
telnetd runs Login by Default, just not with the "-H" switch. It suppresses the hostname lookup what either makes login to slow or open/close the wrong pipe what makes telnetd close with probably a bad Input. The telnetd process is only started when the port is opened to establish the connection. he entire Thing is rather fragile and we're hitting some race condition.
Offline
Offline
The patch is a revert and the condition got relaxed.
From the behavior I rather assume it hits http://git.savannah.gnu.org/cgit/inetut … 97c5d#n622
Since the error is fairly reproducible, one could inject some debug output to see which condition triggers the loop to quit.
Do we care about telnetd?
I understand the risks with running telnet. No need to fret, though; this is a VM to be used in a security class, designed to show why one should NOT use telnet for server maintenance.
Offline
I just ran into the commit I mentioned when I was checking if the inetutils git repository had the fix for CVE-2020-10188.
Last edited by loqs (2020-07-19 22:36:15)
Offline
@seth Thank you for
ExecStart=-/usr/bin/telnetd -E "/bin/login -H"
I got another telnet login message "Login incorrect" four times repeated fixed. Arch was updated today, to 5.10.74-1-raspberrypi4-ARCH, and the error is still there.
Now I can fix an ssh login issue for a box that is not connected to the internet.
Last edited by probackup-nl (2021-10-22 17:07:17)
Offline
With "pts/1" instead of "pts1" in /etc/securetty "Login incorrect" is gone.
Offline
Because it's the proper tty path - "pts1" is not, https://man.archlinux.org/man/core/man- … retty.5.en
You do understand the security implications and at this point it would be more honest to disable pam_securetty altogether?
Offline