Is there a way to disable the arrow keys at TTY login?

metalpunk · 2023-06-26 14:28:41

As the title suggests, I log into my Arch laptop via TTY. This works great, except sometimes I mistype after I enter my username, pressing

<Up>

instead of Enter. This, predictably, moves my cursor up.

<Down>

will move the cursor back where it should be visually, but the login program must not like the input keycodes. Once I do press Enter, the TTY locks up for about 10 seconds until it (I'm guessing) goes through the usual password check, sees no input, and fails, causing the TTY to reset.

Can the arrow keys be disabled to prevent this? Can't seem to find anything relevant in the wiki or the forums.

Trilby · 2023-06-26 14:55:47

I just had to test this as it sounded odd - but I can confirm this does indeed happen but *only* on the first login attempt. Metalpunk, can you confirm this: if you enter an incorrect username / password (with no arrow keys) then get a new prompt to try again and type your username followed by an arrow key, it should not move the cursor up; rather it prints the escape code (e.g., "^[[A") which can readily be deleted with backspace.

This looks to me like a bug (in /bin/login I suspect) that appears only on the initial login attempt resulting in arrow keys creating cursor movement and an unrecoverable login attempt (followed by a delay of about 10 seconds). At least part of this could be due to a failure to initialize the right ioctl settings early enough (at least that would be expected to result in such symptoms).

I don't know any way to disable the cursor keys for /bin/login, but if this is a bug, it should be reported / fixed upstream.

Last edited by Trilby (2023-06-26 14:58:55)

metalpunk · 2023-06-26 21:46:14

Trilby wrote:

I just had to test this as it sounded odd - but I can confirm this does indeed happen but *only* on the first login attempt. Metalpunk, can you confirm this: if you enter an incorrect username / password (with no arrow keys) then get a new prompt to try again and type your username followed by an arrow key, it should not move the cursor up; rather it prints the escape code (e.g., "^[[A") which can readily be deleted with backspace.

Yes, I just tried this, and I saw the behavior you described

seth · 2023-06-28 06:00:17

https://bbs.archlinux.org/viewtopic.php?id=135787
https://bbs.archlinux.org/viewtopic.php?id=142031 (parrot included
https://bugs.debian.org/cgi-bin/bugrepo … bug=680302
https://bugzilla.redhat.com/show_bug.cgi?id=969458
https://github.com/util-linux/util-linu … 0258a43c86

It would seem that reset_virtual_console isn't initially called?
Does

stty [-]echoctl

do anything for either of you?

Trilby · 2023-06-28 13:08:17

In contrast to the decade-old thread there I commented in, this occurrence does prevent a successful login - I still hold the same view that the login program should be simple and not try to do anything outside it's scope, but loging the user in is not only in scope, but is the program's sole purpose. So if it fails in a way that prevents one from login in, that's a problem.

When an arrow key produces something like ^[[A, those characters can be deleted with backspace and one can then log in. If, instead, the cursor moves, there is no apparent way to recover for a successul log in. And oddly, there is a notable delay after a failed log in specifically when there was a cursor movement.

For the stty command, would you expect that entering it after a successful login could affect subsequent logins on that tty (otherwise how / where should that be put)? I logged in successfully, ran `stty echoctl`, logged out, and confirmed the cursor key issue was still present for the next attempt. The same sequence and same result was came from `stty -echoctl`.

Seth, you can't replicate this on your system? Do you have any getty service customizations / overrides? I have autologin configured for tty1, but nothing for the other ttys on which I can replicate this issue.

EDIT: once this issue has happened (i.e., once I have pressed the up arrow) not only can that login attempt not be recovered by any kind of edits or moving the cursor back down, but even Ctrl-C fails to break / reset the login as it normally would (but instead moves the cursor several spaces to the left). The only way forward at that point seems to be to hit enter, then wait out the delay (it seems to be 10s).

Last edited by Trilby (2023-06-28 13:12:36)

seth · 2023-06-28 15:35:36

For the stty command, would you expect that entering it after a successful login could affect subsequent logins on that tty

Since agetty seems to actively manipulate the settings: no. agetty however has a "-c" flag that could be utilized (to not reset the cflags) and the service could setty echoctl ahead of agetty. Iff that even works (hence the question)

But it doesn't do anything here at all (while it should™, I guess) and, possibly* because of that, the behavior is consistent cursor maneuvering (ie. I don't get the escape sequences after even a failed login)
I've a custom getty@tty1.service (autologin) but getty@tty2.service is vanilla (but 2.38, not 2.39 - I really need to update…)

*your description sounds like it's login or some pam module that sanitizes the echoctl and I have manipulated PAM, notably removed homed.

The login probably fails because you're posting a bunch of escape sequences to login and it cannot properly handle those.

Trilby · 2023-06-28 15:40:43

seth wrote:

The login probably fails because you're posting a bunch of escape sequences to login and it cannot properly handle those.

Perhaps - but what is striking to me is that when it "works" (in that an arrow key inserts a visible "^[[A" or similar) those escape sequences can be deleted and the edited entry is handled just fine. But when it "fails" (the arrow key moves the cursor up) no sequence of deletions can lead to success (or at least none of a wide range of variations I've tried). So login / pam / whatever can handle it reasonably in some cases and not at all in others.

But based on the links provided above, this has been a long standing issue - though I *didn't* experience these problems ~10 years ago when it was discussed, so something seems to have changed. Of course it's not something I'd encounter, so perhaps my system became subject to this issue 9.5 years ago for all I know.

(edit: I just tested on a different system and get the same "problematic" results.)

Last edited by Trilby (2023-06-28 15:41:24)

seth · 2023-06-28 15:54:23

In the working case, you're just "typing" those chars and backspace works to remove them (actually, you can define what keys act as additional delete
But the actual control sequences cannot be undone, they'll just stack up and become part of the input for the login/pass, rendering them invalid.

Arch Linux

#1 2023-06-26 14:28:41

Is there a way to disable the arrow keys at TTY login?

#2 2023-06-26 14:55:47

Re: Is there a way to disable the arrow keys at TTY login?

#3 2023-06-26 21:46:14

Re: Is there a way to disable the arrow keys at TTY login?

#4 2023-06-28 06:00:17

Re: Is there a way to disable the arrow keys at TTY login?

#5 2023-06-28 13:08:17

Re: Is there a way to disable the arrow keys at TTY login?

#6 2023-06-28 15:35:36

Re: Is there a way to disable the arrow keys at TTY login?

#7 2023-06-28 15:40:43

Re: Is there a way to disable the arrow keys at TTY login?

#8 2023-06-28 15:54:23

Re: Is there a way to disable the arrow keys at TTY login?

Board footer