5

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.

2 Answers 2

3
  • 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.

2
  • We don't have a setting for PreferredAuthentications in our ~/.ssh or in the /etc/ssh directory. But it does give me something to look at. I can try ssh with debugging to see if it is stopping at the same authentication method. And if not, why.
    – S. Nixon
    Apr 7, 2021 at 21:03
  • 1
    @S.Nixon did you find out what it was for you? :)
    – Rinzwind
    Apr 15, 2021 at 17:23
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .