Skip to main content

As more and more people start using SSH in place of Telnet, I am seeing more and more confusion over the way that the SSH daemon treats password warning, expiration, and grace times. Part of the confusion is caused by the incorrect expectation that SSH will duplicate the behavior of Telnet and the login command. This blog is an attempt to explain how it works.

First, remember that SSH comes from the world of Unix/Linux and that world does not have the 7 day pre-expiration warning with option to change the password that the VOS login command provides. The original release of the SSH daemon did not provide this warning/option either.

Starting in release 2.0.0e (bug fixes ssl-205 and ssl-268) this behavior was changed so that the SSH daemon asked for a new password 7 days before the password was set to expire, just like the login command. However, connections setting up a tunnel would hang at the change password request because the request was never displayed to the user. The problem was that tunnel setup usually does not allocate a pseudo-terminal so there was no place to display the prompt.

So starting in release 2.0.0k (ssl-295) the SSH daemon was changed back to its original behavior. An external variable was added to the code to allow sites to enable the pre-expiration change password prompt if they want it. This is done by setting the sshd$pw_change_method variable to 1.

Note that the behavior of the SSH daemon when prompting for a new password during the 7 day warning period time is different from login’s behavior when connecting with Telnet. Telnet/login allows you to just press the return key to skip the change password step. The SSH daemon requires that you change the password. The behavior is different because of the way that the SSH daemon is changing the password. If you add the change_password argument to the login command you are also not allowed to skip the change password step. This is basically what the SSH daemon is doing. The bug ssl-279 describes this difference in behavior but has been deemed not a bug by Engineering. One other thing you may notice if you login with both Telent/login and SSH is that Telnet/login will report that your password will expire in N days while the SSH daemon may report that your password will expire in N+1 days. The behavior depends on the time of day of the last password change. This has been reported as bug ssl-368.

The above discussion deals with the time during the 7 day warning period. What about during the grace period (defined by the password_grace_time value of the login_admin command)? During the grace period the SSH daemon allows you to login using the old password and requires that you enter a new password, just like the Telnet/login. However the message that the SSH daemon displays is a little misleading. It states that your password is expiring soon. The suggestion ssl-366 has been entered to request that the message be changed to indicate that your password has expired. However, regardless of the message the end result is the same – you must enter a new password.

The final time period to consider is after the grace period. During this time the SSH daemon appears to allow you to login using the old password and it prompts for a new password, but after entering the new password it terminates the connection. The Telnet/login command will terminate the connection after you enter the old password. This is documented as suggestion ssl-367, the SSH daemon should not prompt for a new password.

There is another difference between the Telnet/login and the SSH daemon behaviors when changing a password. After changing the password the SSH daemon will disconnect the session, requiring you to reconnect and login with the new password.

Finally, one more bug that needs to be discussed. If the req_change_first_login parameter as displayed by the set_login_security command is set to “yes” then the SSH daemon will treat all passwords as not expired regardless of their actual state. This bug, ssl-361, is fixed in release 2.0.0u and it is recommended that any module with the req_change_first_login parameter set to yes upgrade to at least this release immediately.

Since the sshd process forks a new process for every connection it is possible to install the new version of the sshd.pm file without forcing all SSH connected users off the system. To do so you need to

  1. Change directories to >system>openssl>sbin
  2. Rename the running sshd.pm file to original_sshd.pm
  3. Move a copy of the new sshd.pm into the current directory
  4. Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
  5. Switch to the root user with the switch_to_root command. You will need to know the root password.
  6. Start the new sshd process. If you are unsure how to start sshd check your module_start_up.cm

The procedure to just change the value of the sshd$pw_change_method variable is almost the same. Steps 1, 2, 4, 5, and 6 are the same but step 3 changes to

3.  Copy original_sshd.pm to sshd.pm

and a new step 3a is added to actually set the variable

3a.  Execute the command

“set_external_variable sshd$pw_change_method -in sshd.pm -type integer -to 1”

© 2024 Stratus Technologies.