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?

THanks.
QuiteSupersonicAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

http:// thevpn.guruCommented:
This might be a security restriction ..did you try another username ?
0
QuiteSupersonicAuthor Commented:
No, i haven't tried another user name.  But since the root password works locally, i thought it should work remotely, right?
0
vishal_impactCommented:
yes thats true its the security restriction
if you got gnome or kde installled go to system preference and select sttings for the users from them and manipulate accordingly
this should do
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

http:// thevpn.guruCommented:
nope ...most daemons ssh in particular disable remote root logins as a security precaution.
0
vishal_impactCommented:
ok u might need to uncheck the security precaution tht just to test
0
vishal_impactCommented:
ok sorry hold on
how are you connecting and are you using straight away root password
please reply i know y it is stupid me >>>>>>
0
QuiteSupersonicAuthor Commented:
give me a second to try this out guys...
0
vishal_impactCommented:
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
0
vishal_impactCommented:
HI any success
0
QuiteSupersonicAuthor Commented:
Guys this is CentOS?  Is that Linux?  Will these commands apply to that flavor or Linux?
0
vishal_impactCommented:
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
 
0
vishal_impactCommented:
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
0
vishal_impactCommented:
HI
any luck still waiting for the reply
0
QuiteSupersonicAuthor Commented:
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.
0
vishal_impactCommented:
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:
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.
0
vishal_impactCommented:
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
0
TintinCommented:
If they are using ssh to connect as root, then the setting

PermitRootLogin

in /etc/ssh/sshd_config

controls whether this is allowed.  Unless you have a very restricted network, then it isn't recommended to allow remote root logins.
0
vishal_impactCommented:
Basic Linux security measures need to be looked at now - have you been rooted/check all logfiles/etc.

Is SSH timing out, or are you being rejected?

Is this a hosted server? Can you access the traffic logs from the host? If so get them. If the server has been hacked, it's likely to be doing something.

0
vishal_impactCommented:
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.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.