4

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.

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 at 21:03
  • @S.Nixon did you find out what it was for you? :)
    – Rinzwind
    Apr 15 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.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.