3

I'm playing around, and trying to streamline/harden my tty login prompt to display a minimum of system information. I modified my /etc/issue and /etc/motd to be empty, and touched ~/.hushlogin. That cleared almost everything away!

I was left with the following as a login experience:

hostname login: user
Password:
user@hostname:~$ 

I dislike that it shows the hostname at the login prompt though, and I chased that down. This led me to the man page for agetty, where I modified the service files:

/lib/systemd/system/serial-getty@.service, and

/lib/systemd/system/getty@.service,

adding the --nohostname option to the ExecStart line as so:

[Service]
ExecStart=-/sbin/agetty --nohostname --keep-baud 115200,38400,9600 %I $TERM

This works great, except, when the user enters a wrong password. Then it reverts to the old prompt and shows the hostname.

Successful login:

login: user
Password:
user@hostname:~$

Failed login:

login: user
Password:

Login incorrect
hostname login:

Even weirder, if I leave the console unattended for ~60 seconds after the incorrect login, there's a half-print of the word login, it pauses, then shows the correct login prompt.

login: user
Password:

Login incorrect
hostname login:
Log
login:

Any ideas explaining this behavior? I looked at the source for agetty, and then for shadow (login.c), and I can see where the re-display of the login prompt happens after a fail, but it's referencing PAMs, and I don't really understand that part of the linux system.

This issue was also reported against CentOS in 2015

1

The behaviour is simple to explain, and goes back decades to the very first versions of Unix. getty prints the first login prompt, but if authentication fails, the second and subsequent prompts are printed by the login program, which getty has overlaid itself with by then.

The login program has a limit on the number of login attempts before it simply exits and lets the login service be respawned by process #1. On a system with real terminals that are remote this would have closed the terminal device, causing it to set DTR to zero, in turn causing an attached modem to drop the connection. The idea was to make it hard to guess passwords and accounts by brute force over a remote connection. (It rather hinged upon multiple telephone calls, even at local rates, being expensive for an attacker.) There is also an inactivity timer that causes the same thing. (The idea of this being somewhat different; to prevent telephone circuits being allocated indefinitely by a remote terminal that did not yet have a login session.)

On a virtual terminal, or on a real terminal that is local, there is no modem, no telephone line, and no carrier to drop; and these mechanisms that repeat the login prompt and that set a watchdog are largely pointless. login could simply wait indefinitely with no watchdog, and cheaply exit and recycle the login service on every authentication failure. But they still exist and are still employed nonetheless.

Unfortunately for you, whilst the agetty program from util-linux allows you to configure at least this part of the prompt, the login program from shadow does not. Its login prompt is hardwired into the code of the program.

This is not universal, note. On, say, a FreeBSD system the prompt issued by the login program is configurable by the login_prompt setting in /etc/login.conf.

Further reading

  • Wow, thank you - that's good stuff. I didn't know it went back that far. – user272127 Apr 5 '18 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy