LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 09-05-2003, 10:12 AM   #1
McSmooth
LQ Newbie
 
Registered: Aug 2003
Posts: 5

Rep: Reputation: 0
Question Strange! SSH and Telnet login problem


I've been running Redhat 8 for quite some time without too many problems. Suddenly the other day, I am having problems logging in through SSH with every user BUT root (which I don't want to have to be logging in as). It closes the connection right after the password is entered. I can log in through telnet, but after I do, it tells me that it does not know who I am. Here is what I would get after logging in:

id: cannot find name for user ID XXX
id: cannot find name for user ID XXX
[I have no name!@host homedir]$

Pretty odd considering I just told it my username and it placed me in the home directory but it doesn't know my name. Seems to know my user ID, but can't match it back to a name. Everything else on the machine I have tested so far seems to be working normal. Can FTP in without problems. Here are the entries from the secure log each time I try to log in:

USER sshd[4375]: Accepted password for USER from XXX.XXX.XXX.XXX port 1201 ssh2
USER pam_console[4380]: getpwnam failed for USER
USER sshd[4380]: fatal: PAM session setup failed[14]: Cannot make/remove an entry for the specified session

I'm not sure if this means my user table or something is messed up. It seems to be able to actually verify all users that log in, but problems come after the actual login process. I'm not sure where to go to check on this. Anybody have any idea what this could be or any possible fixes? Thanks!!!!!
 
Old 09-09-2003, 07:25 AM   #2
mvirnig
LQ Newbie
 
Registered: Sep 2003
Posts: 1

Rep: Reputation: 0
Did you ever figure this out? I get the same PAM error, but only when I ftp after a reboot.

If I do a sshd restart after a reboot the problem seems to go away until I reboot again. I haven't had a chance to track this one down further.

Please let me know if you found the root cause or if this helps you.

Thanks
 
Old 09-09-2003, 10:07 AM   #3
McSmooth
LQ Newbie
 
Registered: Aug 2003
Posts: 5

Original Poster
Rep: Reputation: 0
I actually can always log in through FTP. I tried to restart sshd but it didn't seem to make a difference. I still cannot log in to ssh with any users other than root.

?Puzzled?
 
Old 09-19-2003, 09:35 AM   #4
McSmooth
LQ Newbie
 
Registered: Aug 2003
Posts: 5

Original Poster
Rep: Reputation: 0
Well, I def got hacked, figured that much out. I had a guest account I forgot to disable, so I'm guessing someone figured out the passwd and from there was able to crack the passwd file with some program called ASMD. Didn't think it was that simple for someone to do that. What would prevent any user of a system from gaining root access then? Maybe I have my passwords set up wrong? Wasn't too big a deal, they pretty much just cracked the passwd file, created a user with userid 0 and put a dumb "You've been owned" style web page in a directory nobody would ever go to.

Obviously I need to enforce strong passwords on all accounts and I got rid of any accounts and pretty much disabled all remote access on telnet/ssh. Not sure where to go from here though. Can you just rebuild the password file from scratch or do you have to reinstall programs that handle this? Just trying to figure out a better way to do this other than reformatting.
 
Old 09-19-2003, 12:13 PM   #5
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
Well, I def got hacked, figured that much out.
Sorry to hear that. Shame some people have to learn securing their boxen the hard way.

What would prevent any user of a system from gaining root access then?
If they got the passwd then they already had root access at that point.

Maybe I have my passwords set up wrong?
Shadow passwords are default I guess by now, but what's equally important is to look for "troublesome" applications and services you run. Not installing, removing or hardening those (last in case you need them) is a start. If you've got questions about securing your box, head over to the Linux - Security forum.

Just trying to figure out a better way to do this other than reformatting.
It's all about trust. If you didn't set up your box with simple auditing in mind, chances are you'll never know exactly what they did on the system in the first place. "Ergo" you can't trust the box.
Thinking you can dodge reformatting and reinstalling (you know the mantra) is wishfull thinking, trying to figure out "a better way" is a waste of time which in the end will not provide any solution.
 
Old 09-23-2003, 09:31 AM   #6
McSmooth
LQ Newbie
 
Registered: Aug 2003
Posts: 5

Original Poster
Rep: Reputation: 0
Thanks for the insight and comments. I'm not sure if I explained what happened correctly though. I know that they gained access through an account that they most likely had a program guess the login and eventually got it. From there they ran a program that creates a user with user ID 0. So what I was wondering is what keeps any user that already has access on any system from doing this and screwing everyone over? (say a customer gets fed up with their hosting companies support or something)

I know exactly what happened, a little detective work and going through logs shows that, just wasn't sure how to fix the original problem where no user can log in. Wasn't sure exactly what needs to be reinstalled to correct this. It looks like the program corrupted the password file to some degree, but I'm not too familiar with this, so maybe I can find something in the security section.
 
Old 09-23-2003, 01:09 PM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
Thanks for the insight and comments. I'm not sure if I explained what happened correctly though.
No, but then again the majority of the people doesn't. Since I stumbled on this thread way too late to begin any diagnostics I decided it best to fire off at least some warnings about what *not* to do. Especially since you seemed bent on ahhhh, "fixing" the system. Bad idea. Don't.


I know that they gained access through an account that they most likely had a program guess the login and eventually got it. From there they ran a program that creates a user with user ID 0.
I'm not gonna shout but the details you leave out are the important ones to me. What account? Default system account installed by an application? Could you show some log entries? What's the username? Was the passwd/shadow file modified close after the log entries started or way later? Any other details or evidence?


So what I was wondering is what keeps any user that already has access on any system from doing this and screwing everyone over? (say a customer gets fed up with their hosting companies support or something)
The situation you describe is IMHO mainly a perception problem. It's usually neglected because it's easy to overlook as an attack vector or underestimate the risk. Then there's erosion of policies and bad administration (whatever the cause is, stress, lack of knowledge, management pressure: none are valid reasons) which "helps" as well. One of the other things people have fun with is social engineering, but that's another story.


To protect the system against local attacks there's unfortunately no default or generic solution, and it should partially depend on the tasks they need to perform. For instance, if users don't need to run servers on that box, why give them the rights to do that? Grsecurity(.org)'s kernel patches can take those rights away. Same for client sockets. Should they be able to access the whole filesystem? If they don't, and you don't want them floating in a chrooted jail, then both Grsecurity and LIDS can "mask" parts of the filesystem. Should *anyone* be able to see others processes, run more than X processes for time Y, load/unload modules, use the loopback device to gain access to a daemon etc etc? Note I said "partially" before, because I'm not talking about *human* users only. Most of it can apply to system users and some privileges can be taken away system-wide. A healthy distrust of applications (not only the network facing ones) that need special privileges, mounting partitions read-only, using the extended attributes (only available for those who chose to use ext{2,3}), using sane access methods and permissions across the system and regular auditing of the filesystem and logs are just a few of the means you got to make and keep your boxen sane. Most of the time security is a trade-off.
Just make it a calculated one.


If you've got questions, don't forget we've got an excellent search feature and the security forum has some kind of FAQ with lots of links to good reading material.
 
Old 10-03-2003, 09:24 AM   #8
McSmooth
LQ Newbie
 
Registered: Aug 2003
Posts: 5

Original Poster
Rep: Reputation: 0
Thanks for all the tips. I've learned quite a bit for reading stuff through here too, including a lot on security, but as I mentioned, the only reason someone got in was because of something stupid I forgot to do - my fault. For the most part, I know everyone instantly says, reinstall everything. I can do that anytime, but before I did that I just wanted to know how to fix the user login issue. I'm not sure if its just a corrupt passwd file or if I need to reinstall something like pam.

As I mentioned above, they gained access through a guest account (just a regular user but easy to guess the password) that was set up for testing initially but was never disabled. From there they uploaded some files for some script that basically hacks the passwd file and adds a user with ID 0. I'm pretty sure it was this program that messed up the login. It appears from the log that they didn't do anything other than modify a web page on the site and it was aparent that their cause was not mallicious (they even backed up the index page they were replacing for me, haha).

Again, all I really was asking the whole time is if anyone knows the best way to fix a login problem. Can you just recreate the passwd file from scratch, or is there something that could be reinstalled? thanks.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Automatting Telnet or SSH Login prashant_1012 Programming 6 09-12-2005 02:26 PM
SSH/Telnet, disable root login, how? muhazam Linux - Security 6 08-17-2004 12:49 PM
strange telnet problem! sh3ll Linux - Networking 4 07-14-2004 02:22 PM
ssh and telnet problem dbratton Linux - Newbie 0 03-17-2004 01:45 AM
Telnet and ssh login message digitalgravy Linux - Newbie 7 01-07-2004 10:35 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 01:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration