I applied some O/S patches to a Sun Solaris 8 system last night, and now when I try to login using ssh I get asked for my username, and after entering it and hitting enter, I get disconnected. ssh -v from another system doesn't provide anything that's meaningful to me (I'm a DBA, not a sysadmin) but I can post that output if it'd help. It happens on all users, so it's not just me.

I've reenabled telnet, so I'm not pulling out any hair, but I'd like to get this fixed.

Thanks.

I applied some O/S patches to a Sun Solaris 8 system last night, and now when I try to login using ssh I get asked for my username, and after entering it and hitting enter, I get disconnected. ssh -v from another system doesn't provide anything that's meaningful to me (I'm a DBA, not a sysadmin) but I can post that output if it'd help. It happens on all users, so it's not just me.

I've reenabled telnet, so I'm not pulling out any hair, but I'd like to get this fixed.

Thanks.

Could be a PAM problem....

Noticed all the PAM files were dated yesterday, but diff showed them to be the same as before. I actually may have fixed the problem. I went to my favorite source for unix sysadmin documentation (google) and found a reference to the known_hosts file. It was dated yesterday also, so I copied one from another system in its place, and I can get in again.

Thanks.

What's PAM?

Sounds like you may have regenerated the host keys as part of the patch process. Clients cache the keys for servers they connect to and if the next time the key is different BLAM! no login (it is interpreted as potential host spoofing by an intruder).

The "-v" option can be very useful as you can get diagnostic error messages from situations like this rather than utter silence.

So you probably deleted known_hosts? Or did you just delete the line for the host in question?

I renamed the original file and replaced it with a file from another server. The file itself appears to be encrypted; I'm guessing there are utilities to manage this, but I don't know what they are.

You're right about the -v option. When I added that, I got enough "other stuff" to add to my Google search to come up with some ideas on what to look for.

The known hosts file is not exactly encrypted, it just contains public keys that appear to be encrypted.

With some SSH clients you will be prompted to accept any new hosts you connect to if they are not in the known hosts file. Thus the file can be built back up from scratch without too much adverse impact. I would not bother with the renaming and copying, I would just delete it. Or for more advanced users, if I remember correctly, the file consists of one line per SSH host and the server name is part of the line. So you should be able to edit and delete the particular host's line with a decent text editor.

Can you tell I'm not a sysadmin yet?

I'm used to seeing the prompt for unknown keys and adding them. The weird thing about this is that I am trying to ssh TO this machine and it was disconnecting. I don't know why the known_hosts file has anything to do with inbound connections, but it must.

I'm not a sysadmin either... I just made some additions to an embedded implementation of an SSH server.

I would not have expected known_hosts to affect inbound connections either. May depend on the server implementation. Probably used to make sure there is no spoofing of client systems either. Some of the "secure" software and systems do go to what seem rather extreme measures.

PAM is short for Pluggable Authentication Modules; a lot of stuff can use the modules (it is kind of like IPtables, but not quite)- samba, ssh. It gives more "flags" to work with for security stuff.

I'm glad you got it fixed...I really like working with Linux (Unix, kinda), but I'll say one thing about it. They (Linux, Unix) are kind of like the hot-rodders OS. It takes tweaking and messing with, but once you get it where you want it, its great! The fact that you can customize it is what makes it neat. Just ask all those kids in Finland who use it ;) !

PAM is short for Pluggable Authentication Modules; a lot of stuff can use the modules (it is kind of like IPtables, but not quite)- samba, ssh. It gives more "flags" to work with for security stuff.

I'm glad you got it fixed...I really like working with Linux (Unix, kinda), but I'll say one thing about it. They (Linux, Unix) are kind of like the hot-rodders OS. It takes tweaking and messing with, but once you get it where you want it, its great! The fact that you can customize it is what makes it neat. Just ask all those kids in Finland who use it ;) !

I'm thinking flames and Cragers on all my database servers...

LOL! That would actually look pretty cool :D! People do custom paint jobs on computer cases, so why stop there?! :D

Just a thought - in order to "fix" the known_hosts issue I had to bounce the sshd process (kill -HUP pid), maybe this bounce of the process fixed my login problem and the file itself was ok...

I doubt it although it may have been required too.

My $$ is still on a key change which would have been in the file.

sshd has to be restarted/SIGHUP'd to re-read its config file. If something changed in the updated config that involved auth, then you would've had to restart the daemon for new sessions to work. A simple update patch, however, should generally not have done things like change the auth system. :)

The known_hosts file is consulted *before* you send your password, but after you enter your username (if a host has been compromised, you generally want to know that before you send all of your auth information to the "man in the middle"). So, given that your connection was being dropped after the username but before the password stage, that file was very likely the culpreit.

For future reference, it's perfectly acceptable to go through known_hosts and delete individual lines from the file if you change a server certificate (though, a good admin will back up the server certs so users don't have this hassle). Just find the line that begins with your destination's host name and delete it, then find the one that begins with your destination's IP address and do the same.