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>
Related
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.
Trying to connect Cloud9 to my Digital Ocean droplet and I'm getting:
Cloud9 couldn't connect to SSH server
I've added the ssh public key into my .ssh/authorized_keys file and I know I can connect via ssh. Is there any way to get more info than just that is can't connect?
David
You need to add public key from your profile to .ssh/authorized_keys (not hosts) and make sure that .ssh/authorized_keys file belongs to you and have can be read written only by the owner (should say -rw------- when doing ls -la ~/.ssh)
To get a bit more info, you can try SSHing into your server from one of your other Cloud9 workspaces. Since your Cloud9 SSH key is the same across all workspaces, you'll be able to check if your key has been properly added to the server this way.
I wasn't able to figure out how to get more info on this but I was able to figure out that it was permissions on the .ssh/authorized_keys file / directory. Thanks again for all the help
David
Just finished chatting with cloud9 support and got this working. It's important to note that there are THREE items that require specific permissions:
you user home folder (~) folder should be drwxr-xr-x
your ~/.ssh folder should be drwx------
your ~/.ssh/authorized_keys folder should be -rw-------
Here's in my case
check your instance security groups and ACL
check your sshd_config, ssh, and PAM auth (default is fine, but in my case I mistakenly set PubKeyAuthentication to No), I tried to mimic the ssh connection with ssh -vvv user#ip_address from another server (after putting the public key in the ~/.ssh/authorized_keys file), make sure it's -rw-------
check for the files and folders permission, especially in the ~/.ssh folder
check incoming connection errors in /var/log/auth.log
check for node js if it's installed
put the node path (use which node command)
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.
I would like to setup a rsync a folder inside /etc, I followed this link http://news.softpedia.com/news/How-to-Use-RSA-Key-for-SSH-Authentication-38599.shtml and created one user added in visudo and then with ssh keygen, transferred the public key to remote machine, but still its asking for password.
Any other way would be recommended.
Thanks.
The link that you gave us is right, but there is something that they miss. In the backup-server you must change the file /etc/ssh/sshd_config, uncomment this line
AuthorizedKeysFile .ssh/authorized_keys
and your no password access should be working. In resume:
Client (where you have yours original files)
In a terminal write:
$ ssh-keygen -t rsa
this create the id_rsa.pub file in /home/USER/.ssh/
Server (where you will backup yours files)
modify the ssh_config file:
#nano /etc/ssh/sshd_config
and uncomment the line
AuthorizedKeysFile %h/.ssh/authorized_keys
and now just copy the content of .ssh/id_rsa.pub(Client) at the end of .ssh/authorized_keys(Server) and the no-password will be working(to connect from Client to Server). Maybe you need to restart your ssh server with
/etc/init.d/ssh restart
To make your rsync just do (you don't gave us too much information, but I suppose this)
rsync -az --delete --progress /etc/ server:destinationFolder/
this will make a backup of /etc/ in the Client to destinationFolder/ in the Server, show you the progress of the backup, will delete the file that are not in the source and will send compress the files. The access permissions to the .ssh/ directory in the Server must be 700, i.e: chmod -R 700 .ssh/
Possible errors:
1."Agent admitted failure using the key"
Sol: After you disconnect from the server (logged with the password) you must type in your client terminal ssh-add
I was given some login information for an EC2 machine, basically an ec2-X-X-X.compute-X.amazonaws.com plus a username and password.
How do I access the machine? I tried sshing:
ssh username#ec2-X-X-X.compute-X.amazonaws.com
but I get a Permission denied, please try again. when I enter the password. Is sshing the right way to access the EC2 machine? (Google hits I found suggested that you could ssh into the machine, but they also used keypairs.) Or is it more likely that the problem is that I was given invalid login credentials?
If you are new to AWS and need to access a brand new EC2 instance via ssh, keep in mind that you also need to allow incoming traffic on port 22.
Assuming that the EC2 instance was created accepting all the default wizard suggestions, access to the machine will be guarded by the default security group, which basically prohibits all inbound traffic. Thus:
Go to the AWS console
Choose Security Groups on the left navigation pane
Choose default from the main pane (it may be the only item in the list)
In the bottom pane, choose Inbound, then Create a new rule: SSH
Click Add rule and then Apply Rule Changes
Next, assuming that you are in possession of the private key, do the following:
$ chmod 600 path/to/mykey.pem
$ ssh -i path/to/mykey.pem root#ec2-X-X-X.compute-X.amazonaws.com
My EC2 instance was created from a Ubuntu 32-bit 12.04 image, whose configuration does not allow ssh access to root, and asks you to log in as ubuntu instead:
$ ssh -i path/to/mykey.pem ubuntu#ec2-X-X-X.compute-X.amazonaws.com
Cheers,
Giuseppe
Our Amazon AMI says to "Please login as the ec2-user user rather than root user.", so it looks like each image may have a different login user, e.g.
ssh -i ~/.ssh/mykey.pem ec2-user#ec2-NN-NNN-NN-NN.us-foo-N.compute.amazonaws.com
In short, try root and it will tell you what user you should login as.
[Edit] I'm supposing that you don't have AWS management console credentials for the account, but if you do, then you can navigate to the EC2->Instances panel of AWS Management Console, right click on the machine name and select "Connect..." A list of the available options for logging in will be displayed. You will (or should) need a key to access an instance via ssh. You should have been given this or else it may need to be generated.
If it's a Windows instance, you may need to use Remote Desktop Connection to connect using the IP or host name, and then you'll also need a Windows account login and password.
The process of connecting to an AWS EC2 Linux instance via SSH is covered step-by-step (including the points mentioned below) in this video.
To correct this particular issue with SSH-ing to your EC2 instance:
The ssh command you ran is not in the correct format. It should be:
ssh -i /path/my-key-pair.pem ec2-user#ec2-198-51-100-1.compute-1.amazonaws.com
Note, you need access to the private key (.pem) file to use in the command above. AWS prompts you to download this file when you first launch your instance. You will need to run the following command to ensure that only your root user has read-access to it:
chmod 400 /path/to/yourKeyFile.pem
Depending on your Linux distribution, the user you need to specify when you run ssh may be one of the following:
For Amazon Linux, the user name is ec2-user.
For RHEL, the user name is ec2-user or root.
For Ubuntu, the user name is ubuntu or root.
For Centos, the user name is centos.
For Fedora, the user name is ec2-user.
For SUSE, the user name is ec2-user or root.
Otherwise, if ec2-user and root don't work, check with your AMI provider.
You need to enable an inbound SSH firewall. This can be done under the Security Groups section of AWS. Full details for this piece can be found here.
For this you need to be have a private key it's like keyname.pem.
Open the terminal using ctrl+alt+t.
change the file permission as a 400 or 600 using command chmod 400 keyname.pem or chmod 600 keyname.pem
Open the port 22 in security group.
fire the command on terminal ssh -i keyname.pem username#ec2-X-X-X.compute-X.amazonaws.com
Indeed EC2 (Amazon Elastic Compute Cloud) does not allow password authentication to their instances (linux machines) by default.
The only allowed authentication method is with an SSH key that is created when you create the instance. During creation they allow you to download the SSH key just once, so if you loose it, then you have to regenerate it.
This SSH key is only for the primary user - usually named
"ec2-user" (Amazon Linux, Red Hat Linux, SUSE Linux)
"root" (Red Hat Linux, SUSE Linux)
"ubuntu" (Ubuntu Linux distribution)
"fedora" (Fedora Linux distribution)
or similar (depending on distribution)
See connection instructions: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html
If you want to add a new user the recommended way is to generate and add a new SSH key for the new user, but not specify a password (which would be useless anyway since password authentication is not enabled by default).
Managing additional users: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/managing-users.html
After all if you want to enable password authentication, which lowers down the security and is not recommended, but still you might need to do that for your own specific reasons, then just edit
/etc/ssh/sshd_config
For example:
sudo vim /etc/ssh/sshd_config
find the line that says:
PasswordAuthentication no
and change it to
PasswordAuthentication yes
Then restart the instance
sudo reboot
After restarting, you are free to create additional users with password authentication.
sudo useradd newuser
sudo passwd newuser
Add the new user to the sudoers list:
sudo usermod -a -G sudo newuser
Make sure user home folder exists and is owned by the user
sudo mkdir /home/newuser
sudo chown newuser:newuser /home/newuser
New you are ready to try and login with newuser via ssh.
Authentication with ssh keys will continue to work in parallel with password authentication.