- #Centos passwordless sudo how to#
- #Centos passwordless sudo install#
- #Centos passwordless sudo password#
#Centos passwordless sudo install#
The home directory is set to /home/foo. The ceph-deploy utility must login to a Ceph node as a user that has passwordless sudo privileges, because it needs to install software and configuration files without prompting for passwords.The user foo is added to the both the foo and sudo group.Sed -i /etc/sudoers -re 's/^#includedir.*/# Removed the #include directive! #"/g' & \Įcho "Customized the sudoers file for passwordless access!" & \Įcho "foo ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers & \Įcho "root ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers & \Įcho "foo user:" su foo -c 'whoami & id' & \Įcho "root user:" su root -c 'whoami & id' Sed -i /etc/sudoers -re 's/^root.*/root ALL=(ALL:ALL) NOPASSWD: ALL/g' & \ Sed -i /etc/sudoers -re 's/^%sudo.*/%sudo ALL=(ALL:ALL) NOPASSWD: ALL/g' & \ Useradd -U foo -m -s /bin/bash -p foo -G sudo & passwd -d foo & passwd -d root & \ This is how I've implemented the non-root, passwordless user in an ephemeral Docker Image for use in a CICD pipeline with the base image of ubuntu:18.04: RUN \ Lets assume you want all sudo users (i.e. It looks like this: #includedir /etc/sudoers.d The answer mentioning to set a host confused me, as I want to be able to have a sudo user be able to run privileged commands without requiring to consider such 'host aspect' any host should work, hence I use the special ALL reserved word. This is a sneaky little directive, as it appears to be a commented line upon first glance.
Is it because the user nicholsonjf was inheriting sudo rights from the two group specifications of admin and sudo (seen below in the sudoers file), which were overriding the nicholsonjf user specification because they were further down in the config file?Īs I was researching this, I realized that there's a line in the /etc/sudoers file that is not a comment, but a directive that makes any file or folder under the directory /etc/sudoers/* override the contents of /etc/sudoers. I was only able to start running sudo commands as nicholsonjf once I removed nicholsonjf from the sudo and admin groups.
#Centos passwordless sudo password#
However this did not work, and I was still prompted for my password every time I ran a command as nicholsonjf. # See sudoers(5) for more information on "#include" directives: # Allow members of group sudo to execute any command The residual problem with disabling 'su' by removing it or removing permission bits is that some system scripts may depend on su being present.
Remove its setuid permission bit ( chmod u-s /bin/su ). # Members of the admin group may gain root privileges Remove its execute permission bits ( chmod o-x /bin/su or chmod go-x /bin/su ).
#Centos passwordless sudo how to#
# See the man page for details on how to write a sudoers file.ĭefaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Please consider adding local content in /etc/sudoers.d/ instead of Initially, my only change to the sudoers file ( /etc/sudoers) was one line, a user specification that should have enabled nicholsonjf to run all commands with sudo without having to enter a password (see the line that starts with nicholsonjf): # This file MUST be edited with the 'visudo' command as root. I understand it's a huge security risk to enable NOPASSWD sudo. NOTE: I have made these changes on a dedicated machine running Ubuntu Desktop 13.04, that I use purely for learning purposes. If you still have a problems you can look at the verbose output of the SSH command (e.g.This is a fairly complex question related to the sudoers file and the sudo command in general. There are a number of discussions online about what the ‘correct’ permissions for the home directory should be ( here for example) but the default values will work for SSH: I’ve also seen the problem that the home directory permissions are not set correctly (which will also cause the passwordless SSH to fail). Sudo chmod 600 /home/USER/.ssh/authorized_keys Your ‘ssh’ folder should have read, write and execute permission for the owner only (700) and the ‘authorized_keys’ file should have read and write permissions for the owner only (600): If you still cannot connect using your SSH key there is very likely a permissions problem. To resolve this you must again edit /etc/ssh/sshd_config and set:īy default it is set to ‘yes’ (this is an interesting difference between CentOS and Ubuntu).ĭon’t forget to restart the SSH service after making changes otherwise they won’t be updated: Which is probably not what you want if you are trying to turn off password authentication. If there is a problem with the key then this setup will still go ahead and ask for a password when trying to connect via SSH. Setting “PasswordAuthentication no” in /etc/ssh/sshd_config.Whilst the wiki provides most of the information required to set up passwordless SSH on CentOS, namely:
The CentOS wiki page misses out a crucial step in setting up passwordless SSH.
0 kommentar(er)
