Tag Info

Hot answers tagged

9

You can't ssh into recovery mode as ssh won't be running. You need a way to get on to console. If this is a virtual machine and you own the host there should be some way to connect to the host and get on console. If this is a service like AWS then you are out of luck and you need to recover it someway else like building a new instance and detaching the root ...


6

You could use an acl on the file(s) to grant read permission to user setfacl -m user:grepuser:r /var/log/maillog* This as the advantage of allowing the user to use any tool that they wish. This is also logrotate safe for maillog*


3

Unless you know what specific strings the users will be searching for and the specific files they'll be checking using sudo is not a good solution for this. If you create a rule like this: blizz ALL=root NOPASSWD: /bin/grep * /var/log/maillog* The user will be able to run commands like this: grep root /etc/shadow /var/log/maillog grep = /root/my.cnf ...


2

This should work as expected in sudoers file: %users ALL= /bin/cat /var/log/mail.log %users ALL= /bin/cat /var/log/mail.err (log paths from Ubuntu, change if necessary) Using a generic, output-only tool like cat is simple and secure. You won't have to permit and limit specific options as with grep directly in sudoers. It will also allow filtering of ...


1

To recover your password, saved in KiTTY follow this simple steps: Load the session with the stored password into KiTTY Go to the Session -> Options Enable logging for SSH packets and raw data Uncheck the Omit known passwords fields box Start the session, wait until it logs you in Close the KiTTY window Go to your KiTTY folder and open the log file Find ...


1

You can define this with sudoers(visudo command for editing): www-data ALL=(ALL:ALL) NOPASSWD:/usr/bin/docker inspect * www-data user will have access to /usr/bin/docker binary with argument inspect and other arguments to this command. This command won't require password. If you don't want this behaviour remote "NOPASSWD:". For example: User can ...


1

solved. I forgot the /usr/sbin/ before service :|


1

I think the issue is the /tmp file doesn't have permissions. If you sudo -u root ssh git@github.com That might work since root can read the files To fix this as the vagrant user run setfacl -m otheruser:x $(dirname "$SSH_AUTH_SOCK") setfacl -m otheruser:rwx "$SSH_AUTH_SOCK" That should give the otheruser rights to get into the directory and read ...



Only top voted, non community-wiki answers of a minimum length are eligible