I have an Amazon (AMI) Linux EC2 instance running on AWS. I'm create a perl script that will create directories when it is called through a web url (CGI script).
However, because the browser is executing the script, the user apache is running the perl script. Because apache is not allowed to do mkdir command without using sudo none of the directories are being created.
I've modified the scripts permissions to execute (755) via the browser, however none of the mkdir commands work.
I even tried using the sudo command within the perl script, but I have no luck. However, all of the non sudo commands work such as 'cd' etc.
If anyone knows how to resolve this issue I would appreciate it.
I've found the answer through searching.
The first thing you need to do is disable tty for the current user.. my web browser executes anything as the user 'apache' on the server.
So in my /etc/sudoers file i added
Defaults:apache !requiretty
Also i created a list of commands that I want apache to use without requiring the sudo password
Cmnd_Alias APACHE = /bin/mkdir, /bin/rmdir
apache ALL=(ALL) NOPASSWD: APACHE
This allows only certain sudo commands to execute on my web server without requring the password.
NOTE: only open the /etc/sudoers file using the visudo command... DO NOT open it using just regular vim or nano because if you save it and theres an error it will **** your machine up and you may have to create a whole new server because any sudo commands wont execute.
u can specify your editor using visudo.. e.g
EDITOR=nano visudo
Related
I'm facing a weird behavior trying to run rsync as sudo through ssh with passwordless login.
This is something I do with dozens of servers, I'm having this frustrating problem connecting to a couple of Ubuntu 18.04.4 servers
PREMISE
the passwordless SSH from CLIENT to SERVER with account USER works
nicely
When I'm logged in SERVER I can sudo everything with
account USER
On SERVER I've added the following to /etc/sudoers
user ALL=NOPASSWD:/usr/bin/rsync
Now, if I launch this simple test from machine CLIENT as user USER, I receive the following sudo error message:
$ ssh utente#192.168.200.135 -p 2310 sudo rsync
sudo: no tty present and no askpass program specified
Moreover, looking in the SERVER's /var/log/auth.log I found this errors:
sudo: pam_unix(sudo:auth): conversation failed
sudo: pam_unix(sudo:auth): auth could not identify password for [user]
am not an PAM expert, but tested the following solution working on Ubuntu 16.04.5 and 20.04.1
NOTE : Configuration set to default on /etc/ssh/sshd_config
$ sudo visudo -f /etc/sudoers.d/my_config_file
add the below lines
my_username ALL=(ALL) NOPASSWD:ALL
and don't forget to restart sshd
$ sudo systemctl restart sshd
I've found a solution thanks to Centos. Infact, because of the more complex configuration of /etc/sudoers in Centos (compared to Ubuntu or Debian), I've been forced to put my additional configurations to an external file in /etc/sudoers.d/ instead than putting it directly into /etc/sudoers
SOLUTION:
Putting additional configurations directly into /etc/sudoers wouldn't work
Putting the needed additional settings in a file within the directory /etc/sudoers.d/ will work
e.g. , these are the config lines put in a file named /etc/sudoers.d/my_config_file:
Host_Alias MYSERVERHOST=192.168.1.135,localhost
# User that will execute Rsync with Sudo from a remote client
rsyncuser MYSERVERHOST=NOPASSWD:/usr/bin/rsync
Why /etc/sudoers didn't work? It's unknown to me even after two days worth of Internet search. I find this very obscure and awful.
What follows is a quote from this useful article: https://askubuntu.com/a/931207
Unlike /etc/sudoers, the contents of /etc/sudoers.d survive system upgrades, so it's preferrable to create a file there than to modify /etc/sudoers.
For the editing of any configuration file to be used by sudo the command visudo is preferable.
i.e.
$ sudo visudo -f /etc/sudoers.d/my_config_file
I had a similar problem on a custom linux server, but the solution was similar to the answers above.
As soon as I removed the line your_user ALL=(ALL) NOPASSWD:ALL from /etc/sudoers, the errors were gone.
This question already has answers here:
WinSCP connect to Amazon AMI EC2 Instance changing user after login to "root"
(6 answers)
Closed last year.
I am trying to use WinSCP to transfer files over to a Linux Instance from Windows.
I'm using private key for my instance to login to Amazon instance using ec2-user. However ec2-user does not have access to write to the Linux instance
How do I sudo su - to access the root directory and write to the Linux box, using WinSCP or any other file transfer method?
Thanks
I know this is old, but it is actually very possible.
Go to your WinSCP profile (Session > Sites > Site Manager)
Click on Edit > Advanced... > Environment > SFTP
Insert sudo su -c /usr/lib/sftp-server in "SFTP Server" (note this path might be different in your system)
Save and connect
Source
AWS Ubuntu 18.04:
There is an option in WinSCP that does exactly what you are looking for:
AFAIK you can't do that.
What I did at my place of work, is transfer the files to your home (~) folder (or really any folder that you have full permissions in, i.e chmod 777 or variants) via WinSCP, and then SSH to to your linux machine and sudo from there to your destination folder.
Another solution would be to change permissions of the directories you are planning on uploading the files to, so your user (which is without sudo privileges) could write to those dirs.
I would also read about WinSCP Remote Commands for further detail.
Usually all users will have write access to /tmp.
Place the file to /tmp and then login to putty , then you can sudo and copy the file.
I just wanted to mention for SUSE Enterprise server V15.2 on an EC2 Instance the command to add to winSCP SFTP server commands is :
sudo su -c /usr/lib/ssh/sftp-server
I didn't have enough Reputation points to add a comment to the original answer but I had to fish this out so I wanted to add it.
ssh to FreePBX and run the commands stated below in your terminal:
sudo nano -f /etc/sudoers.d/my_config_file
YourUserName ALL=(ALL) NOPASSWD:ALL
sudo systemctl restart sshd
Winscp:
under session login ==> Advanced ==> SFTP
Change SFTP Server to:
sudo /usr/libexec/openssh/sftp-server
I do have the same issue, and I am not sure whether it is possible or not,
tried the above solutions are not worked for me.
for a workaround, I am going with moving the files to my HOME directory, editing and replacing the files with SSH.
Tagging this answer which helped me, might not answer the actual question
If you are using password instead of private key, please refer to this answer for tested working solution on Ubuntu 16.04.5 and 20.04.1
https://stackoverflow.com/a/65466397/2457076
I'm using flask with apache(mod_wsgi).
When I use ssh module with external command subprocess.call("ssh ......",shell=True)
(My Python Flask code : Not wrong)
ssh = "sshpass -p \""+password+"\" ssh -p 6001 "+username+"#"+servername+" \"mkdir ~/MY_SERVER\""
subprocess.call(ssh, shell=True)
I got this error on Apache error_log : Failed to get a pseudo terminal: Permission denied
How can I fix this?
I've had this problem under RHEL 7. It's due to SELinux blocking apache user to access pty. To solve:
Disable or set SELinux as permissive (check your security needs): edit /etc/selinux/config and reboot.
Allow apache to control its directory for storing SSH keys:
sudo -u apache
chown apache /etc/share/httpd
ssh to desired host, accept key.
I think apache's login shell is "/sbin/nologin".
If you want to allow apache to use shell command, modify /etc/passwd and change the login shell to another shell like "/bin/bash".
However, this method is vulnerable to security. Many python ssh modules are available in internet. Use one of them.
What you are doing seems frightfully insecure. If you cannot use a Python library for your SSH connections, then you should at least plug the hole that is shell=True. There is very little here which is done by the shell anyway; doing it in Python affords you more control, and removes a big number of moving parts.
subprocess.call(['/usr/bin/sshpass', '-p', password,
'/usr/bin/ssh', '-T', '-p', '6001', '{0}#{1}'.format(username, servername),
'mkdir ~/MY_SERVER'])
If you cannot hard-code the paths to sshpass and ssh, you should at least make sure you have a limited, controlled PATH variable in your environment before doing any of this.
The fix for Failed to get a pseudo-terminal is usually to add a -T flag to the ssh command line. I did that above. If your real code actually requires a tty (which mkdir obviously does not), perhaps experiment with -t instead, and/or redirecting standard input and standard output.
I've been working on an internal site that has Apache / PHP running.
I have CIFS Mount in a root directory. /filesys/Images/ that points to a file server.
My apache runs under the 'apache' user account.
The CIFS is mounted with the user and group of the apache user. (and 777)
When I write a PHP script to read or write from this CIFS mount and run it on the command line (both under normal and apache users) everything is fine.
As soon as I try to call the script from apache things fail. No read or write permissions.
My error log will show (for mkdir) 'file exists' although it does not.
My PHPInfo verifies that safe mode is not on.
Any ideas?
My problem had to do with SELinux and getting that configured properly.
semanage boolean -m --on httpd_use_cifs
How can I run a command from a (bash) CGI script to play a wav sound on the server side?
You can execute your command line audio player as described by nak, but this may not work due to the permissions of the user running Apache. By default Apache is run as www-data:www-data (or apache:apache or www:www on some distros). As a quick fix/test you can set Apache to run as a user that has permissions to access the audio device on the machine by modifying your /etc/apache2/apache2.conf (or /etc/httpd/httpd.conf") file to have:
User USER_THAT_CAN_PLAY_AUDIO
Group USER_THAT_CAN_PLAY_AUDIO
Warning: this is not secure and is not intended to be a permanent solution!
This is how I would do it
#!/bin/sh
echo Content-type: text/plain
echo ""
echo "Server is playing sine.wav!"
aplay -q sine.wav
I stumbled over this old question looking how to solve the same problem: to have my personal Apache webserver warning me when someone makes a specific request (in my case a call for chat without the need to have any IM running).
The solution below is what I use on Slackware 14.1: according to your distro YMMV.
launch visudo
add the line TheUserRunningApache ALL=(ALL) NOPASSWD: /usr/bin/play (TheUserRunningApache is the user name used by your Apache)
In the PHP page you want to play a sound add this line: system ("sudo /usr/bin/play SOUND.WAV");
If you don't want to give access to Apache to the /usr/bin folder, even if limited just to play, you can copy the sox executable (the program used to run /usr/bin/play) elsewhere, but you'll have to modify the last two instructions above accordingly.