Using ssh without a password

NotionCommotion · 08-07-2017, 09:06 PM

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?

Thank you

Turbocapitalist · 08-07-2017, 09:42 PM

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.

Code:

ssh-keygen -f machine1_rsa -t rsa -b 3072 

ssh-keygen -f machine2_rsa -t rsa -b 3072 

ssh-keygen -f machine3_rsa -t rsa -b 3072

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:

Code:

ssh-copy-id -n -i machine1_rsa michael@machine1

ssh-copy-id -n -i machine2_rsa michael@machine2

ssh-copy-id -n -i machine3_rsa michael@machine3

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?

So on machine1:

Code:

ssh -i ~/.ssh/machine2_rsa michael@machine2

ssh -i ~/.ssh/machine3_rsa michael@machine3

Turbocapitalist · 08-07-2017, 10:00 PM

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.

NotionCommotion · 08-08-2017, 08:39 AM

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?

Turbocapitalist · 08-08-2017, 08:55 AM

Quote:

Originally Posted by NotionCommotion

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.

michaelk · 08-08-2017, 09:15 AM

In addition you can create a ssh configuration file to make things a bit easier.
https://www.cyberciti.biz/faq/create...on-linux-unix/

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?

NotionCommotion · 08-08-2017, 10:12 AM

Thanks Turbocapitalist and michaelk.

I ended up getting this working.

Wasn't sure exactly to look for at /etc/ssh/sshd_config. Nothing, however, looked out of place. I didn't try your sshd suggestion.

I also found that ssh -v was helpful.

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.

I think the issue resulted from PuTTY when I did the following:
Windows PuTTY userX@machine1 -> su michael -> ssh michael@machine2

ntubski · 08-08-2017, 10:44 AM

Quote:

Originally Posted by NotionCommotion

I read on another post that ~ needed 700 and not just ~/.ssh and ~/.ssh/authorized_keys

That is not required. Even .ssh/authorized_keys is allowed to be world readable (don't make it world writable though!). Check your man page:

https://man.openbsd.org/ssh

Quote:

~/.ssh/

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.

~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519
~/.ssh/id_rsa

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.

~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub

Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone.

Turbocapitalist · 08-08-2017, 11:35 AM

Quote:

Originally Posted by ntubski

That is not required. Even .ssh/authorized_keys is allowed to be world readable (don't make it world writable though!). Check your man page:

https://man.openbsd.org/ssh

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

suicidaleggroll · 08-08-2017, 12:38 PM

Quote:

Originally Posted by NotionCommotion

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.

sundialsvcs · 08-09-2017, 08:28 AM

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."

businesscat · 08-10-2017, 02:49 AM

could you copy the messages of /var/log/messages & /var/log/secure? please

sounds like a permissions issue

sundialsvcs · 08-10-2017, 08:34 AM

Quote:

Originally Posted by suicidaleggroll

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.

suicidaleggroll · 08-10-2017, 10:01 AM

Quote:

Originally Posted by sundialsvcs

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.