I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh myusername#IP_ADDRESS
On the server:
sudo su
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open /dev/tty for read-write and prints that error if it fails. You've indicated in comments that /dev/tty is missing on your system.
Sudo has an option -S to read the password from standard input instead of /dev/tty. You should be able to run sudo -S to become root.
Regarding how to recover /dev/tty, It's possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I'd inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where "major" is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You've to either log-in as root or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes "have a tty". If you are still having problems, it's probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command "tty" - if it returns "not a tty", that shell doesn't have a "controlling tty" and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) -- High Sierra uses a different mechanism for allocating pty's than earlier Mac OS X releases, so if your code isn't reconfigured for it, it will fail to allocate a pty.
Related
I am trying to launch a program on Lubuntu 19.04 that talks to my Arduino Due device (robotics) via serial with /dev/ttyACM0. Everything seems fine, until I try to launch the app at startup.
The problem occurs only when I try to make my app boot at login. Running it as user, from terminal, from .desktop file, from script etc. is not a problem at all, I am able to establish connection 10/10 times.
Please bear in mind that I am putting $USER manually now, in every command it is explicitly passed as my de facto username.
It shouldn't be a permissions problem.
$ ls -la /dev/
...
crw-rw-rw- 1 root dialout 166, 0 mar 13 17:27 ttyACM0
...
$ groups $USER
$USER : $USER root adm tty dialout cdrom sudo dip plugdev lpadmin sambashare
I have tried runing it from .xsessionrc with:
#!/bin/bash
# Some other commands to set the environment up
/home/$USER/user_panel /dev/ttyACM0
I have also tried setting it in LXQt Session Settings with Autostart so i ended up with a .desktop entry:
$ cat ./.config/autostart/$USER\ User\ Panel.desktop
[Desktop Entry]
Exec=/home/$USER/user_panel /dev/ttyACM0
Name=User Panel
Type=Application
Version=1.0
I have tried launching both of that files manually and it was alright, the app started, the connection was made.
I have also tried making my udev rule.
$ cat /etc/udev/rules.d/50-myusb.rules
KERNEL=="ttyACM[0-9]*", MODE="0666
Hence, my question is: what should I look for as the reason for this boot time denial?
I don't know if this is the same problem but I was getting "access denied" when opening /dev/ttyACM0 during a hot-boot of the USB connection. I went through permissions, overrode the kernel to give me ownership of the device and still got the same error. Unless I was debugging, in which case access was fine.
The problem seemed to be that the device had not yet started up and putting a half second delay (you may have to increase it to find what works) was enough to allow the device to initialize and be accessed correctly. Try putting a short delay inside a finite loop while you try to open it.
Hope this helps.
I wanted to force root user to change password on next login , so I executed command
chage -d 0 root.
The command executed successfully and return code as 0.Even /etc/shadow file is showing changes properly as follow
root:$1$ZlexRZiM$3cb5GDF9s7.U0l/Xwoh0E1:0:1:90:7:::
Still system is not forcing root user to change password.I even tried to expire password by executing command
passwd -e root
still facing same issue.
IT is a very strange behavior, this should work since it is a rather standard way to do it.
What I would check is:
Full logout, don't test it with the "sudo -i" or "sudo su" to test it and perform a clean login as root (straight as root)
Check the /etc/login.defs file for variables settings (even if I don't think it is much probable). Variables you should check for are (pasting std fedora settings from my workstation):
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
I have a VPS with Nagios installed, and I want to use Nagios to monitor the VPS resources in the /proc/user_beancounters file. The file has the following permissions:
-r-------- 1 root root 0 Oct 26 15:53 /proc/user_beancounters
So I downloaded the script from the Nagios Exchange:
https://exchange.nagios.org/directory/Plugins/Operating-Systems/*-Virtual-Environments/OpenVZ/check-beancounters/details
In the instructions it suggests to:
don’t forget to set the s-bit (chmod +s check_UBC.pl)
So, I copied the script over, and set the s-bit, then run it from the terminal as root. It works as expected. I then delete the temp file it created, su into the nagios user, and run the script. It works as expected. I delete the temp file it created, and start up Nagios. It can't read the /proc/user_beancounters file! The exact error I get, helpfully, is "could not read /proc/user_beancounters". This is, I believe, thrown by the line in the Perl script:
if (! open IN, "<", $UBC )
{
print "could not read $UBC\n";
exit $ERRORS{'CRITICAL'};
}
My OS is CentOS release 6.2 (Final).
My first thought is that it is some kind of SELinux voodoo, but there is no indication that SELinux is running on this server. Just in case, I tried the following:
echo 0 > /selinux/enforce
But this made no difference.
For reference, this is my nagios service running:
nagios 12939 0.0 0.0 203652 3404 ? Ssl 15:39 0:00 /usr/sbin/nagios -d /etc/nagios/nagios.cfg
And this is where I've put the Perl script:
-rwsr-sr-x 1 nagios nagios 2934 Oct 26 15:37 check_UBC.pl
Any suggestions as to what else I can try?
PS apologies if this should go in a different SE site - never sure with questions that involve scripts, permissions etc...
UPDATE 1
I created a shell script to see if I could 'emulate' the nagios service. It is extremely simple:
#!/bin/bash
/usr/lib64/nagios/plugins/check_UBC.pl
And now I have the following permissions:
-rwsr-sr-x 1 root root 2934 Oct 26 15:37 check_UBC.pl
-rwxrwxrwx 1 root root 51 Oct 26 19:29 check_UBC.sh
As root:
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.pl
everything is fine..
[root#/usr/lib64/nagios/plugins]$ ./check_UBC.sh
everything is fine..
As nagios:
-bash-4.1$ ./check_UBC.pl
everything is fine..
-bash-4.1$ ./check_UBC.sh
everything is fine..
So still no clue...
UPDATE 2
My nagios command definition:
define command{
command_name check_beancounters
command_line $USER1$/check_UBC.pl
}
And the service definition:
define service{
use local-service
host_name localhost
service_description VPS Beancounters
check_command check_beancounters
}
UPDATE 3
I managed to get it to work, but am not over the moon about giving the nagios user full sudo access with no password. In /etc/sudoers I put this on the last line:
nagios ALL=(ALL:ALL) NOPASSWD: ALL
And then changed my command definition to:
define command{
command_name check_beancounters
command_line sudo $USER1$/check_UBC.pl
}
Apparently recent versions of linux will not respect the +s permission when running an interpreted script, only a binary. So I guess I will have to compile a binary wrapper for the script?
UPDATE 4
As per Joe Young's suggestion, I changed my visudo entry to:
nagios ALL=NOPASSWD: /usr/lib64/nagios/plugins/check_UBC.pl
Which hopefully is relatively harmless!
Try changing the owner of check_UBC.pl to root so that when nagios executes check_UBC.pl the script runs as setuid of it's owner root and not the nagios user.
chown root:root check_UBC.pl
EDIT:
Can you post your command definition that's calling check_UBC.pl?
The last thing I can think of to try is to install the perl-suid module: https://chrisjean.com/fix-setuid-cannot-exec-sperl/
Although, if check_UBC.pl runs from the command line with no problem, I'm not sure what difference it would make.
What would the risk be to change the permissions on /proc/user_beancounters to 444 (read for all?) It only contains a number, correct? Not sure if that particular file "sticks around" after a reboot, or worse, constantly gets replaced as the services are running, so this could be a problem still.
Also, consider trying to test for actual "existence" of the file, before you attempt to read from it. Since we're in /proc directory, things do change, from time to time....
Lastly, you are asking to open the file, but syntactically is it asking to open in a read only mode? You may want to try a system call to simply "cat" the file contents, in your shell script, and see if you get a response.
everyone :
I need ssh to connect remote linux ,I already know how to run and display a GUI program in remote linux .It can be done by :
ssh username#ip
export DISPLAY=:0.0
firefox &
however ,my target linux hasn't X Window System , I need display the execution result in remote linux's screen ,for example :
my pc is A , remote pc is B
A use ssh access B , after connected to B ,I type ls in A then press enter
the execution result should display in B's screen (tty or whatever , I don't know what it should be called)
any idea? thanks for your help.
Basic idea:
a$ ssh user#b
b$ run-program >/dev/console
(I use a$ and b$ to indicate the shell prompts on A and B respectively.)
Problem with this:
b$ ls -l /dev/console
crw------- 1 root root 5, 1 Mar 19 09:10 /dev/console
Only root can write to /dev/console.
Possible workaround:
$b run-program | sudo tee /dev/console >/dev/null
(Redirecting to /dev/null here prevents the output from showing up on your screen as well.)
This does depend on user#b being allowed to run sudo tee /dev/console.
If you are sysadmin for B and user#b is not allowed to run sudo tee /dev/console, read man 5 sudoers and man 8 visudo to find out how to give user#b this permission.
If you are not sysadmin for B and user#b is not allowed to run sudo tee /dev/console, you will have to ask B's sysadmin to set this up for you.
I have the following "root-file" with the following contents:
$ cat root-file
#!/bin/bash
echo $EUID
id
Following are the permissions for this file:
$ ls -l root-file
-rwsr-sr-x 1 root root 15 Nov 18 02:20 root-file
Since the set-user-id bit is set for this file, I would expect that on executing this
file, the effective uid would be displayed as 0 even when a non-root user executes it (since set-user-id bit causes the process to be executed with the effective user-id of the owner of the file, which in this case is root). However, instead I get the following output on executing "root-file" from a non-root shell.
$ ./root-file
1000
uid=1000(chanakya) gid=1000(chanakya) groups=1000(chanakya),4(adm),20(dialout),24(cdrom),46(plugdev),105(lpadmin),119(admin),122(sambashare)
This file/or script is not being executed with effective user-id 0. Why is that so?
you cannot use setuid on shell scripts...
if you absolutely need to use setuid checkout http://isptools.sourceforge.net/suid-wrap.html
Normally something like this could also be established using some custom sudo configuration...