ssh authorized_keys file location and permissions - authentication

I am confused on the permissions that ssh requires when dealing with custom authorized_keys files.
For example, assuming that we have a server with the following line in /etc/ssh/sshd_config:
AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/authorized_keys
It means that theoretically we can access the server with all the keys inserted in those two files, considering that .ssh/authorized_keys is a per-user file (meaning that we can log in with user root using the keys in /etc/ssh/authorized_keys and /home/root/authorized_keys).
Now, how can this even work for a non-root user for /etc/ssh/authorized_keys, if when using the default mode StrictMode yes does not allow to use of the authorized_keys file unless the parent folders are with permission 0600 and owned by the user (which is not the case here) and the file is owned by the user and has permission 0700 (that we can assume is the case)?
Ssh won't accept the keys in /etc/ssh/authorized_keys for a non-root user, since the permission are not correct for that user (the owner of /etc/ssh is root).
Or am I missing something?

Related

SSH keys are added to default location and not to specified AuthorizedKeysFile in sshd_config

I want to change the location where the Authorized SSH keys are saved. Therefore, I changed the location of the authorized keys file in /etc/ssh/sshd_config to
AuthorizedKeysFile /etc/ssh/authorized_keys/%u/authorized_keys
The ssh service was restarted with sudo systemctl restart ssh and the owner and group of the /etc/ssh/authorized_keys/user directory is the right user/group.
The server is accessible for the already included ssh keys in /etc/ssh/authorized_keys/user/authorized_keys, but adding a new ssh key from some other device to the server with ssh-copy-id -i ~/.ssh/id_rsa user#server saves the key in the default directory ~/.ssh/authorized_keys.
Grateful for any advice or help!
For anybody coming by this later, ssh-copy-id is on the client, and the sshd_config is on the server. It cannot know where to write to. It assumes the default location.
Furthermore, you don't want every user able to write into /etc/ssh/authorized_keys anyway. If you've specifically set ownership to the user for /etc/ssh/authorized_keys/user then there's no obvious benefit vs having it in the default location. The advantage of doing what you've suggested is for centralized management of keys, an advantage you only have if the users are NOT permitted to write to it.

can't login by ssh aftcher chmod on home folder

I've done a chmod 777 on my home folder, where the .ssh folder is, and now I cannot login.
I've restored permission on all files but still cannot login. Should I change anything in order to be able to login again.
I get this message: Server refused our key
On other servers I can login properly.
Thank you.
ssh rejects key-based logins if permissions allow other people to tamper with your authorized_keys file. You need to check /, /home, /home/yourname, /home/yourname/.ssh and /home/yourname/.ssh/authorized_keys. All of those must not be group or world writeable.
Typically you want the .ssh directory permissions to be 700 (drwx------) and the public key (.pub file) to be 644 (-rw-r--r--). Your private key (id_rsa) should be 600 (-rw-------).
Stolen from: Permissions on private key in .ssh folder?

Assigning public key to user's login

I have a Centos 6.4 server and I need to assign certificate to user's login so that he doesn't need to enter password during login. The user has already provided the id_rsa.pub -file. I don't have his credentials and I'm working with the root account
The was no .ssh directory under his home folder so I created one, but I don't know how to advance from here..
so, as root you need to create a $HOME/.ssh/authorized_keys with the right owner and permissions. Something like this should work
cd /home/theuser
mkdir .ssh
cp /some/path/id_rsa.pub .ssh/authorized_keys
chown theuser .ssh .ssh/authorized_keys
chmod 700 . .ssh .ssh/authorized_keys
the permission may not have to be so tight but if it's to loose ssh won't allow the key to be used and complain about it in some syslog.

Unable to connect using SSH to the pushed MobileFirst container image on Bluemix

I have built an MF container image and pushed it. I have copied the file in (Mac) ~/.ssh/id_rsa.pub to mfpf-server/usr/ssh before building the image.
I am trying to connect using the command in Mac terminal:
ssh -i ~/.ssh/id_rsa admin#public_ip
It says:
Permission denied (publickey).
Any idea? What is the user I shall use?
your problem is very probably related to the permissions of the pub key copied on the container or to the configuration of your key.
You could check the permissions of key copied on the container, sshd is really strict on permissions for the authorized_keys files: if authorized_keys is writable for anybody other than the user or can be made writable by anybody other than the user, sshd will refuse to authenticate (unless sshd is configured with StrictModes no)
Moreover such a problem won't be showed using ssh -v, it will showed only on daemon logs (on the container)
From man sshd(8):
~/.ssh/authorized_keys
Lists the public keys (RSA/DSA) that can be used for logging in
as this user. The format of this file is described above. The
content of the file is not highly sensitive, but the recommended
permissions are read/write for the user, and not accessible by
others.
If this file, the ~/.ssh directory, or the user's home directory
are writable by other users, then the file could be modified or
replaced by unauthorized users. In this case, sshd will not
allow it to be used unless the StrictModes option has been set to
“no”.
So I suggest you to check about the files and directories permissions.
Then check that the content of your pub key has been copied correctly on authorized_keys listing
/root/.ssh/authorized_keys
To access the container with the ssh key you need to use the "root" user.
ssh -i ~/.ssh/id_rsa root#<ip address>

Store a private key outside of ~/.ssh

I have to deal with a rather annoying situation. I must transfer a file via shell script using scp from one server to another. The problem is that I do not have root access on either of them. I'm not allowed to install any packages like, sshpass, ssh2, expect etc. I don't even have write permission in the home directory of the user I have to use on the second server.
Since I can't use sshpass etc. to enable my script to enter the login credentials, I thought about using an ssh keypair for auth. Actually that was my first thought, but since the user on the second server doesn't have write permissions in its home directory but only in a subsequent directory, ssh-keygen fails as it can't put the keys in ~/.ssh.
Both are Debian servers btw.
Is there any way to generate a ssh keypair and use it outside of ~/.ssh?
Any help is greatly appreciated.
On the clientside yes. However, on serverside, unless configured differently, sshd will expect your credentials in that directory.
If you can scp from the server where you can't access .ssh to the one where you can, you can use -i option to specify the keyfile location.
Do you have an alternative transport mechanism? Can you put the filn your public_html and wget it on the other side?
You can have the keypairs anywhere. What is key is that the permissions are set correctly on the keypair. The ownership needs to be set to the user chown user:user keyfile and the permissions must be chmod 400 keyfile.
Once you have your key moved and permissions set all that's left is to tell scp which key to use. You can do this by using the -i flag.
IE: scp /source/file user#host:/target/location/ -i keyfile
Edit:
As Amadan alluded to in his answer - this assumes the server you're connecting to already has the key as an authorized key on the user. If not it would require an /etc/ssh/sshd_config change that only someone with the right access can do. It might be worth trying a cat /etc/ssh/sshd_config on the server if your user has access to it at all right now. If you have read access you'll be able to discern the expected authorized_keys location. It's possible the server admin has already customized the expected key location to something you have write access to.