COURSE of the MONTH

Linux (centOS) root password not being accepted via remote connection

I can connect fine with the root user and password locally, but when our vendor tries to dial in (not via VPN, but via a pinhole in our router) using the same user name and password, this generates an access denied error message. Any ideas?

Who is Participating?

One of the greatest vulnerabilities in Linux is allowing root to SSH remotely into your server. The root account is a known master userID, and you will see many attempts to log in as root from the Internet, attempting to brute-force their way into your system. There is really no reason to have to SSH directly as the root user. Instead, what you should do is SSH as a non-root user to the box, and then su or sudo to root, which allows you to temporarily become root or run a single command as root, depending on how you execute it from the command-line.

The SSH daemon is controlled by a file: /etc/ssh/sshd_config

This file controls all settings for the SSH daemon. This is the "SSH server" that allows you to connect TO your server, but has nothing to do with the SSH client on your server, which allows you to connect from your server to another machine (the connecting machine is always considered the client).

First, make sure you don't lock yourself out of your box. Test to make sure you have sudo or su - permissions. Try both of these as your non-root user:

$ sudo bash
(enter your non-root user's login password when asked)

If you don't get an error and are presented with the root prompt (# instead of $), you're good to go. If that fails, try su -:

$ su -
(enter root's login password)

Same scenario - no error and # prompt is what you're looking for. If both of these fail, you need to edit /etc/sudoers and make sure your userID is in the admin group (if not, add it to the admin or wheel group in /etc/group), and then try the above again.

Next, make a backup copy in case you jack something up, it's a quick copy & SSHD restart to get back to where you were...as root:

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old

Open /etc/ssh/sshd_config in your favorite text editor, such as vi or pico or whatever, as root. Lines beginning with a # are commented out (disabled).

Find the following lines and make sure they are not commented out. If they begin with a # sign, then delete the # sign to enable the setting.

(1) First, protocol. This tells SSHD what versions of SSH encryption to accept, and in what preferred order. It's basically a handshake/introduction process where the server and client announce what languages (ssh versions) they speak, and they agree on the strongest/preferred version they both speak. Your protocol line may look like this:

Protocol 2,1
if so, change it to:
Protocol 2
to disable SSH1. SSH1 is vulnerable and insecure and should never be used under any circumstance. From a tool perspective, it is no harder to sniff SSH1 traffic including passwords, than it is clear text.

(2) Disable root SSH. Your line may be commented out or may actually be permitting root login (PermitRootLogin yes). This is A Very Bad Thing.

Change it to:
PermitRootLogin no

You will SSH as a regular user with su or sudo access and change to root only as needed.

You should google for "ubuntu SSHD security" or "SSHD hardening", etc. for more details and a better understanding of the need for security.

I also suggest that you change the default port your SSHD is listening on. Recent posts discuss how and why to do that, and how to connect to your box on a non-standard port. This is probably the best security measure for a box "in the wild" such as a VPS.

Restart SSHD to apply the changes:

one of these two (can't remember which Ubuntu names it):

# /etc/init.d/ssh restart

or

# /etc/init.d/sshd restart

Linux is very, very smart. When you are connected via SSH and restart SSHD, it protects your current session rather than kicking you offline. This is of vital importance if you break something. Leave your current connection open, and establish a NEW connection. If you can't get in, then use your current connection to fix SSHD and try again. Do NOT disconnect your current SSH session -- if something's busted, you're locked out.

If it breaks something, copy your backup and restart SSHD:

# cp /etc/ssh/sshd_config.old /etc/ssh/sshd_config

# /etc/init.d/ssh restart

You've lost all your changes, but at least you're not locked out of the box. Try again and watch for typos, etc.

ok
Let me tell you somethig first via command line through vpn remotely if you are using putty or anything login as nomal user then after login try using command su root
it will ask yuo for password and type the password and you are done
LOLZ
security settings are like this by default
sorry for creating confusion in all begning
thnx

yeh
the su command is for switching user
and basically if you are using putty via vpn or something then u need to login as normal user not root and then use su command as su root to get in to root
as this is what i do daily to get into my remote server which is centos as well

hi any luck
can you please select yes from right hand side of is this what you were looking for ?
so other users can get this solution as well
much appreciiate thnx
and let me know after doing tht if need any more help

Ok, i tried something. I tried logging in through putty locally here on the same subnet, to test the other non-root account. This worked. So i called the vendor to have him log in through the test account first, and then hopefully have him be able to use the "su" command as mentioned. He couldn't log in through the test account though. Where's the security settings which apply to remote logins being mentioned before? Thanks.

ok
sorry but can you confirm that he can login with any other normal user account via vpn or tell me how is he connecting
please reply promptly as i am concentrating on your issue fully as its jus matter of few minor things
thnx

0

QuiteSupersonicAuthor Commented: 2008-02-06

i created a rule in our router which allows port 22 (ssh) traffic to one IP address on our network, the CentOS server. He cannot log in with the root account or a test account. He does get prompted for a user name and password, so i know he's got basic connectivity.

ok then the best way to check is to go to system preferences on top toolbar and select usermangement or something
that will give you options the users have with login
make sure you login as root to do all this
soory cant tell you more as i dont have my linux running herelet me know the option you get as i can tell you after tht