[SOLVED] Trouble with openSSH authentication with id_rsa

mfoley · 12-12-2018, 01:35 AM

I have a Linux Slackware64 14.2 host with two users who authenticate to their Mac workstations via ssh. I've done the ssh-keygen and ssh-copy-id from the Linux system to the Mac systems for both users. User 'brian' can ssh to his Mac workstation from Linux without problem. User 'mike' cannot. He is prompted for a password. I'm having trouble figuring out the problem. I've run 'ssh -v' as each user. Below are the initial difference between them:

Code:

< debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
< debug1: match: OpenSSH_7.6 pat OpenSSH* compat 0x04000000
< debug1: Authenticating to mac1:22 as 'mike'
---
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
> debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to mac2:22 as 'brian'

< debug1: Offering RSA public key: /home/HPRS/mike/.ssh/id_rsa
< debug1: Authentications that can continue: publickey,password,keyboard-interactive
< debug1: Trying private key: /home/HPRS/mike/.ssh/id_dsa
< debug1: Trying private key: /home/HPRS/mike/.ssh/id_ecdsa
< debug1: Trying private key: /home/HPRS/mike/.ssh/id_ed25519
< debug1: Next authentication method: keyboard-interactive
---
> debug1: Offering RSA public key: /home/HPRS/brian/.ssh/id_rsa
> debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
> debug1: Authentication succeeded (publickey).
> Authenticated to mac2 ([192.168.0.54]:22).

The first thing I notice is that mike's host has openSSH version 7.6 and brian's is openSSH version 7.8. A clue?

mike's has the line "Authentications that can continue", whereas brian's does not have that line.

mike's tries private keys: id_dsa, id_ecdsa and id_ed25519. None of these files exist in /home/HPRS/mike/.ssh; only id_rsa and id_rsa.pub. These attempts fail and it goes to the "keyboard-interactive" method, which prompts for the password.

brian's goes immediately from the "Offering RSA public key" to "Server accepts key."

So, something is obviously different, but I don't know what. I've done exactly the same thing to generate the keys on the Linux host:

ssh-keygen (no passphrase, default location)
ssh-copy-id user@workstation

I deleted mike's .ssh directory on the Linux host and his workstation several times and recreated the keys.

How do I fix this?

MensaWater · 12-12-2018, 08:59 AM

The public key from the source user/host has to be in the target user/host's authorized_keys file.

Assuming that is OK for Mike then the next thing to check would be permissions of the files and directories up to and including $HOME/mike/.ssh/* on the source and on the host. Compare those to what you see for $HOME/brian/.ssh.

ssh is very picky about permissions and won't allow "secure" connections if they are wrong as it deems it to be "insecure".

mfoley · 12-12-2018, 04:23 PM

Yup! That was the problem. Permissions on the home directories were:

Code:

# Mike's permissions
drwxrwxr-x  28 mike  10000  896 Dec 12 01:24 /Users/mike

# Brian's permissions
drwxr-xr-x+ 26 brian  HPRS\Domain Users  884 Dec 11 07:44 /Users/brian

When I changed mike's to 'chmod g-w /Users/mike', the ssh from Linux to Mac started working. Sheesh! Thanks a million for that simple solution.

scasey · 12-12-2018, 04:44 PM

Quote:

Originally Posted by mfoley

Yup! That was the problem. Permissions on the home directories were:

Code:

# Mike's permissions
drwxrwxr-x  28 mike  10000  896 Dec 12 01:24 /Users/mike

# Brian's permissions
drwxr-xr-x+ 26 brian  HPRS\Domain Users  884 Dec 11 07:44 /Users/brian

When I changed mike's to 'chmod g-w /Users/mike', the ssh from Linux to Mac started working. Sheesh! Thanks a million for that simple solution.

I'm surprised that did it...the home directory on my server has group write permies and ssh works just fine.

What MensaWater suggested was that you check the permissions on /Users/mike/.ssh.
ssh requires that directory be only writable by the user.

Code:

ls -la /home/scasey/.ssh
total 12
drwx------.  2 scasey root   24 Feb 23  2004 .  #the .ssh directory
drwxrwx---. 21 scasey root 4096 Dec  9 03:00 .. #the user's home directory
-rw-r--r--.  1 scasey root  238 Feb 23  2004 known_hosts

(Note that the home directory is not readable or viewable by "others"...not an issue with ssh, afaik, but certainly makes things a bit tighter otherwise.)

mfoley · 12-12-2018, 10:00 PM

Yes, I'm surprised too, especially since the 'ssh -v' output said nothing about permissions. Yet, changing the home directory to g-w worked. No computers were rebooted. Hey, it's a Mac! Maybe it works a bit differently.

scasey · 12-12-2018, 11:08 PM

Quote:

Originally Posted by mfoley

Yes, I'm surprised too, especially since the 'ssh -v' output said nothing about permissions. Yet, changing the home directory to g-w worked. No computers were rebooted. Hey, it's a Mac! Maybe it works a bit differently.

??? Aren't we talking about the permissions on the Linux box?
Aren't the Macs the clients?
The Linux host wouldn't care about what OS the client is running, I wouldn't think.

MensaWater · 12-13-2018, 12:35 PM

Quote:

Originally Posted by scasey

I'm surprised that did it...the home directory on my server has group write permies and ssh works just fine.

I'm surprised at your surprise.

I've often found permission on the $HOME rather than just $HOME/.ssh to be the issue. If any of (or all of) /, /home /home/mike and /home/mike/.ssh is 777 then it isn't considered a secure connection. This is because other people on the system can modify what is in /home/mike including .ssh. That is to say if you can write anything you want to root you can write anything you want to any subdirectory thereof regardless of the permissions of such subdirectories.

That is to say open permissions in the hierarchy can override restrictive permissions later. If however the hierarchy permissions are restrictive then the permissions later can override them.
So root can be set to allow access (r-x) to everyone (note x here doesn't mean execute as it does on files):
dr-xr-xr-x. 35 root root 4096 Apr 23 2018 /
And /home can be set to allow writes within it by root and other access by everyone else:
drwxr-xr-x. 22 root root 4096 Oct 25 15:01 /home
But the subdirectories of /home (user $HOME directories) determine final access:
drwxr-xr-x 4 billybob users 4096 Nov 23 2016 billybob
drwxr-xr-x 4 autossh autossh 4096 Jun 23 2016 autossh
drwx------ 4 susieq users 4096 Jan 17 2017 susieq

Since / being 777 causes other things to break it is almost never the issue with ssh in my experience. On very rare occasion /home (if that is where the home directories are as usual) has been 777 would be the issue. Ideally no one sets /home to that because it means all users under /home have access to each others home directories.

In my experience it is almost always $HOME (e.g. /home/mike) or $HOME/.ssh permissions that are the issue in my experience. On occasion it is specific files in $HOME/.ssh (no one needs access to authorized_keys file except the owner).

P.S. Blithely leaving ACLs out of this discussion.

MensaWater · 12-13-2018, 12:38 PM

Quote:

Originally Posted by scasey

??? Aren't we talking about the permissions on the Linux box?
Aren't the Macs the clients?
The Linux host wouldn't care about what OS the client is running, I wouldn't think.

MacOS is actually built on a UNIX kernel and as such has the same mode (permissions) setup on files and directories as any other UNIX/Linux would. You can go to command prompt on Mac and find many of the commands you're used to from UNIX/Linux are available there. My neighbor is often mystified when I do that on her Macbook while troubleshooting issues for her as all she knows is the GUI.