I'm running into permissions issues renewing my certs with certbot-auto, because whenever it runs it displays this message:
Requesting to rerun certbot-auto with root privileges...
There is no need for it to run as root, because the user running the command has permissions on all directories used by certbot. I couldn't find any command-line options to disable this, but looking at the script itself I discovered that when it re-runs itself it checks for the argument
--cb-auto-has-root and if it's there it doesn't try to obtain root (again). I found that if I run certbot-auto with this command it runs just fine as non-root!
But I'm not sure if this workaround should be used - since it's undocumented - or will break in the future. What's the recommended way to run as a non-root user?
Related
I have created an EC2 instance with Amazon Linux 2 Image. Access to the instance is only allowed via Session Manager and not via SSH.
I have the following users:
ec2-user (Created by default)
ssm-user (Created by default)
root (Created by default)
myrootec2-user (My custom root user created by me from Terraform and with password assigned)
I have tried to disable the root user because I only want to be able to perform administrator actions with the user myrootec2-user.
To do so, I have carried out the following steps:
sudo vim /etc/passwd
And then, I have changed:
root:x:0:0:root:/root:/bin/bash
to
root:x:0:0:root:/root:/sbin/nologin
However, depending on the parameter I assign to the sudo command, I can access or not:
sudo su - # Error: This account is currently not available.
sudo -s # OK: Log in to the root user without errors
Why can I log in with the second command? Do you recommend disabling the root user or could I have problems in the future? What alternative would you recommend otherwise, e.g. assigning a password to root?
I have tried to disable the root user because I only want to be able to perform administrator actions with the user myrootec2-user.
You cannot "disable" the root user. You can disable password login and set the root shell to /sbin/nologin, but you'll still need to sudo to run administrative commands.
If you think you can get away without ever running administrative commands, well, that sounds like an interesting challenge. With the right approach to immutable infrastructure you might be able to do it. You would remove all users access to sudo in addition to your stuff, and root would be close to inaccessible at runtime (certain system processes would still use it).
But your system will still need a root user. It's critical to system functionality.
I got a strange problem with using git on IntelliJ IDEA on Windows 10.
If I want to access the remote repo on GitLab, I always get
Permission denied (publickey).
Everything I found here or via Google didn't solve the problem.
I tried:
Setting the ssh executable to Native
Converting my public key from Putty to ssh-keygen style
Removing known_hosts
I also tried to access the repo with Git Bash, it works fine like that.
Another interesting fact is that after removing known_hosts, I got "Host key verification failed". I had to use Git Bash once to recreate the known_hosts entry, after that I got the Permission denied error again. Somehow I don't get asked for any user input.
I faced this problem while connecting bitbucket cloud from my Intellij 2019.2 , which thankfully got solved with the following steps. Please note that these steps are to be carried out after you successfully generate and add ssh-public key to your bitbucket/github/gitlab profile.
Open Git-SCM ssh_config file present in Git-SCM installation directory.It's default location in Windows (for 64 bit) is in C:\Program Files\Git\etc\ssh\
Add the following lines into ssh_config
Host *your-gitlab-or-github-or-bitbucket-hostname*
IdentityFile *your-ssh-rsa-privatekey-file-with-absolute-path*
for e.g
Host bitbucket.org
IdentityFile C:/Users/Sahil/.ssh/id_rsa
Source:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360004124959-IntelliJ-2019-1-3-Can-t-access-git-using-SSH-keys
Update IDEA 2021.2.3
The bug in Sahil's answer has been fixed and Christian's solution is not needed with the correct entry in your ssh config file for the most common case of one key for one or more hosts. Additional options for complex configurations, such as multiple keys to the same or multiple hosts, can be found in Maddes comprehensive answer on superuser.
ANY inconsistency between ssh-agent and ssh-add leads to a situation where some things work and some don't.
For example, I had the Windows OpenSSH agent running but my path pointed first to the Git for Windows ssh-add. Many such failures are possible given the many ssh implementations out there, so know that you know where things are running from.
To get ssh working in IDEA...
Git for Windows
Install Git for Windows. I put it in C:\Git since, as a standard user without an elevated install, I couldn't write to C:\Program Files.
In Control Panel | User Accounts | Change my environment variables add the Git usr\bin folder to the path after the cmd folder entry already there (e.g. C:\Git\usr\bin for my installation).
Unset environment variable HOME -- it still breaks ssh in this version of IDEA.
In a Windows cmd.exe console, run start-ssh-agent.cmd to start the agent
In IDEA in Settings | SSH Configurations | Authentication type: set it to Key pair OpenSSH or PuTTY and test your connection. Then, make a small change and test Commit and push....
Windows OpenSSH
In Control Panel | User Accounts | Change my environment variables add C:\Windows\System32\OpenSSH to your path. Make sure no other ssh implementation is ahead of this in the path!
Start the OpenSSH agent in Task Manager | Services (or any number of other ways)
Set your IDEA SSH Configuration as #5 above
Keep in mind that, on Windows, ssh in IDEA uses the environment available in a standard Windows command-line console (cmd.exe). If git operations work there, then with the above steps in place, they'll work in IntelliJ.
It has been really long since OP but here is my solution on an execution basis:
You need to open a prompt and set the ENVVAR GIT_SSH_COMMAND.
You need to open IntelliJ from that same prompt.
Example:
> set GIT_SSH_COMMAND=ssh -i C:\\path\\to\\not\\default\\key
> idea
Also the path to not-default-key should use ~ instead of %userprofile% or paths unix-like using /.
I was having this same issue, and while it did have to do with the public key, my issue was concerned with WSL2/Linux and windows .ssh folders. My keys were in my WSL2/linux folder system, but intelliJ was looking in my windows folder system.
I copied my rsa keys from WSL2 to windows, and it worked automatically. In fact, I attempted to have it fail again by removing the keys from the Windows folders, but intelliJ must have it's own keylocker solution, because even without the keys in the Windows .ssh folder intelliJ continued to work.
For a screen capture explaining it you can see it here https://vimeo.com/558267383/74d55415c4
If you're using wsl2 in Clion like me, just add
Host github.com
IdentityFile /home/yieatn/.ssh/github
to /home/user/.ssh/config (create if it doesn't exit). You don't even have to restart IDE.
Adding to Cristian Torres's answer:
For all of you folks struggling with a similar problem on Mac OSX:
In IntelliJ, PyCharm, etc. click Tools -> Create Command-line Launcher...
Open your terminal and execute:
$ export GIT_SSH_COMMAND="ssh -i ~/.ssh/your-custom-private-key"
$ idea
For PyCharm the executable name is charm or /usr/local/bin/charm
Goland: goland or /usr/local/bin/goland
WebStorm: webstorm or /usr/local/bin/webstorm
I have Jenkins running on Windows, and I have a build that works fine under CygWin bash from the CygWin terminal, so I now want to automate it. However, using this script:
#!C:\cygwin\bin\bash.exe
whoami
make
The system reports me as nt authority\system, not the ken that I get when using an interactive shell. Is there an easy way to persuade Jenkins or CygWin to run as me?
Most likely you are running jenkins with default installation. You have two options. First is mentioned in the comment. Change the "Service account" to be same as yours.
Second option is derived from best practices. Run the jenkins master on a system with backup etc. Configure slave node with your account credentials. Change the project configuration to build on the specific node.
(It is possible to run slave and master on same machine with different credentials - just in case you want to try out things)
The real problem I was having was not that the shell script was running as the wrong user, but that the shell script was not executing the default /etc/profile. So, the solution was simply:
#!C:\cygwin\bin\bash.exe -l
whoami
make
I was still nt authority\system, but now I had the correct environment set up and could run make successfully.
Note also that if I create a /home/system directory I can add .bash_profile, etc, to that directory to further customise the build environment.
I have a MAC slave connected to my Jenkins master via Java WebStart (SSH not working).
I have an administrator user called 'qalab' who has logged into the m/c (it never sleeps).
Node system information is shown as the given image.
Now, I need to launch Safari browser via Selenium.
Whenever i run the test with Safari i get the below exception
java.lang.IllegalStateException: The expected Safari data directory does not exist: /Users/null/Library/Safari
(Chrome and Firefox works fine)
Selenium looks for Safari in /Users/ user.name /Library/Safari
I tried like this.
System.setProperty("webdriver.safari.driver", "/Users/qalab/Library/Safari");
But still, it does not seem to take this path and fails with above exception.
Is there any way to fix this?
Also why does it show the user.name as root. How to change it to my user - 'qalab'?
You really don't want to run your slave as Root (which the above information indicates you are doing). Jenkins slaves have no inherent need to have escalated privileges (we run our Master and Slave with non-administrator accounts) as long as your Jenkins home directory is in someplace they can access. In your case, your Jenkins home directory above appears to be /, which is probably not what you want to do, since you will run into permission problems if you aren't root.
Any directory under your qalab user's home should work, as should any other directory that you create as long as the qalab user has privileges to read/write/execute on it (we tend to use a /Development/Jenkins directory, but that's an historical preference for us).
From one of our slaves:
user.dir /Development/Jenkins
user.home /Users/buildbot
user.name buildbot
Our master is similarly configured, and both work fine for us.
I have installed incron from the EPEL repository (before you ask; YES, I also tried downloading the source and compiling locally; same results) and am attempting to set up a process on my CentOS 6.4 (final) virtual box that I have successfully prototyped on my local Ubunto 12.04 machine:
Some information up front:
SELinux is set PERMISSIVE
I have added my script(s) and called executables to all with NOPASSWD using visudo to get around some permissions issues...
If I invoke my script from the command line with sudo /path/to/my/script.sh arguments it works like a charm.
sudo service incrond status verifies that incrond is running. root and myusername are added to /etc/incron.allow, /etc/incron.deny is empty.
My incrotab for root is:
/path/to/dropfolder/ IN_CLOSE_WRITE sudo /path/to/my/script.sh $#/$#
Events in /path/to/dropfolder/ result in exactly NOTHING happening. No logs are generated, no messages, no actions occur on the files in the folder.
So I have researched: it was suggested that cron runs in a minimal environment and that to execute complex commands/scripts you may have to execute your .bashrc and/or export your PATH at the beginning of the cron command.
Note: I can find no documentation supporting that incron also runs in a minimal environment, but as my google-fu (and bing-fu!) failed to result in any helpful results related directly to incron I figured WTH, I'll try that!
Edit: Documentation indicates that incron run from system tables or root takes env from its host enviroment, therefore only incron executed by non-root users should require any sort of env or PATH fiddling
So… incrontab for root:
/path/to/dropfolder IN_CLOSE_WRITE . /home/myusername/.bashrc; export PATH=$PATH:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin; sudo /path/to/my/script.sh $#/$#"
No dice… tried && instead of ; = no dice. If you can think of a variation on the above I've probably tried it…
So, lets try a little restorecond -R /usr/sbin/incrond /etc/incron* action!
Huh, no change there either.
service incrond stop followed by service incrond start and then service incrond restart … nope, nope, and nope.
Drastic measures: yum remove incron and yum install incron, chkconfig incrond on and then for good measure a sudo reboot!
Nothing.
I don't even get anything from /tmp/ IN_ALL_EVENTS echo boo>>/home/myusername/boofile.txt, hence my inability to even do an env>>envfile.txt to check whether incron is running in a sparse environment… (see above note)
And yet: service incrond status yields incrond (pid xxxx) is running...
What am I missing? It has to be big and obvious and I hope someone can make me feel like an idiot in short order!
further examination of /var/log/cron yields results like this: Aug 14 15:05:30 hostname incrond[1584]: (root) CMD (sudo /path/to/DropFolder/script/subfolder/script-Beta-1.sh /home/username/DropFolder/testfile.file) -yes I made sure my script was executable..
so incrond is indeed attempting to do SOMETHING, but I get no output anywhere... even a simple echo > /dev/pts/0 produces nada results.
thanks for fixing my crap formatting job
Ok, here's the answer:
Despite all documentation I can find declaring it to be the contrary, incrond under CentOS 6.4 runs in a sparse environment and behaves as cron. this is NOT the case under Ubuntu, where incron inherits its environment from root for system tables and root tables and only user tables run in a sparse environment. This of course means that if you're calling a script (I am) the script needs to build it's environment and every thing must have a full path. EVERYTHING. (well, except for shell builtins :p)
numerous Google and and Bing and Stack Overflow and Server Fault searches all told me that cron operates this way, but they all also seemed to indicate that incron operates as described in the documentation, which it DOES under Ubuntu...
Bottom line, it works now, yay!
I guess this just goes to show: when in doubt define the environment and use full paths... er, actually, just do that all time and save yourself a headache.
(this does not address my problem with applying a SELinux security policy for incron, but I'll worry about that later, in another post...)