When I use chef knife solo with a non-root user with sudo access, it always asks me that user's password. However, I have turned off password access to that server.
$ bundle exec knife solo cook supersecretuser#productionserver -VV
Starting 'Run'
Running Chef on productionserver...
Checking Chef version...
DEBUG: Initial command sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'
DEBUG: Initial command sudo -V
DEBUG: Running processed command sudo -V
DEBUG: sudo -V stdout: Sudo version 1.8.9p5
DEBUG: sudo -V stdout: Sudoers policy plugin version 1.8.9p5
Sudoers file grammar version 43
DEBUG: sudo -V stdout: Sudoers I/O plugin version 1.8.9p5
DEBUG: Running processed command sudo -E -p 'knife sudo password: ' chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'
Enter the password for supersecretuser#productionserver:
I've added my ssh key to the server and am able to ssh into that server with ssh supersecretuser#productionserver without needing a password.
I have used chef knife solo on my staging server with the root user and it works fine.
I've tried explicitly passing my ssh key using the -i option, chef knife solo cook supersecretuser#productionserver -i ~/.ssh/id_rsa.pub and knife solo didn't seem to use that. Any ideas on what to try next?
Note: I am showing cook because that's where I'm at. I did a prepare and it worked because I hadn't turned off password access yet - that happened with my first cook - so I was able to just enter the password.
You messing between ssh and sudo, check your sudoers file for the supersecretuser entry it should looks like:
#Vagrant entry to allow sudo from vagrant
vagrant ALL=(ALL) NOPASSWD: ALL
Here allowing vagrant user to sudo any command without password.
Related
I have gitlab CI job which had a script execution like below:
stage: permissions
script:
sshpass -p "${PASSWORD}" ssh ${USER}#${HOST} sudo chown -cv user_a:user_a ${directory}/test.txt
The above gives me following error:
sudo: sorry, you must have a tty to run sudo
If i add -t with ssh i get:
Pseudo-terminal will not be allocated because stdin is not a terminal.
sudo: sorry, you must have a tty to run sudo
If i add -tt with ssh, the job keeps waiting for me to enter the password.
My requirement is to execute a remote command using ssh and text password i.e. sshpass, is there a way i can achieve this without change any sudoers permissions over the server?
Use somethinc like:
sshpass -p "${PASSWORD}" ssh ${USER}#${HOST} sh -c "echo ${PASSWORD} | sudo chown -cv user_a:user_a ${directory}/test.txt"
Example for write password from not tty to sudo:
echo ${PASSWORD} | sudo -S command
p.s. For configure servers use Ansible, he handles such tasks very easily.
I'm using password-less key based login with sudo to execute remote commands. I have figured out that I have to spawn a new shell to execute commands that write to root areas of the remote file system. But, I would like a clear explanation of exactly why this is the case?
This fails:
sudo -u joe ssh example.com "sudo echo test > /root/echo_test"
with:
bash: /root/echo_test: Permission denied
This works fine:
sudo -u joe ssh example.com "sudo bash -c 'echo test > /root/echo_test'"
It's the same reason that a local sudo echo test >/root/echo_test will fail (if you are not root) -- the redirection is done by the shell (not the sudo or echo command) which is running as the normal user. sudo only runs the echo command as root.
With sudo -u joe ssh example.com "sudo echo test > /root/echo_test", the remote shell is running as a normal user (probably joe) and does not have permission to write to the file. Using an extra bash invokation works, because sudo then runs bash as root (rather than echo), and that bash can open the file and do the redirect.
i am wondering how does fabric execute commands.
Let's say I give him env.user=User, env.host=HOST. Then i ask him to sudo('ls')
Is that equivalent to me typing in a shell : ssh User#host 'sudo(/bin/ls)'
or it's more : ssh User#host in a first time, then sudo ls commande in a seconde time ?
I'm asking that because sometimes using a shell, if the TTY has a bad configuration (I am a bit blurry on this), ssh User#Host 'sudo /bin/ls'
return : sudo: no tty present and no askpass program specified
but you can first log in with ssh User#Host then sudo ls and it works.
I don't know how to replicate the no tty error, but I know it can occurs. Would this block the sudo commande from Fabric?
Basically how it works is:
First a connection is established (equivalent as doing ssh User#host)
Over this connection a command is executed as follows:
sudo -S -p 'sudo password:' /bin/bash -l -c "your_command"
You can also allow Fabric not to request a pty with either pty=False argument, env.always_use_pty=False or --no-pty commandline option.
I am doing this using fabric (python):
Login as root to a brand new Centos 6.5 box from linode.com
Run the following script
The script:
#!/bin/bash
yum -y update
adduser shortfellow
echo "shortfellow ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
echo 'Defaults:shortfellow !requiretty' >> /etc/sudoers
/sbin/mkhomedir_helper shortfellow
mkdir -p /home/shortfellow/.ssh
echo "<my ssh public key>" >> /home/shortfellow/.ssh/authorized_keys
chmod -R 700 /home/shortfellow/.ssh
chown -R shortfellow:shortfellow /home/shortfellow/.ssh
su - shortfellow
exit
The problem:
I can not log into the server with the new server with given username(shortfellow) for a few attempts. I have added ssh keys to ssh-agent. It works after I try to login multiple times, but I can not understand why that would be the case.
Any help is appreciated.
You might want to use single quotes when echoing things like ssh keys. If there are any special characters that would be bash variables or similar they could be being expanded.
I'm trying to login to a ssh server and to execute something like:
ssh user#domain.com 'sudo echo "foobar"'
Unfortunately I'm getting an error:
sudo: no tty present and no askpass program specified
Google told me to either set the environment variable SSH_ASKPASS or to set askpass in the sudoers file. My remote machine is running on Debian 6 and I've installed the packages ssh-askpass and ssh-askpass-gnome and my sudoers file looks like this:
Defaults env_reset
Defaults askpass=/usr/bin/ssh-askpass
# User privilege specification
root ALL=(ALL) ALL
user ALL=(ALL) ALL
Can someone tell what I'm doing wrong and how to do it better.
There are two ways to get rid of this error message. The easy way is to provide a pseudo terminal for the remote sudo process. You can do this with the option -t:
ssh -t user#domain.com 'sudo echo "foobar"'
Rather than allocating a TTY, or setting a password that can be seen in the command line, do something like this.
Create a shell file that echo's out your password like:
#!/bin/bash
echo "mypassword"
then copy that to the node you want using scp like this:
scp SudoPass.sh somesystem:~/bin
Then when you ssh do the following:
ssh somesystem "export SUDO_ASKPASS=~/bin/SudoPass.sh;sudo -A command -parameter"
Another way is to run sudo -S in order to "Write the prompt to the standard error and read the password from the standard input instead of using the terminal device" (according to man) together with cat:
cat | ssh user#domain.com 'sudo -S echo "foobar"'
Just input the password when being prompted to.
One advantage is that you can redirect the output of the remote command to a file without "[sudo] password for …" in it:
cat | ssh user#domain.com 'sudo -S tar c --one-file-system /' > backup.tar
Defaults askpass=/usr/bin/ssh-askpass
ssh-askpass requires X server, so instead of providing a terminal (via -t, as suggested by nosid), you may forward X connection via -X:
ssh -X user#domain.com 'sudo echo "foobar"'
However, according to current documentation, askpass is set in sudo.conf as Path, not in sudoers.
How about adding this in the sudoers file:
user ALL=(ALL) NOPASSWD: ALL