I'm setting up monit to monitor vps and when I add pem file, monit said that it does not have permissions so should I change pem file permission to 700?
Permission 700 is not needed to .pem file since it says the .pem is executable to the owner (besides being readable and writable). Pemission 600 means just read/write to the owner.
Your monit might be running as a different user (not the owner of the .pem file) so it has no permission. Remember that you .pem file may contain your private key and you don´t want to "others" have access to it, so open permission to others read the .pem file may be a secure breach. If you choose to go forward you can:
chown .pem to same user as monit run
make monit run as the same user that owns the .pem
put 650 permission to .pem file, make it same group as monit and garantee that monit is the only member of that group*
try use ACL
*This solution may cause other problems if application that use .pem file checks for permissions (like ssh do).
Ask yourself if this is really necessary.
Related
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?
I'm in the process of setting up a virtual server via Amazon AWS. I followed their tutorial regarding setting up a Linux based virtual server on OS X. Everything goes well until I get to the .ssh pair key file. I download AWS's key as a .pem file. It saves as a .pem.txt file. Which seems odd from what I'm reading. So, I duplicate and change the extension to .pem only.
Then I go to copy the file from downloads to the ~/.ssh folder and get no problems using cp ~/Downloads/FileName.pem ~/.ssh. When I try to use chmod 400 to adjust the security parameters of the folder it returns "Not a directory". When I try to authenticate it fails. I suspect because it has something to do with the chmod 400 code line, but I'm not certain. I also wanted to verify to make sure the file copied into the .ssh folder, but all of the suggestions online about unhiding the hidden folders on a Mac were a no-go.
It is a Linux set up so the user name is the one listed in the tutorial (I already researched this problem). I double check to see if there was a file .ssh and there seems to be. When I type ssh in the terminal I do get feedback, so I'm assuming there is a file there.
Create an ssh folder in your home folder, if one is not present. Then copy the PEM file to that folder. Then change permissions of the PEM file to protect it. Something like this:
mkdir -p ~/.ssh
cp fred.pem.txt ~/.ssh/fred.pem
chmod 400 ~/.ssh/fred.pem
I have a problem while I am logging to my SSH server using OpenSSH (note: i am on windows and i need to use OpenSSH)
Permissions 0644 for 'privkey.ppk' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: privkey.ppk
Enter passphrase for key 'privkey.ppk':
Permission denied (publickey).
First of all, you need to convert the PPK file format to OpenSSH format, if you want to use it in SSH.
Second thing is that the private key should not be readable by anyone else but you. So setting permissions to 600 is a good idea (chmod 600 privkey.ppk).
You should change the file permission to 400 not 600.
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>
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.