Home / ubuntu / Questions / 1329917
Accepted
S. Nixon
Asked: 2021-04-08 10:48:01 +0800 CST

Is there a way to change the default login/password prompts?

  • 772

Just noticed something odd happened to two of my Linux servers. We have two dozen Ubuntu 18.04 LTS servers, and all of them ask us for a prompt in the same way:

# ssh admin@pl3poland
admin@pl3poland's password:

However, we recently started enforcing stronger password requirements on two servers. We changed the settings in /etc/pam.d/common-password for libpwquality.

Before:

password        requisite                       pam_pwquality.so retry=3

After:

password        requisite                       pam_pwquality.so retry=3 minlen=12 difok=3 minclass=4 maxrepeat=2 dictcheck=1 usercheck=1

It seems that after these values were changed, now the password prompt shows up differently. This is what comes up now:

# spawn ssh admin@spain
Password:

This is a relatively minor difference, but it has affected a few of our automated routines where we use expect scripts to connect to systems. I've changed the script to look for "sword:" instead of the full "password:", but I'm just curious why that would change, and if there is any way to change it back?

Looking through documentation, I found a command called "password-prompt" but it does not look like that is something I can use to permanently set the password prefix.

Anyone able to direct me to a .conf file or some documentation that explains how to change this? I come from an AIX background, and there was a file called /etc/security/login.cfg that we could change to adjust the "herald" for each login. But I don't see something similar in Ubuntu.

Thx

Steve N.

login

2 Answers

  1. Best Answer
    • user@server's password is used for password authentication
    • Password: is used for keyboard-interactive authentication

    Both are set with an SSH option:

    • PreferredAuthentications=password
    • PreferredAuthentications=keyboard-interactiv

    as definied in rfc 4252 and rfc 4256 so it is unlikely related to a change in /etc/pam.d/common-password and more to do with a change in .ssh/config and the setting PreferredAuthentications or by setting it with an option with ssh -o.

    • 3

  2. It looks like the problem was exactly what Rinzwind had indicated. Using the ssh -vv debugger flag, I was able to see that Ubuntu Server #1 (polaris) was stopping at the "password" authentication method, while Ubuntu Server #2 (spain) was

    To demonstrate, here is the tail end of the debugger login session:

    debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /.ssh/id_dsa
debug1: Trying private key: /.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
admin@polaris's password:

    Versus the one on my spain server:

    debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /.ssh/id_dsa
debug1: Trying private key: /.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

    Now for my own curiosity, I should really spend the time to find out why one is using password while the other is at keyboard-interactive. I suspect it is an issue with the id_rsa.pub or authorized_keys entries. But I have not had the time to research it further.

    The solution we came up with to fix our expect scripts is to simply look for "assword:" instead of "password:" that was used previously. That way, if we run into the issue again, the automated routines will continue regardless if we get "Password:" or "password:" as part of the login string.

    • 0