Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Possible Duplicate:
Why is “chmod -R 777 /” destructive?

I have CentOS 6.3 minimal installed. No desktop or GUI. All the while, I was able to login as root. Today, I come to work and find the same password no longer works. I was the only one who knew the password and no one in the office touches this machine. I have verified it using CCTV.

When I enter the password it gives me the following error:

centos2 login: root
Password:
Login incorrect

I have tried SSH via Putty as well as WinSCP. I get Network Error: Connection refused.

So what could have gone wrong?

Please advise.

Please Note: root is the only user on this machine. I have not made any other user yet. Or maybe I did but I cannot remember since I have been using root for several days now.

UPDATE: I tried to reset the password following the instructions on some other site. All went well, except I get the same error despite changing the password!

UPDATE: This server is my test server and I try a lot of things on it. The last major thing I did was to select all the directories in WinSCP and give them 777 permissions. Could this have anything to do with the problem?

share|improve this question

marked as duplicate by Michael Hampton, HopelessN00b, EightBitTony, faker, Joel E Salas Dec 21 '12 at 0:57

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
You should not normally be logging into a system as root. The first thing you should do when setting up a system is to create an additional account and grant privileges using sudo. If you are accessing a system via SSH, then you should setup key-based authentication which will work, even if the password is changed. –  Zoredache Dec 20 '12 at 22:35
    
I agree. In my defense, I am a Linux newbie and only started serious work on it last month. I am learning best practices as I go along and after this experience, I am going to ensure I always setup a sudoer and key-based authentication. Thanks for the tip –  Freckles Dec 20 '12 at 22:42
    
Are you logging in as root from the console port and not from a network connection? –  mdpc Dec 20 '12 at 22:50
    
I'm trying to log in on the machine itself as well as from my usual Windows dekstop sitting next to it using Putty and/or WinSCP –  Freckles Dec 20 '12 at 22:52
    
@sajid....try logging in directly on the console for the system, and NOT over any network connection. Reason: there might be blocks in place to inhibit root login from anywhere but the console. –  mdpc Dec 20 '12 at 23:16
add comment

4 Answers

Congratulations, you broke it beyond repair. Your only option at this point is to recover what data you can (try booting from a Live CD) and rebuild the server from scratch.

share|improve this answer
    
This may well be the reason but I am still unconvinced as the system continued to work fine after doing the system wide 777. Maybe it kicked in later. Anyway, the server is working fine as a webserver and Apache/Nginx continue to serve up webpages. Except my phpmyadmin isn't working now but that's not my concern now –  Freckles Dec 21 '12 at 0:26
1  
I'm sorry you're not convinced, but reality will not bend to your disbelief. –  Michael Hampton Dec 21 '12 at 0:29
add comment

Is it safe to reboot the server, or you run some production on it already? I would first check that you have correct keyboard map chosen, and if so, I would probably just change root password using single user boot, or recovery mode, chroot and passwd.

share|improve this answer
    
Hi Marek. Thanks for replying so quickly. Yes, it's safe to reboot. It's a development server and I did reboot it a couple of times already. I had already checked possible keyboard map errors by typing password in the username section to see if the characters appeared any different. The password appeared exactly as intended. I can reset the password if I have to but I'd be more interested in trying to resolve it without having to do the same. I like to get to the bottom of things and therefore would like to know what could have triggered such an event. It's so bizarre and so un-Linux. :-) –  Freckles Dec 20 '12 at 22:38
    
Did you have a secure password? Is the box reachable from the internet? Reset the password and examine the system closely; look in /var/log/messages, /var/log/secure and last/lastlog to check the last logins. –  fukawi2 Dec 20 '12 at 23:06
    
The password was quite secure and it isn't really reachable from the internet. I checked my router and firewall settings. There is no apparent way to enter. I looked at the logs and there is no sign of suspicious activity. All the previous logins refer to known incidents initiated by myself. –  Freckles Dec 21 '12 at 0:46
add comment

I would boot in to recovery mode and check to see if allow login as root is enabled in the ssh config.

File: /etc/ssh/sshd_config
Option: PermitRootLogin yes

While you are in recoery mode it might be with adding a non root account with sudo access so you can try that should you still have issues logging in as root.

If you don't have a recovery option then at boot time you can edit the kernel line at the boot loader screen.

Add

init=/bin/bash

This will drop you in to a usable shell without having to login.

share|improve this answer
    
I logged in as single user by going into the grub menu and pressing e and then typing "single" then b. It logged me in straight as root and then I did, nano /etc/ssh/sshd_config. Strangely enough, PermitRootLogin was commented with a # but it's option is set to yes. Most other lines are also commented with a #. I removed the # for PermitRootLogin and rebooted the machine. Still no luck. –  Freckles Dec 21 '12 at 0:31
add comment

This looks like the root user is being inhibited from logging in over the network. This is likely as part of the default install configurations that I have seen over the years.

Question: Can you login to root from directly from the system console on the machine itself and NOT use any networked login?

If so, then you have the prime responsibility that the tty being logged into the system from is not listed in /etc/securetty file. The system will not give any clue that this is happening for security reasons.

One other idea .. another idea is possible corruption of the /etc/passwd, or /etc/shadow files.

share|improve this answer
    
No, I cannot login on the machine itself either. Whatever I say or do, is being done on the machine itself now. I'm not concerned about Putty or WinSCP anymore. –  Freckles Dec 21 '12 at 0:33
add comment

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