SOLVED [SCALE] Cannot SSH with keys at all.

[The_Panda_Trueno]

EDIT: My bad, I sent this into the wrong category by accident.

Okay so, I was really about to break my laptop over this since I've been trying this for over 5 hours and am out of patience, so sorry if anything sounds a bit condescending:

I can't SSH at all into ANY of my servers with keys only. The goal here is to have key-only authentication for SSH because I need to open SSH publicly via a domain.
Also don't lecture me on how insecure it is to do that. I do not care.

This is what I did so far:

Went into Termius, and generated a key. So far, no issues.
I saw a post somewhere saying that since TrueNAS 13, RSA is deprecated. Since I use SCALE, I didn't know if it applied so I tried both RSA and ED25519:

So far everything is fine.

I input everything I need (username etc.) and connect selecting the key.
(Note: IP isn't public, no need to blur)

But then I get this no matter what I do on either the client side or server side:

I get this from multiple clients, from multiple devices.

I then tried to verify that the file within .ssh did exist, and it did.

I also chown'd to the appropriate user (miu-admin) and chmod 600'd the file. I also tried 777, but it didn't work either and ain't the best thing to do anyway.
Stangely, as you might have seen in one of the screenshots, it says ''Username/PublicKey combination invalid''. I do not understand since I did specify to Termius to use the correct user to which the key is binded to.
Doing so on Windows' terminal with ''ssh miu-admin@100.64.16.50'' yields the same result.

What am I supposed to do ?

 

[unseen]

Is the directory ".ssh" (and the associated public key in authorized_keys) in the home directory of the user mui-admin on the TrueNAS server?
Is the private key of your key pair either loaded in an ssh agent or present in the .ssh directory of the user initiating the connection?

Also, if the IP address 100.64.16.50 is not public then it should be allocated from one of the RFC 1918 non-routable address ranges:

• 10.0.0.0/8 ( Range: 10.0.0.0 – 10.255.255.255 ) – Available IPs: 16,777,214
• 172.16.0.0/12 ( Range: 172.16.0.0 – 172.31.255.255 ) – Available IPs: 1,048,574
• 192.168.0.0/16 ( Range: 192.168.0.0 – 192.168.255.255 ) – Available IPs: 65,534

Using a public IP address for an internal system is exceptionally bad practice.

 

[The_Panda_Trueno]

Is the directory ".ssh" (and the associated public key in authorized_keys) in the home directory of the user mui-admin on the TrueNAS server?
Is the private key of your key pair either loaded in an ssh agent or present in the .ssh directory of the user initiating the connection?

Also, if the IP address 100.64.16.50 is not public then it should be allocated from one of the RFC 1918 non-routable address ranges:

• 10.0.0.0/8 ( Range: 10.0.0.0 – 10.255.255.255 ) – Available IPs: 16,777,214
• 172.16.0.0/12 ( Range: 172.16.0.0 – 172.31.255.255 ) – Available IPs: 1,048,574
• 192.168.0.0/16 ( Range: 192.168.0.0 – 192.168.255.255 ) – Available IPs: 65,534

Using a public IP address for an internal system is exceptionally bad practice.

Yes, the .ssh folder is inside the user's home dir.
Yes, the private key was also pasted into the SSH agent.
Also the IP is from Tailscale, hence why it isn't public.
The server itself has a private IP in the 192.168.x.x range.

 

[unseen]

Are the permissions of the .ssh directory also correct? On the TrueNAS machine, they should be 700.

 

[The_Panda_Trueno]

Are the permissions of the .ssh directory also correct? On the TrueNAS machine, they should be 700.

I tried 600, 700, 755, 775 and 777.
Edit: also I had the -R flag

 

[unseen]

Then I'm out of ideas. As long as there's a public key entry in .ssh/authorized_keys which matches the private key of the client, the permissions on both the file and the directory are correct and the client has the private key loaded, it should just work.

 

[The_Panda_Trueno]

Then I'm out of ideas. As long as there's a public key entry in .ssh/authorized_keys which matches the private key of the client, the permissions on both the file and the directory are correct and the client has the private key loaded, it should just work.

I know, I just can't figure out what's going on either. My Foxtrot server which runs Archlinux has no issues with random generated keys and I've tried importing the exact same public key with the same settings and it just works. I don't know what is causing this not to work on TrueNAS.

 

[Patrick M. Hausen]

Does the user in question have a proper shell? What happens when as root on the TrueNAS you try su - <username>? What does ssh -v on the client show? I don't know what the SCALE equivalent to /var/log/auth.log on CORE is, but surely there is something logged on the NAS, too.

 

[The_Panda_Trueno]

Does the user in question have a proper shell? What happens when as root on the TrueNAS you try su - <username>? What does ssh -v on the client show? I don't know what the SCALE equivalent to /var/log/auth.log on CORE is, but surely there is something logged on the NAS, too.

When using password auth, the user does have a shell (bash)
I'll try finding the log later today after work.

 

[The_Panda_Trueno]

I found the issue.

For some reason, I can't login at all if any of those are ticked:

After unticking these and quickly restarting sshd with sudo systemctl restart sshd it worked right away.

I don't get why this alone would prevent me from logging in with a key, but now it works so whatever.
Adjusting the perms manually with chmod does not work at all with this. You must untick those.

Marking as solved. Still a very frustrated that I lost about 6 - 7 hours on this over some boxes ngl.

 

[Arwen]

It is standard security practice for SSH to restrict writing new SSH keys, (or SSH user config options), unless you are the owner.

If the home directory or SSH sub-directory are writable by group or other, then anyone could install their SSH public key. This would allow anyone, (who can log into the server as themselves), to pretend to be you. SSH dis-allows logins with keys in an un-secure home directory.