SSH Authorized Keys (probably permissions)

[valkyre14]

I’m pretty sure this started happening after I ran fixhome

When the main quickbox user tries to ssh authenticating with public key, they are still prompted with password.

This does not happen for other users.

I have removed the .ssh directory entirely, running ssh-copy-id on the client side to recreate the folders & files needed.

I found the following guide already on the forum:

Ssh key integration for your server

This was made by @JMSolo Generate keys Linux (on your server) Use the ssh-keygen utility to create your key. For a 2048 bit RSA key do: ssh-keygen -t rsa For increased security you can make an even larger key with the -b option. For example, for 4096 bits do: ssh-keygen -t rsa -b 4096 We recommend using RSA over DSA because DSA keys are required to be only 1024 bits. When prompted, you can press Enter to use the default location ~/.ssh/id_rsa if you don’t already have a key installe…

I adapted the line:
mkdir -p /root/.ssh && chmod 700 /root/.ssh && cd ~/.ssh
to suit the /home/user location.

I still cannot get the damn key to accept.
ssh-v just gives the output:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/chronos/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/chronos/user/.ssh/id_dsa
debug1: Trying private key: /home/chronos/user/.ssh/id_ecdsa
debug1: Trying private key: /home/chronos/user/.ssh/id_ed25519
debug1: Next authentication method: password

I’ve tried multiple computers and generated differnet rsa keys to rule that stuff out.
If I install the keys on another user, they’re fine. It’s just this one user.

at the moment, the .ssh folder permissions are:
-rw------- 1 user user 399 Oct 13 03:50 authorized_keys

The keys file is:
-rw------- 1 user user 399 Oct 13 03:50 authorized_keys

Have any of you seen this before?

[RXWatcher]

I use: chmod 700 .ssh; chmod 640 .ssh/authorized_keys

[JMSolo]

I am not entirely certain that the key will be recognized in a subfolder of the user. The auth key mapping is pretty specific in most scenarios I have encountered.

The key could go in /home/chronos/.ssh/authorized_keys but I am not entirely sure it will pick it up in /home/chronos/user/.ssh/authorized_keys.

Additionally, the private key is what you connect with from your local and/or remote computer connecting to the server… thus, the public match should be added to an authorized_keys file in the .ssh directory.

I have always gave 600 permissions to the authorized_keys file

####Post Script
Another thing I am guilty of doing is placing user specific keys in the users /home/username/.ssh directory and then trying to connect with said user but by typing ssh [email protected] - Just throwing that out there.

[valkyre14]

Apologies for the confusion, I was doing the testing from my chromebook - they’re a little strange with /home directories, but for this exercise /home/chronos/user is basically ~/

I’ve definitely got the correct keys , because repeating the same steps with a different issue, the problem does not appear.

Thanks RXWatcher for the chmods, I’ve changed the permissions to match yours, the problem is still there.

I genuinely have no idea what I’ve done.

This account is the master quickbox user. Is it possible to create a new user, the build is only a day old so other than the media files (which I could offload to /media temporarily), there isn’t much on the user.

If it’s a ball ache, I might just have to put up with typing my password

[JMSolo]

Do you have multiple _rsa in the directory on your chromebook? I assume it would work the same way as how the linux subsystem works on Windows 10 (which is what I use)

[valkyre14]

no, just one generated purely for this test.

The only reason I’m using it is because the problem started happening when I was on my mac & wanted to rule out something on the local machine.

It’s 4am where I’m from, I should probably get some sleep

Who knows, when I wake up maybe I’ll remember what I did

[JMSolo]

Alright, when you’re done with your let’s pick this back up, I’d like to help you figure it out… I just ran several tests and can’t hit any issues… but my RL job requires me to generate keys everyday.

[RXWatcher]

have you looked at the actual /var/log/auth.log to see what it says there for the reason its not using the keys?

I wonder if its an issue with the /etc/ssh/sshd_conf file or something. I ran into an issue the other day where a customer changed the ciphers on me in there. ‘We disabled the old ciphers…bad practice to leave them’…when my program uses an ancient ssh client not compatible with modern ciphers…umm…yeah, you do…All of a sudden 400 users are locked out of my app…hmmm…put it back the way it was.

[JMSolo]

Yeah, I am going through all the settings now. So far there are 0% in the way of clues and even with a proper key file and permissions, his server is rejecting it and requesting a user password. It’s an oddity I haven’t encountered.

[RXWatcher]

This seems like a white box setup as he’s running multiple? Screw it…wipe the box and start over. I’d want it fixed and that might be the fastest way.

[JMSolo]

Well, I finally got a clue…

Authentication refused: bad ownership or modes for directory /home/USERNAME

There we go… all he needed was chmod g-w /home/USERNAME - we’re done here.

[RXWatcher]

I wonder why it was set like that…odd.

[JMSolo]

I was wondering the same thing. I noticed it was 770. Perms inside the directory were great… I didn’t even think to one up my level.

Probably something to do with following one of my confusing tutorials…