Hey guys playing around with a mammoth VPS and forgive me if its something silly i am missing but i am in need of root access to the server, running CentOS and not very knowledgeable in Linux at this stage. The FAQ on www.mammothvps.com.au while good, isn't a huge help.
The commands offered are
sudo passwd root
to set up a root password on the account, however the error returned is
sudo: must be setuid root
To explain a little better I have installed cPanel / WHM for learning purposes / something to entertain my brain & for initial logon to setup it is requiring root login and password:
To access the WHM interface:
If someone could tell me where I have gone wrong, anything I have missed or if there is 'possibly' an easy solution to this problem then I would love to know.
You don't learn if you don't try.
Many Thanks in advance for taking the time to help a guy forward himself.
I've never come across that exact issue myself, but I think if you do this you should be able to enable a password on the root account:
sudo su -
^^ you'll probably get prompted for your vps password and then become root
now you can just run:
^^ to set a root password
be aware that this isn't a recommended practice, you're better off having the root password disabled
Hmm but my problem is that it looks as if WHM has created the default login as root & whatever the password was.. which I could avoid if i went back and changed root password pre-installation..
I will try your suggestion, thanks Jim
what output does
ls -l `which sudo`
so you can't do anything via sudo at all now? at first I thought maybe sudo just gave that error specifically when trying to change the root pass with it, but maybe this cpanel thing has actually removed the setid bit from the sudo binary - it should be "---s--x--x"
Habib ls: which: No such file or directory.
You used single quotes instead of tilde (quake console key)?
Looks like you found the file anyway.
ah yeh it has now I see your last post
Habib ls: which: No such file or directory.which isn't installed as part of core-utils, so it misses out being included in our minimal image. there's several commonly-used utils like which (such as man) that aren't included and you tend to think wtf when you notice them missing, but they're trivial to install with the package manager and it means the customer gets the choice about what chews up their precious disk space
does the mammoth control panel let you see the screen while it's booting and take control?
if so, you could put it into single-user mode and fix things up:
* wait for GRUB splash screen, press a key to get to menu if you have to
* look at instructions below the menu and press the key that lets you modify parameters
* add a "1" to the end as an extra parameter (no quotes), it should log you in as root
* run "passwd" to set the root password
* run "chmod 4111 /usr/bin/sudo" to fix the suid problem
* run "init 3" (console) or "init 5" (starts X11 if you need/want it) to start up normal services and go to multi-user mode
andrewus: can you confirm whether you can no longer either:
- use sudo to run commands as root
- become root from the shell or at least via this cpanel thing
if you can't do any of the above, this thing might be a bit dumb in that it can get installed via sudo, but then doesn't know how to operate without the root account and already disables any existing sudo users
if that's the case, you might need to reinstall your default image and try again, but this time enable a password on the root account before you try installing cpanel
either that, or if you're willing to have your vps shut down for a few minutes, I can mount your filesystem from the host and edit your shadow file directly, and then umount it and start your vps back up again which means you wouldn't need to reinstall. if you want me to do that, create a file in the vps user's home directory called password.txt or something, and inside the file, enter a temporary root password you want me to set for you.
but, log into mpanel and use the 'contact support' link so it creates a ticket in our system and I get verification that you own the vps you're asking me to meddle with
habib: yep it does, but atm we only provide the kernel from the host, so grub isn't used - I'm not sure if that method is possible
Jim i am unable to sudo or become root.
I can afford to have the VPS shutdown for a while as its not got anything on it yet. If you are willing to mount my file system and edit it, this might save me another 1gb of bandwidth.
I have had to do 2 reinstalls of cPanel already today. I will do as instructed.
No probs, I see the ticket, doing it now
heh no probs, I happened to be at the pc anyway
All done, responded to your ticket with details
Can these be used to packet important international networks with? DDoS botnet buyins are getting expensive and I still have some old scores to settle with zee Russians
I want Jim to mount my filesystem..
I want Jim to mount my filesystem..
and root it ?
lame, but thats all i got.
hey just if I could ask one more question. Attempting to setup quotas and am getting the following:
the sites are still saying unlimited space & google is not being my friend :(
I've never tried cpanel sorry
not sure whether you need to make sure the filesystem is mounted with quotas enabled yourself, or whether cpanel modifies your /etc/fstab for you but it sounds a bit like it's not mounted with quotas enabled
FYI i had no issues doing what jim said in the second post, when i changed/setup root on my CentOS server.
Getting pretty hammered with SSH Brute force attemps, ive setup fail2ban atm using IPTABLE banning 2 SSH failures for a week.
You can change the SSH listen port to put as a crude way of mitigating the brute force robots. It won't stop evil humans, so the bans are a good idea, but it seems to do a good job of stopping your log from filling up with spam from brute force attempts on port 22.
last edited by Habib at 00:10:57 22/Apr/10
Yeah, I've got zero failures recorded, I suspect because I'm not running ssh on the default port.
Someone mentioned you can avoid the issue entirely by using keys instead of passwords, but I don't know how to set that up.
yeh personally I like running it on another port to avoid all the log annoyance
internally when we were discussing what to do with ssh in our images we decided to leave it on the default port to avoid complicating it for customers, and chose instead to disable the root password and provide a sudo'd default account which should greatly reduce the chance of bots bruteforcing without adding much complexity for the customer. this is pretty standard practice for several distros now anyway so most people will hopefully be used to it
once they log in they can then reconfigure things however they like, alternate ports, firewalling etc
chose instead to disable the root password and provide a sudo'd default account which should greatly reduce the chance of bots bruteforcing without adding much complexity for the customer.
and is a little annoying at times... but customer support pwns.
Will look into this SSH port change though, sounds good.
/edit ssh port change = easy
You can put a password back on if you like andrewus, its just disabled by default.
You may like to just login as your vps user and then issue:
sudo su -
You then get logged in as root@yourvps
Yes Plasma but my problem was that once cPanel is installed it breaks SUDO permissions and therefore doesn't allow this, hence needing Jim to do what he did and fix it for me.
In hindsight it would have proven smart to ensure a Root password existed prior to installing cPanel. But there was no way of knowing this being first time user.
Also Trog I just edit the sshd config & just be sure to have the ports open on your firewall before you restart the server, otherwise fun times ahoy!
That reminds me, I need to change my ssh port. What is an easy/safe way to do that without locking myself out? I assume I just update the sshd.config or whatever and kill -HUP the sshd daemon?
centos, ubuntu, debian and opensuse's sshd init scripts all provide for a full restart while logged in, without dropping you off (the process your are connected in to is left alone):
- edit sshd config, change port
- use service or init script to do restart
- test login from another client on new port
- if it worked, disconnect old one
jim awesome, thanks, worked fine
1) edit /etc/sshd_config and change the 'Port' line (note: /etc/ssh_config is a different file, which I found out when nothing happened the first time)
2) cd /etc/init.d
3) ./ssh reload
My main connection stayed alive, then reconnected fine to the new SECRAT PORT
Remember Security through obscurity isn't security.
SSH Keys is another way, but if your like me and move around alot using lots of different computers just set up SSH to only allow specific accounts to login, disallow root and use strong passwords that aren't dictionary based and have numbers letters and special symbols.
in all fairness, habib already covered the fact that changing the port doesn't provide security - it provides far less headache for log monitoring and alarming though
there was a good article on slashdot about this a while back:
Moving SSH does nothing for security
I disagree; I think I've side stepped a lot of attacks I may normally get because of it.
Its a lot more expensive to port scan every host to first see they're even running SSH, instead of just moving on to the next one and trying the default port.
I disagree; I think I've side stepped a lot of attacks I may normally get because of it.No you just moved the problem away from script kiddies with out dated scripts. As the article that Trog posted from /. points out there are many methods for delaying or stopping force attacks, personally I just Ban IP addresses that attempt more times than is humanly possible.
iptables -N autoban
iptables -I INPUT -p TCP --dport 22 -j autoban
iptables -A autoban -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A autoban -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
example from the post, 4 trys in 60 secs and you banned.
No you just moved the problem away from script kiddies with out dated scripts.Well the only real measure of whether this is true or not is to find out how many attempted logins are made AFTER you've changed ports. I have only just changed so don't have data, but maybe plasma does. If he now gets zero login attempts, then it clearly does sidestep the attacks!
edit: now I want to log it. I have the default sshd logging settings:
I would expect that to log in to /var/log/syslog but there's nothing there?
edit#2: I'm a retard, now I see auth.log
I think we just have two different takes on 'does nothing for security' here
imo it doesn't actually do anything for security - it just tends to reduce the number of attempts
edit: further on this, I mean that while the end result may be that you escaped being compromised where you otherwise might've been, it wasn't actually because your host was more secure
imo it doesn't actually do anything for security - it just tends to reduce the number of attempts
+1 moving the port doesn't improve the service from attacks, it just obscures the initial attempts which blindly attack port 22, any "real" attack would port scan your ass and attack all ports.
Iif you view security in terms of number of attempted logins, then moving ports helps a lot.
If you view security as protecting against a determined human, it clearly does nothing.
If you have a personal VPS (as I do), then simply picking a strong password or (preferably) enforcing public key authentication will give you enough security. So for me on my personal not-for-business VPS, I never look at those logs because I dont care.
This is what I am currently using
you can set it up to ban more than just ssh failures, sends email on banning also so if your worried you can pp onto your site an cehck etc.
Monday morning had 10 different ip attempt access most seem like hacked webhosts
OK personal opinions aside...
Security regardless of how a server that is directly connected to the internet should be similar to a point, bad practices are bad practices. However viewing obscurification as security is a common misconception held by too many people in IT. just because you reduce the likelihood of an attack by moving a port means you are still vulnerable be it reduced, security is to make yourself less vulnerable from that type of attack, in this case brute force password attacks.
So regardless of personal or business, for the small amount of administration required to configure SSH properly vs the harm that can be done by a compromised machine, always choose security over obscurity.
1. Disallow root login.
2. Only allow specific users to login.
3. Choose a strong password.
4. Set IPTABLES to BAN excessive attempts.
5. Make sure SSH is up to date, especially if you use Ubuntu < 8.10.
How hard is that?
PS : Never run Web servers or other Web based services as a privileged user (root).
last edited by GumbyNoTalent at 15:18:25 22/Apr/10
Nice list Gumby.
I would also put on the list regularly cracking your own password file to check for common simple passwords being used. Get yourself a large word list and the latest "John the Ripper" and run it overnight. Make sure you find a word list with the same words used by the SSH brute force tools to make sure the basics are covered but don't just stop there, make further word list additions from the websites of your customers, just in case they are a self referencing in their password choices.
if you're that paranoid about security pop an IDS instance and spool the output into Splunk which you can then nicely graph all the noise using Afterglow or just output to (pick a graph type) chart to oogle over.
Snort probably has anomaly-based inspection and restriction down to a T by now so it saves you dropping into a shell and updating your iptables ruleset if by chance you don't hardconf them in (thinking reboots wouldn't need to happen all that often but you did say you were a little noobish so...)
cpanel is a bit of a one way install unless you know how to surgically remove it after it's done fsjacking a perfectly good rhel install, found that one out the hard way after borrowing some fancy regex from it that I couldn't have been bothered writing myself ;(
last edited by trillion at 19:47:54 22/Apr/10
"The Spinning Cube of Potential Doom or How to Keep Jaded Conference Attendees Mesmerized While Hopefully Teaching Them Something"
last edited by trillion at 21:29:02 22/Apr/10
last edited by trillion at 21:35:57 22/Apr/10