Imagine my surprise when it only worked on one server and not on the other. I’ve dug deep and wide. Took a break. And dug again. Then, I’ve summoned the great troubleshooting powers of my brother<\/a>. But even those didn’t help.<\/p>\n Lots of logging, diff-ing, strace-ing, swearing and hair pulling later, the problem was found and fixed. The issue was due to two separate reasons.<\/p>\n Reason 1<\/strong>: \/etc\/sudoers<\/em> syntax uses the hash character (#) for two different purposes.<\/p>\n The default \/etc\/sudoers<\/em> file is full of lengthy comments. Just to give you and idea:<\/p>\n Yup. 118 lines<\/strong> in total vs. 12 lines<\/strong> of configuration (comments and empty lines removed). Like with banner blindness<\/a>, this causes comment blindness. Especially towards the end of the file. Especially if you’ve seen this file a billion times before.<\/p>\n And that’s where the problem starts. Right at the bottom of the file, there are these two lines:<\/p>\n Interesting, right? Usually there is nothing in the \/etc\/sudoers.d\/<\/em> folder on the brand new CentOS box. But even if there was something, by now you’d assume that the include of the folder is commented out. Much like that wheel<\/em> group configuration I mentioned earlier. I found it by accident, while reading sudoers(5)<\/em> manual page, trying to find out if there are any other locations or defaults for included configurations. About 600 lines into the manual, there is this:<\/p>\n So that comment is not a comment at all, but an include of the folder. That’s the first part of the problem.<\/p>\n Reason #2<\/strong>: Windows Azure Linux Agent<\/p>\n As I mentioned above, the servers aren’t part of my infrastructure – they were provided by the clients. I was basically given an IP address, a username and a password for each server – which is usually all I need. In most cases I don’t really care where the server is hosted and what’s the hosting company in use. Turns out, I should.<\/p>\n The server with the problem was hosted on the Microsoft Azure cloud infrastructure. I assumed I was working off a brand new vanilla CentOS 7 box, but in fact I wasn’t. Microsoft adds packages to the default install. On of the packages that it adds is the Windows Azure Linux Agent, which “rpm -qi WALinuxAgent<\/em>” describes as following:<\/p>\n The Windows Azure Linux Agent supports the provisioning and running of Linux VMs in the Microsoft Azure cloud. This package should be installed on Linux disk images that are built to run in the Microsoft Azure environment.<\/p><\/blockquote>\n Harmless, right? Well, not so much. What I found in the \/etc\/sudoers.d\/<\/em> folder was a little file, called waagent<\/em>, which included the different sudo configuration for the user which I had a problem with.<\/p>\n During the troubleshooting process, I’ve created a new test user, added the account to the wheel group and found out that it was working fine. From there, I needed to find the differences between the two users.<\/p>\n I guess, the user that I was using initially was created by the client’s system administrator using Microsoft Azure web interface. A quick Google search brings this page<\/a> from the Azure documentation:<\/p>\n By default, the I checked the user’s home folder and found no keys in there, so I think it was provisioned using the first option, with password only.<\/p>\n I think Microsoft should make it much more obvious that the system behavior might be different. Amazon AWS<\/a> provides a good example to follow. When you login into Amazon AMI instance, you see a message of the day (motd) banner, which looks like this:<\/p>\n It’s dead obvious that you are now on the Amazon EC2<\/a> machine and you should adjust your Deleting the file immediately solved the problem. To avoid similar issues in the future, #includedir directive can be moved further up in the file, and surrounded by more visible comments. Like, maybe, an ASCII art skull<\/a>, or something.<\/p>\n\n
\n(root@host ~)# wc -l \/etc\/sudoers\n118 \/etc\/sudoers\n(root@host ~)# grep -v '^#' \/etc\/sudoers | grep -v '^$' | wc -l\n12\n<\/pre>\n
\n##Read drop-in files from \/etc\/sudoers.d (the # here does not mean a comment)\n#includedir \/etc\/sudoers.d\n<\/pre>\n
\nTo include \/etc\/sudoers.local from within \/etc\/sudoers we\nwould use the following line in \/etc\/sudoers:\n\n#include \/etc\/sudoers.local\n\nWhen sudo reaches this line it will suspend processing of\nthe current file (\/etc\/sudoers) and switch to\n\/etc\/sudoers.local.\n<\/pre>\n
root<\/code> user is disabled on Linux virtual machines in Azure. Users can run commands with elevated privileges by using the sudo<\/code> command. However, the experience may vary depending on how the system was provisioned.<\/p>\n\n
.CER<\/code> file) or SSH key as well as a password, or just a user name and password. In this case sudo<\/code> will prompt for the user’s password before executing the command.<\/li>\n.cer<\/code>, .pem<\/code>, or .pub<\/code>file) or SSH key, but no password. In this case sudo<\/code> will not<\/strong> prompt for the user’s password before executing the command.<\/li>\n<\/ol>\n<\/blockquote>\n\n$ ssh server.example.com\nLast login: Tue Apr 5 17:25:38 2016 from 127.0.0.1\n\n__| __|_ )\n_| ( \/ Amazon Linux AMI\n___|\\___|___|\n\nhttps:\/\/aws.amazon.com\/amazon-linux-ami\/2016.03-release-notes\/\n\n(user@server.example.com)$\n<\/pre>\n
expectations<\/del> assumptions accordingly.<\/p>\n
![\"ASCII](\"https:\/\/i0.wp.com\/mamchenkov.net\/wordpress\/wp-content\/uploads\/2016\/04\/ascii-skull.png?resize=249%2C289&ssl=1\")
<\/a><\/p>\n