Linux drops session after asking me to change my password
 

I just recently uploaded putty in order to access my Community College's Linux sever- I had access before to the said server and was using a different laptop at that time. I am able to log in my username and temporary password, however, after doing the said steps, I am then directed to change my password. When I type in my new password and press Enter the session drops and screen goes away. Any thoughts?

There's no way anyone here can even guess at this. This is a server at the community college...we've got NO IDEA what security measures are on that box, why they're there, or what they do. This would be a question for either your professor or the IT folks at your school.

Depends on how the login goes.

Kerberos, for instance, will force you to provide a new password anytime the current password is expired (which is the standard handling for temporary passwords - just mark them as expired). This is all done before you actually get a session. Once you have given a password change, the session drops, to force you to USE your new password.

The better way is to use Kerberos on your workstation, then get a credential via kinit (which will also require password change if it is expired). Then use putty to connect. I believe the current putty recognizes and uses kerberos credentials when available.

The advantage this has is that NO password ever crosses the network. kinit uses the password locally to decrypt a message containing credentials (which has more credentials encrypted within it). When you attempt to connect, putty uses the host name to request credentials from the KDC for that connection. These tickets have a limited lifetime but can be reused within that lifetime.

This sounds perfectly normal (almost) to me. When you ssh into a server, are prompted to change your password, you do, then you normally get logged off with the expectation that you will login again using your newly changed password. Normally you are just prompted to login again, in the same window you were in before, without the "session drops and screen goes away" part however. Geez, I do this all the time (I have logins on dozens and dozens of servers where I have to change passwords), but I can't remember the details of "the screen goes away". I don't believe it goes away, but now that I think about it, well, maybe it does. IIRC, I just get a new "login:" prompt in the existing window however.

Are you saying that on your second login attempt, using the NEW password, you are being prompted to change your password AGAIN? That is not expected. I would think that might be a misconfiguration in the login setup or password aging settings. Talk to your sysadmin if you suspect this.

Thanks, TBOne and jpollard.

To answer your question, haertig: when I go back into Linux, I can Not use the new password. It only takes the old password (the one it wants me to change). Thanks for your response, as well.

That sounds like a failure on the server - as in the utility doing the password change doesn't have the necessary privileges/permissions to make the change and gets aborted. And if the user session hasn't been started (a shell), the abort causes the sshd service to terminate.

There should be some logs on the server to identify what is happening.

I have seen this happen on Solaris boxes when the username is longer than 8 characters. When you login and attempt to change your password, your real username (longer than 8 characters) is truncated down to the first 8 characters, and thus the password changing fails because it is trying to change the password of a non-existant userid. This is a problem when you are at the point where the "passwd" command is automatically being invoked for you, as it would be in your ssh login scenario. In this case, you have no control over how "passwd" is called.

Normally, when you call "passwd" it tries to change the password of the current userid, and on some systems, this would be the 8 character truncated userid. The solution is to call password and explicitly give it your long userid. e.g., "passwd longusername" instead of just "passwd". However, you don't have this option when it is ssh that is invoking "passwd" for you. The only way I know out of that dilema is to have the sysadmin change your password for you. Then ask the sysadmin to create you a new, shorter, userid. I haven't noticed this happening on Linux boxes nor on recent Solaris boxes. However, I have been in the habit of only creating userids that are 8 characters or less for some time, and I may just be masking the problem by doing this.

It used to be problem at 8 chars for passwds on eg very old Solaris etc; not uids (which are typically 3 or 4 digits).
It shouldn't be using the username field under the covers; just for display purposes.