Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
In ~/.ssh, I see the following, and have listed my understanding.
id_rsa. My private key. Has the ability to decrypte anything encrypted by my public key. I can set it up with a passkey should I desire
id_rsa.pub. My public key.
known_hosts. Hosts that I have connected to. The first time I do, I will be asked to verify the ECDSA key fingerprint, and after that, I will not normally connect if something has been changed.
authorized_keys. Okay, this is where I need some help.
I have a user called "michael" on three machines called machine1.com and machine2 (no .com) and machine2 (no .com). My desire is to be able to ssh from machine1 to machine2 or machine3 without a password, and to be able to ssh into machine1 from machine2 or machine3 without a password.
On machine1, /home/michael/.ssh/id_rsa.pub is: ssh-rsa AAAAB3NzaC1yc2EAAAADA....xUt713oiYNeWBasdfz michael@machine1.com
On machine2, /home/michael/.ssh/id_rsa.pub is: ssh-rsa AAAAB3NzaC1yc2EAAAAD.....Ca4xZMslrKoMQF4jJJ michael@machine2
On machine3, /home/michael/.ssh/id_rsa.pub is: ssh-rsa AAAAB3NzaC1yc2EAAAAD.....asfasdfKJHf7Khf7kG michael@machine3
So, I just opened up a putty session to the various machines and used vi to cut and paste the public key of machine2 and machine3 into machine1's authorized_keys (with a cr between the two), cut and pasted machine1's public key into machine2's and machine3's authorized_keys. I didn't use ssh-copy-id or anything fancy.
So, then I tried to ssh into one from the other, but I am being asked to provide a password. Why?
It looks close, but I'd start fresh and work through the steps one by one again. It will help if you use at least the -f option with ssh-keygen when you generate the keys.
Then copy the private key for machine1 (machine1_rsa) over to ~/.ssh/ on machine2 and machine3. Likewise with the other two keys, but with different destinations. The private keys for a machine go on the machines you are connecting from and the the public keys for a machine go on the machine you are connecting to, specifically in ~/.ssh/authorized_keys
So then put the public keys onto the appropriate destination machines in ~/.ssh/authorized_keys. You can get them there any way you want but ssh-copy-id is the easiest to spell out:
Be sure to see the manual page for ssh-copy-id before you try it.
Lastly, PuTTY has a weird key format. You may have to read about what is needed to adapt it to using regular SSH keys. Instead, one you have the above in place, can you connect with the regular SSH client first?
I just (re-)edited the above to sort the machine names out in regards to the public keys. The premise is that you have only one key pair per target machine, that gives three key pairs, not one key pair per source-destination pairing, which would give six key pairs.
Last edited by Turbocapitalist; 08-07-2017 at 10:03 PM.
machine1 is a 1&1 Centos7 virtual server. machine2 and machine3 are local Raspberry Pis.
I can ssh without a password from machine1 to either machine2 or machine3, and can ssh without a password from machine2 to machine3 and machine3 to machine2.
I cannot ssh without a password from either machine2 or machine3 to machine1.
I also tried creating a new user on machine1, and copied that users to michael@machine1. I also am prompted for a password when using ssh.
Can the Centos7 box be set up such to prevent user michael to ssh using just keys and not a password?
I called 1&1 and they said that there is nothing special which they know of which they are doing.
I rebooted machine1, and now I can no longer ssh from machine1 without a password to the new machines. Can it be caused by having the same username on the three machines?
Last edited by NotionCommotion; 08-08-2017 at 09:12 AM.
I cannot ssh without a password from either machine2 or machine3 to machine1.
On the CentOS 7 machine at 1&1, check what you have in the SSH server's configuration file. You can peruse it at /etc/ssh/sshd_config
Code:
less /etc/ssh/sshd_config
Alternately, if you know the ip numbers you are connecting from and to, you can use the -T option to see what specific settings are inflicted on your account:
Code:
sudo /usr/sbin/sshd -TC user=michael,host=server.oneandone.com,addr=192.0.2.11 \
| sort | less
Substitute the "host" address for the machine you are connecting to. Substitute the "addr" address for the machine you are connecting from.
In the output you'll probably see that a lot of very insecure ciphers are still used. However, what you are looking for is the "pubkeyauthentication" directive, and that should be set to "yes" Then check the permissions on the private keys you are using to try to connect to machine1. They should be in directories not writable by any other account except your own. Same goes for the keys themselves.
On which machine did you create the keys? As posted by Turbocapitalist did you copy machine 1's public key to its authorized_keys file and the private key to both machine 2 and 3? Are the permissions set correctly for the files?
This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.
~/.ssh/authorized_keys
Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.
~/.ssh/config
This is the per-user configuration file. The file format and configuration options are described in ssh_config(5). Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others.
~/.ssh/environment
Contains additional definitions for environment variables; see ENVIRONMENT, above.
Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute).ssh will simply ignore a private key file if it is accessible by others. It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using 3DES.
It looks like the manual page missed some changes. I'm pretty sure 3DES was retired a while back and that AES is used for the private keys: http://www.openssh.com/txt/release-5.4
Go for it:
Code:
Index: ssh.1
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh.1,v
retrieving revision 1.376
diff -u -p -r1.376 ssh.1
--- ssh.1 16 Jul 2016 06:57:55 -0000 1.376
+++ ssh.1 8 Aug 2017 16:34:13 -0000
@@ -1503,7 +1503,7 @@ accessible by others (read/write/execute
will simply ignore a private key file if it is accessible by others.
It is possible to specify a passphrase when
generating the key which will be used to encrypt the
-sensitive part of this file using 3DES.
+sensitive part of this file using AES-128.
.Pp
.It Pa ~/.ssh/identity.pub
.It Pa ~/.ssh/id_dsa.pub
Yes, permissions were fine. I read on another post that ~ needed 700 and not just ~/.ssh and ~/.ssh/authorized_keys, but don't think this is the case.
700 is not needed on ~, but it can't be wide open either (change it to 777 and you'll see that ssh will stop trusting your authorized_keys file). I typically use 750.
It is critical that the permissions to the .ssh directory be 700 = rwx------. If they're not, sshd won't consider it.
You should also configure sshd so that it does not offer "passwords" as an alternative. A key should not be "an alternative to" a password; it should be the one-and-only thing that works. Either you possess a key, or you don't. Period.
Then, shove the whole thing behind an OpenVPN tunnel with tls-auth so that you can only reach sshd through that tunnel. When you do this, the fact that it is possible to connect to the machine, by any(!) means, becomes invisible to the public. The only means of access is through an undetectable hidden door that only those who possess a pair(!) of non-revoked one-of-a-kind digital keys may find, much less enter. (Now, to make it all the way through both layers of security, you must possess three one-of-a-kind credentials. And if you've got all three, access is quick and easy.)
"Number of unauthorized access attempts: Zero."
Last edited by sundialsvcs; 08-10-2017 at 08:31 AM.
700 is not needed on ~, but it can't be wide open either (change it to 777 and you'll see that ssh will stop trusting your authorized_keys file). I typically use 750.
It is, indeed, not the case that your home-directory must be secured, although I would add that it is a very good idea!
Only the ~/.ssh has permission requirements.
However, on all of my systems, each user's home directory is their own private play-pen that no one else can peek into. I learned that habit from administering University systems, long ago. Other users don't need to be able to eavesdrop into what other users are doing.
It is, indeed, not the case that your home-directory must be secured
That is incorrect. All it takes is a 5 second test to see for yourself. Chmod your home directory to 777 and you'll see that you can no longer SSH into that system using keys. I'm not just making things up here, I've seen it happen on real systems with actual users, and I also just tested it on my own system to re-confirm.
Last edited by suicidaleggroll; 08-10-2017 at 10:04 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.