Keys are properly deployed in ~/.ssh/authorized_keys
Yet ssh keeps on prompting for a password.
Several issues, mostly privileges - but also related to SELinux on RedHat 6
The following script should fix them all, please replace <user>:<group> with your matching userid and group
chown -R <user>:<group> ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
restorecon -R -v ~/.ssh
I'd agree with the changes above working on most linux variants in the root account.
I have had a problem with RedHat 6.3 with trying to get a postgres user account to use DSA auth. (6.3 running in VirtualBox)
The issue can be that the basic selinux permissions are wrong. Restorecon wont help in this case.
(After restorecon)
drwx------. postgres postgres unconfined_u:object_r:var_lib_t:s0 .ssh
I have fixed this with :
chcon -R -t ssh_home_t .ssh
This resolved this instance of the problem.
I had also this same issue, the proposed solution above did not solve the case for me. To summarise instructions abowe together:
Check following logfile on target system for possible details of errors: /var/log/secure
Permission of files in users ~/.ssh directory should be 600 and files should be owned By "user:group"
Permission of ~/.ssh directory should be 700 and owned By "user:group"
Permission of home directory of user ie. "~" (="~/.ssh/..") should be 755. If permissions are f.ex 775, ssh key autenthication failed in my system.
br
bruno
The above answer is quite good, I have an addition & a suggestion. The addition is in line 2 below, as home directory permissions not be more permissive than rwxr-x--- for ssh key authentication.
cd ~
chmod g-w,o-rwx .
chmod 700 .ssh
cd .ssh
chmod 600 *
chmod 644 authorized_keys
chmod 644 known_hosts
chmod 644 config
restorecon -R -v ../.ssh
The suggestion is to make use of the -vv option when testing.
Related
I'm trying to save a file called app.js on a folder called js.
Vs Code pop up this:
Failed to save 'app.js': Unable to write file 'vscode-remote://wsl+ubuntu-18.04/js/app.js'
(NoPermissions (FileSystemError): Error: EACCES: permission denied, mkdir '/js')
I tried:
sudo chown -R user /mnt/c/Users/myUser/Documents/myFolder/proyectFolder
but I still can't save this file.
Try this, fixed it for me
sudo chown -R username path
Example:
sudo chown -R emanuel /home/emanuel/test/
In the SSH terminal:
Recommended :
sudo chmod -R 777 folder_name_where_your_file_exists
or
sudo chmod -R 755 folder_name_where_your_file_exists
this works for me
sudo chown -R $USER:$USER /home/
TLDR;
If you're using a docker container, avoid making files from within the container because the owner and group permissions may cause problems with your editor (in my case VS Code)
I was running docker container for a Django project from Windows Terminal and using VS Code to edit my code.
It is a Linux file (since everything in Linux is a file) permission problem that arises because the files don't have proper user and/or group permissions. So VS Code tries to tell us that.
The problem I found only happened when I created files from within my docker container.
I would run docker exec ... bash
make new files using touch /path/to/file from the container bash
then try to edit those files on VS Code (say urls.py) only to get the scary permissions error preventing the file from saving.
I suspect that making files from within the container embellishes those files with different owner and group settings than your system would default to if you just ran the commands locally (not in the container).
Changing the file permissions with chown -hR and chgrp -hR would do the trick but to avoid the error altogether I stopped making files from within the container.
Try activating polling:
This worked for me during I tried using wsl.
The below is for individual file:
sudo chown yourUserNAme filename
For an entire directory it will be (when you write ls to terminal, you should see your directory to execute this command):
sudo chown yourUserNAme dirName
For recursive (i.e files and folders inside a folder):
sudo chown -R yourUserNAme dirName
Note: yourUserNAme is, if you do pwd under any Documents, you will see the path: /home/jhon/Documents. Here user is jhon.
Run VS Code as administrator and it will fix the problem.
https://answers.microsoft.com/en-us/windows/forum/all/error-in-vs-code-destination-directory-and-says/e70dc626-6b12-4791-a960-8b704e57098d
Install the extension Save as Root in Remote SSH in VS code.
While saving press Ctrl + Shift + P.
This open the command palette.
Search Save as Root
It is a Linux user permissions problem.
you should use the command:
sudo chown -R $USER:$USER.
I am trying to run multiple mongod instances on the same centos machine with different config files.
I am getting following error while running the instance as a service:
sudo service mongod1 start
/var/lib/mongo1: boost::filesystem::status: Permission denied: "/var/lib/mongo1/mongod.lock"
I have added the permissions for the /var/lib/mongo1 using:
sudo chmod -R 600 /var/lib/mongo1
I also tried with 700, 755 and 777 at the end but nothing seems to work.
mongod:mongod is the owner of the folder /var/lib/mongo1
Any help is appreciated.
I know this is really late but I was struggling with this for days and just now found the fix. That being said for future users running into this issue the solution if you're using SELinux is to check the context of the default mongodb path against your own to make sure they are the same by executing
ls -dZ /var/lib/mongo/
the output should look something like this
drwxr-xr-x. mongod mongod system_u:object_r:mongod_var_lib_t:s0 /var/lib/mongo/
if it's not then you can copy it by doing
chcon -R --reference=/var/lib/mongo /your/path
the source can be found here
Maybe the lock file is missing? Which might explain why chmod isn't having the desired effect...
Try:
touch /var/mongo1/mongod.lock
chown mongod:mongod
chmod 600 /var/mongo1/mongod.lock
important :
Don't try to restart mongo using sudo as it tries to change the user to root where as /var/lib/mongodb owner is mongod:mongod
Please remember that Directories needs to have execute permission, but the files within the directories do not need to execute permission.
The following 2 commands worked for me
$ sudo chmod -R 770 /var/lib/mongo1
$ sudo find /var/lib/mongo1 -type f -exec chmod 660 {} \;
This will first give everything under /var/lib/mongo1 execute permission, and then return all the normal files to having only read and write, but not execute.
I believe I ended up mixing up permissions at /etc/ssl directories tree as the last modification was made on 18th November and a day after I could not get my PostgreSQL to work.
When I type in
sudo service postgresql start
I get
FATAL: could not access private key file “/etc/ssl/private/ssl-cert-snakeoil.key”: Permission denied
Checking permissions
~$ sudo -i
~$ ls -la /etc/ssl/private
drw-r----- 2 root ssl-cert 4096 Nov 18 21:10 .
-rwxrwxrwx 1 postgres postgres 1704 Set 4 11:26 ssl-cert-snakeoil.key
Checking group composition
~$ id postgres
uid=114(postgres) gid=127(postgres) groups=127(postgres),114(ssl-cert)
Also I noticed that my ssl-cert-snakeoil.pem file at /etc/ssl/certs/ doesn't have a symlink. I don't know if this makes any difference...
Please, help me sort this out.
Thanks.
Edit: Should it be posted on serverfault instead?
Try adding postgres user to the group ssl-cert
Run the below code to fix your issue:
# > It happened to me and it turned out that I removed erroneously the postgres user from "ssl-cert" group, set it back with
sudo gpasswd -a postgres ssl-cert
# Fixed ownership and mode
sudo chown root:ssl-cert /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 740 /etc/ssl/private/ssl-cert-snakeoil.key
# now postgresql starts! (and install command doesn't fail anymore)
sudo /etc/init.d/postgresql start
courtsey to GabLeRoux
Check the output of
$ sudo -u postgres
$ cd /etc/ssl/private
$ ls
If the response is "Permission denied" do
$ chown postgres:ssl-cert /etc/ssl/private/
$ chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
Only thing that will work if you have changed permissions for /etc/ssl/private
mkdir /etc/ssl/private-copy; mv /etc/ssl/private/* /etc/ssl/private-copy/; rm -r /etc/ssl/private; mv /etc/ssl/private-copy /etc/ssl/private; chmod -R 0700 /etc/ssl/private; chown -R postgres /etc/ssl/private
Copy this whole command (It's a one line code).
If this doesn't work for you, ckeck your postgres user groups by groups postgres and make sure your postgres user have ssl-cert root postgres (Order doesn't matter).
Now lets check your file permissions on ssl/private :
$ ls -la /etc/ssl/
> drwx------ 2 postgres root private
If this is not the output change your permissions with sudo chmod -R 700 /etc/ssl/private and for owners chown -R postgres:root /etc/ssl/private
//Now check permissions on ssl-cert-snakeoil.key,
//which will be inside your **private** directory.
$ ls -la /etc/ssl/private/ssl-cert-snakeoil.key
> -rwx------ 1 postgres root /etc/ssl/private/ssl-cert-snakeoil.key
I was suffering from this issue when attempting to start Postgresql on a remote docker instance. I eventually tracked down the crazy solution here. Basically you have to recreate the directories, chown on it's own doesn't work:
mkdir /etc/ssl/private-copy; mv /etc/ssl/private/* /etc/ssl/private-copy/; rm -r /etc/ssl/private; mv /etc/ssl/private-copy /etc/ssl/private; chmod -R 0700 /etc/ssl/private; chown -R postgres /etc/ssl/private
This error was preventing my PostgreSQL server from running locally.
The following worked for me:
sudo chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 600 /etc/ssl/private/ssl-cert-snakeoil.key
Also make sure that /etc/ssl/private has enough permissions.
Some programs can be incredibly pedantic and cost you valuable hours. By running journalctl after sudo systemctl start postgresql I'd see various errors like:
FATAL: could not load private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
FATAL: private key file "/etc/ssl/private/ssl-cert-snakeoil.key" must be owned by the database user or root
FATAL: private key file "/etc/ssl/private/ssl-cert-snakeoil.key" has group or world access
DETAIL: File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.
I couldn't make it with work sudo chmod root:root, so I had to settle for sudo chmod postgres:postgres.
EDIT
I haven't tried it, but running deleting and regenerating the snakeoil certificate might work as well:
make-ssl-cert generate-default-snakeoil --force-overwrite
(You may have to run it with sudo, don't know.)
Try setting permissions on the .key file to 600. Postgres doesn't like key files with group or world permissions set. You may also need to change the owner to postgres, though I'm not sure about that.
I am running the postgres server in WSL, and I was facing the error with the ssl-cert file. I managed to make it work by changing the owner of the file to the postgres user I had created, adding the expected user and group IDs to the user as required of the application (111 and 116, respectively, as gleaned from helpful error messages), and voila, I have an active server from within WSL.
sudo useradd postgres
sudo usermod -u 111 -g 116 -a -G ssl-cert postgres
sudo chown postgres /etc/ssl/private/ssl-cert-snakeoil.key
After running the above, there were two more files the user running the server (postgres for me) needed permission to access, both residing in /var/postgresql. I used sudo chown -- twice more to give ownership to postgres. Running sudo service postgresql start will tell you which files you'll need to transfer ownership of through any error messages.
I had other certificates under /etc/ssl/private and hence, changing permissions recursively was out of question.
I tried adding postgres user to ssl-cert group that didn't help either.
I modified the permission of /etc/ssl/private to 716, basically saying that anyone else other than root (user) and ssl-cert (group) can read and execute the directory.
sudo chmod 716 /etc/ssl/private
Then, I modified the ownership of ssl-cert-snakeoil.key
sudo chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
This worked for me, basically a combination of the answers by #devops and #Noushad
Mac OSX Lion 10.7.
In an effort to get around weird environment stuff (homebrew wasn't installing wget, and I had all sorts of weird blocks and errors), I uninstalled zschrc and homebrew and a bunch of other stuff, then installed fish shell.
Now, whenever I try to push/pull to/from github, I get this error:
The authenticity of host 'github.com (204.232.175.90)' can't be established.
RSA key fingerprint is <string of colon-separated chars that I should probs keep private>.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/Users/sasha/.ssh/known_hosts).
So I tried to check the permissions of my ~./ssh folder, and got this, which looks fine to me:
-rw-r--r-- 1 sasha staff 97B Jul 9 22:56 config
-rw------- 1 sasha staff 1.7K May 16 2012 id_rsa
-rw-r--r-- 1 sasha staff 403B May 16 2012 id_rsa.pub
drwx------ 5 sasha staff 170B Jul 15 09:56 known_hosts
All that's in known_hosts is a pem file I used for ssh'ing (also with the "authenticity..." prompt) to an Amazon ec2 instance, though I tried copying id_rsa and id_rsa.pub there when things got desperate.
Any idea what's going on? I'd love to fix this so I don't get prompted all the many times I push/pull.
EDIT I followed these instructions successfully a while ago, so I do have my ssh keys on Github, and they're recognized, so that when I run ssh -T git#github.com, I get
Hi sashafklein! You've successfully authenticated, but GitHub does not provide shell access.
It seems to be exclusively my local computer that's unhappy with my ssh situation.
In your specific case, your known_hosts is a folder, so you need to remove it first.
For other people which experiencing similar issue, please check the right permission to your ~/ssh/known_hosts as it may be owned by different user (e.g. root). So you may try to run:
sudo chown -v $USER ~/.ssh/known_hosts
to fix it.
This is the solution i needed.
sudo chmod 700 ~/.ssh/
sudo chmod 600 ~/.ssh/*
sudo chown -R ${USER} ~/.ssh/
sudo chgrp -R ${USER} ~/.ssh/
For guys on Ubuntu, if you get this error:
Failed to add the host to the list of known hosts
Then simply delete the known_hosts file, and re-run your ssh. This will regenerate the known_host file with appropriate permissions, and add the remote host you are trying to ssh into to this file.
I think the OP's question is solved by deleting the ~/.ssh/known_hosts (which was a folder, not a file). But for other's who might be having this issue, I noticed that one of my servers had weird permissions (400):
-r--------. 1 user user 396 Jan 7 11:12 /home/user/.ssh/known_hosts
So I solved this by adding owner/user PLUS write.
chmod u+w ~/.ssh/known_hosts
Thus. ~/.ssh/known_hosts needs to be a flat file, and must be owned by you, and you need to be able to read and write to it.
You could always declare known_hosts bankruptcy, delete it, and continue doing things as normal, and connecting to things (git / ssh) will regenerate a new known_hosts that should work just fine.
Shouldn't known_hosts be a flat file, not a directory?
If that's not the problem, then this page on Github might be of some help. Try using SSH with the -v or -vv flag to see verbose error messages. It might give you a better idea of what's failing.
This command worked for me,
sudo chown -v $USER ~/.ssh/known_hosts
as mentioned by #kenorb.
The error was coming due to broken permissions, for the current user.
Okay so ideal permissions look like this
For ssh directory (You can get this by typing ls -ld ~/.ssh/)
drwx------ 2 oroborus oroborus 4096 Nov 28 12:05 /home/oroborus/.ssh/
d means directory, rwx means the user oroborus has read write and execute permission. Here oroborus is my computer name, you can find yours by echoing $USER. The second oroborus is actually the group. You can read more about what does each field mean here. It is very important to learn this because if you are working on ubuntu/osx or any Linux distro chances are you will encounter it again.
Now to make your permission look like this, you need to type
sudo chmod 700 ~/.ssh
7 in binary is 111 which means read 1 write 1 and execute 1, you can decode 6 by similar logic means only read-write permissions
You have given your user read write and execute permissions. Make sure your file permissions look like this.
total 20
-rw------- 1 oroborus oroborus 418 Nov 8 2014 authorized_keys
-rw------- 1 oroborus oroborus 34 Oct 19 14:25 config
-rw------- 1 oroborus oroborus 1679 Nov 15 2015 id_rsa
-rw------- 1 oroborus oroborus 418 Nov 15 2015 id_rsa.pub
-rw-r--r-- 1 oroborus root 222 Nov 28 12:12 known_hosts
You have given here read-write permission to your user here for all files.
You can see this by typing ls -l ~/.ssh/
This issue occurs because ssh is a program is trying to write to a file called known_hosts in its folder. While writing if it knows that it doesn't have sufficient permissions it will not write in that file and hence fail. This is my understanding of the issue, more knowledgeable people can throw more light in this.
Hope it helps
to me, i just do this :
rm -rf ~/.ssh/known_hosts
then :
i just ssh to the target host and all will be okay.
This only if you dont know, what permission and the default owner of "known_hosts" file.
just in case anyone else encounters this error message and the permissions on .ssh and .ssh/known_hosts look good.
My problem was that I had installed gh from snap and snap apps have limited access to the file system and apparently could not access .ssh. The solution is to remove the snap installation and install from apt.
It happened to me simply because of broken permissions. My user did not have read nor write access to that file. Fixing permissions fixed the problem
I generated the "ssh" key again and added to my git account. This worked for me.
Please find following commands to generate the "ssh-key":
$ ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
-> This creates a new ssh key, using the provided email as a label.
Generating public/private rsa key pair.
-> When you're prompted to "Enter a file in which to save the key," press Enter. This accepts the default file location.
Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]
-> At the prompt, type a secure passphrase. For more information, see "Working with SSH key passphrases"
Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]
-> Your key is generated, to copy the key:
$ sudo cat /root/.ssh/id_rsa-pub
Hope this works!
For anyone interested, this one worked for me in Ubuntu:
Go to .ssh directory.
$ cd ~/.ssh
Remove the known_hosts file.
$ rm known_hosts
Re-push your Git changes.
I was having this issue and found that within ~/.ssh/config I had a line that read:
UserKnownHostsFile=/home/.ssh-agent/known_hosts
I just modified this line to read:
UserKnownHostsFile=~/.ssh/known_hosts
That fixed the problem for me.
It may be due to the fact that the known_hosts file is owned by another user i.e root in most cases.
You can visit the path directory given (/home/taimoor/.ssh/known_hosts in my case) and check if the root is the owner and change it to the default owner.
Example:
Error Description -
Before changing the owner -
After changing the owner -
"Failed to add the host to the list of know hosts"
Was also my error.
I tried chancing owner and rights.
And then i did see that it tried to write to "~/.ssh/known_hosts.d/"
Failed to add the host to the list of known hosts (~/.ssh/known_hosts.d/<hostname>).
if this also happens to you,
just create the folder:
mkdir ~/.ssh/known_hosts.d
chmod 700 ~/.ssh/known_hosts.d
While this wouldn't have Solved the Problem of the Original Poster, (since his system tryed to write to the "~/.ssh/known_hosts" file and not to an systemd directory like "~/.ssh/known_hosts.d/") i thought it would help others who searched for the same error message.
The difference is that when an system tries to write to an known_hosts file all host data will be contained there.
While in the directory it will create an file for each host in that directory.
For more info on such directories -> https://askubuntu.com/questions/7648/many-directories-have-a-d-suffix-extension-what-does-it-mean
#check permissions of directory and files.
ls -la ~/.ssh/
#in my case, ~/.ssh/known_hosts was owned by root.
sudo chown xxx:xxx ~/.ssh/known_hosts
#where xxx = my username
#then ssh to some server, the warning message will still appear until you have ssh'd in successfully once, to verify, exit and ssh in again.
Check permissions of the file, if it is good check parent directories
I had to correct
/home/sravindr/.ssh permissions which worked for me
it works with me when I tried the following commands
sudo chown $my_user .ssh/id_rsa
sudo chown $my_user .ssh/id_rsa.pub
sudo chown $my_user .ssh/known_hosts
This command worked for me,
sudo chmod +x ~/.ssh/known_hosts
I couldn't solve this despite all the above answers.
My solution was to move from ssh to https.
I am getting a 500 error because the owner of some of my files is set incorrectly, its set at 0 0 when the rest are at 510 510?? How do I fix this, I've read something about ssh?
Yes, SSH is right. You need to use SSH to connect to your server (using openssh and the "ssh" program in Linux, or PuTTy in Windows) and issue the command webdestroya already posted:
$ ssh yourserver -l username <host>
OR
$ ssh yourserver [username#]<host>
And then issue the command to change your file permissions:
$ chown 510:510 thefile.file
chown 510:510 thefile.file
If it is a linux server, you can use the chown and chgrp commands to change the owner and group of a file.
You can also use the chmod command to change the permissions of a given file - EG: 777 means that everyone has access to a file (probably not what you want, just an example: