Unable to connect as the root user in Vagrant 1.7.1 - passwords

I've been trying to login to Vagrant as a root user using 'vagrant' as the password. It doesn't seem to work. I have checked the official documentation and read few posts which confirm 'vagrant' as the password for the root user. Is there a solution?

You should never log in with the root user. Do everything you need under sudo or, worst, sudo -s.

Related

pam_unix(sudo:auth): conversation failed, auth could not identify password for [username]

I'm using ansible to provision my Centos 7 produciton cluster. Unfortunately, execution of below command results with ansible Tiemout and Linux Pluggable Authentication Modules (pam) error conversation failed.
The same ansible command works well, executed against virtual lab mad out of vagrant boxes.
Ansible Command
$ ansible master_server -m yum -a 'name=vim state=installed' -b -K -u lukas -vvvv
123.123.123.123 | FAILED! => {
"msg": "Timeout (7s) waiting for privilege escalation prompt: \u001b[?1h\u001b=\r\r"
}
SSHd Log
# /var/log/secure
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): conversation failed
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): auth could not identify password for [lukas]
I've found the problem. It turned out to be PAM's auth module problem! Let me describe how I got to the solution.
Context:
I set up my machine for debugging - that is I had four terminal windows opened.
1st terminal (local machine): Here, I was executing ansible prduction_server -m yum -a 'name=vim state=installed' -b -K -u username
2nd terminal (production server): Here, I executed journalctl -f (system wide log).
3rd terminal (production server): Here, I executed tail -f /var/log/secure (log for sshd).
4th terminal (production server): Here, I was editing vi /etc/pam.d/sudo file.
Every time, I executed command from 1st terminal I got this errors:
# ansible error - on local machine
Timeout (7s) waiting for privilege escalation prompt error.
# sshd error - on remote machine
pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth): [username]
I showed my entire setup to my colleague, and he told me that the error had to do something with "PAM". Frankly, It was the first time that I've heard about PAM. So, I had to read this PAM Tutorial.
I figured out, that error relates to auth interface located in /etc/pam.d/sudo module. Diging over the internet, I stambled upon this pam_permit.so module with sufficient controll flag, that fixed my problem!
Solution
Basically, what I added was auth sufficient pam_permit.so line to /etc/pam.d/sudo file. Look at the example below.
$ cat /etc/pam.d/sudo
#%PAM-1.0
# Fixing ssh "auth could not identify password for [username]"
auth sufficient pam_permit.so
# Below is original config
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Conclusion:
I spent 4 days to arrive to this solution. I stumbled upon over a dozens solutions that did not worked for me, starting from "duplicated sudo password in ansible hosts/config file", "ldap specific configuration" to getting advice from always grumpy system admins!
Note:
Since, I'm not expert in PAM, I'm not aware if this fix affects other aspects of the system, so be cautious over blindly copy pasting this code! However, if you are expert on PAM please share with us alternative solutions or input. Thanks!
Assuming the lukas user is a local account, you should look at how the pam_unix.so module is declared in your system-auth pam file. But more information about the user account and pam configuration is necessary for a specific answer.
While adding auth sufficient pam_permit.so is enough to gain access. Using it in anything but the most insecure test environment would not be recommended. From the pam_permit man page:
pam_permit is a PAM module that always permit access. It does nothing
else.
So adding pam_permit.so as sufficient for authentication in this manner will completely bypass the security for all users.
Found myself in the same situation, tearing my hair out. In my case, hidden toward the end of the sudoers file, there was the line:
%sudo ALL=(ALL:ALL) ALL
This undoes authorizations that come before it. If you're not using the sudo group then this line can safely be deleted.
I had this error since upgrading sudo to version 1.9.4 with pacman. I hadn't noticed that pacman had provided a new sudoers file.
I just needed to merge /etc/sudoers.pacnew.
See here for more details: https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave
I know that this doesn't answer the original question (which pertains to a Centos system), but this is the top Google result for the error message, so I thought I'd leave my solution here in case anyone stumbles across this problem coming from an Arch Linux based operating system.
I got the same error when I tried to restart apache2 with sudo service apache2 restart
When logging into root I was able to see the real error lied with the configuration of apache2. Turned out I removed a site's SSL-Certificate files a few months ago but didn't disable the site in apache2. a2dissite did the trick.

User Permissions in Ubuntu

I want to access "sudoers" file and also access "su -" but I fail and get following error please check terminal output that I have tried. I am m-usman(admin) but not allow to edit or access ? :(
m-usman#muhammad-usman:~$ sudo gedit /etc/sudoers
[sudo] password for m-usman:
m-usman is not in the sudoers file. This incident will be reported.
m-usman#muhammad-usman:~$ su -
Password:
su: Authentication failure
m-usman#muhammad-usman:~$ sudo visudo
[sudo] password for m-usman:
m-usman is not in the sudoers file. This incident will be reported.
How can I fix it?
It seems like your user account has not been added to the sudoers file, hence you don’t have permission to edit the sudoers file or switch to super user.
Ask somebody (who already is in sudoers list) to add you in the sudoers list. and then you will have the appropriate permissions to do stuffs using sudo.
Thanks.

Create ssh root password

For some reason, after a plesk update, I can no longer login to ssh as root using my old password. I have tried to create a user with:
/bin/bash & /bin/bash (chrooted) in plesk
Which lets me login but has no root privileges. How can I either recover my old password or get access to the ssh config to check whether root login is disabled. I installed ssh term in plesk, but that bums out with an error of:
jarsigning exception
Guess it's because there is only the default certificate on the server. I would be grateful if someone could help with this as I have reached a point where I am struggling to find other things to try. Many thanks
Plesk 11.5 CentOS 6 SSH Client
Once you are logged with the non-root user try to type "su" or "su root" and the enter your root password, it will allow you to become root.
Note that su allow you to login as any user, the syntax is "su username".

If I run 'git push' via ssh then it outputs 'Permission denied (publickey)'

I set ./git/config file like this.
[remote "origin"]
url = https://github.com/haradashinya/dotfiles.git
It's pushed my github's repository but it asks for my username and password. So, I set my url to ssh style, like this:
url = git#github.com:haradashinya/dotfiles.git
But it outputs an error message saying 'Permission denied (publickey)'.
Why this happened?
Even if you have defined ssh keys, you need to be sure HOME is defined (which isn't the case on Windows for instance, unless you are using a DOS session from git-cmd.bat shipped with msysgit): see "Trying to “install” github, .ssh dir not there".
In that same HOME directory, you could also record your https GitHub credential (username and password) if you still want to use the https address: see "change github account mac command line" for an example.
You need to add your SSH key to your github account here: https://github.com/settings/ssh
If you haven't generated an SSH key, or you don't know how to generate an SSH key, or you don't understand how to add it to your github account, github provides detailed instructions here: https://help.github.com/articles/generating-ssh-keys
I've followed with https://help.github.com/articles/error-permission-denied-publickey instructions.
And I resolved my problem by ssh-add 'my-id-rsa-path' command.
ssh-add ~/.ssh/id_rsa;
ssh -vT git#github.com #-> success!
Thanks for help!

Can connect to EC2 as ubuntu user but not as the user i created

I created a new ebs backed EC2-instance and the necessary key-pair. Now I am able to connect to the instance as ubuntu user. Once i did that I created another user and added it to the sudoers list but I am unable to connect to the instance as the new user I created.
I get the following error. I am using the same key to connect with the new user i created. Can somebody help me. Am I missing something here?
Permission denied (publickey)"
Okay I think i figured it out.
The first technique is to login by password. The idea is to login as the ubuntu user or root user and go to /etc/ssh/sshd_config file and turn the PasswordAuthentication to yes and run
/etc/init.d/ssh reload
If you try to connect now you ec2 allows you to log with the password of the user that was created. Though this is not really secure.
Second is you create a key-pair and copy the id-rsa.pub file and move it to the /home/new-user/.ssh/authorized_keys file and change permissions to 600 and assign to the appropriate user(new-user in this case).
I found this to be amazingly useful
http://blog.taggesell.de/index.php?/archives/73-Managing-Amazon-EC2-SSH-login-and-protecting-your-instances.html
SSH is very picky about the directory and file permissions. Make sure that:
The directory /home/username/.ssh has permission "700" and is owned by the user (not root!)
The /home/username/ssh/authorized_keys has permission "600" and is owned by the user
Copy your public key into the authorized_keys file.
sudo chown -R username:username /home/username/.ssh
sudo chmod 0700 /home/username/.ssh
sudo chmod 0600 /home/username/.ssh/authorized_keys
You can do all that as a root user. There is no need to allow temporarily in /etc/ssh/ssh_config to passwords.
Sid, I did what you mentioned but I still got the same error
The first technique is to login by password. ...
It took a reboot to get it to work. (Just in case anyone else wants this insecure method to work) The public key method is a major pain to make it work with remote desktop apps