Passwordless SSH login


81 posts in this topic Last Reply

Recommended Posts

On 3/8/2021 at 1:24 PM, ljm42 said:

Have you had a chance to check out the 6.9.0 release notes?
  https://wiki.unraid.net/Unraid_OS_6.9.0#SSH_Improvements 

 

It can't (yet?) be configured via the webgui, but you can simply drop your authorized_keys files into config/ssh/root on the flash drive and it will be activated the next time you reboot.

 

There is no longer any need to tweak your go script to copy files to /root/.ssh 

 

So this is no longer needed in go?

# Enable certificate based SSH login
mkdir /root/.ssh/
cp /boot/config/ssh/authorized_keys /root/.ssh/authorized_keys
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

 

 

And since authorized_keys is already in /boot/config/ssh/ (that's where it's being cp'd from) I just need to delete the entry from my go file and everything should be good?

Link to post
  • Replies 80
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

A slightly better way to maintain the keys across reboots is to * copy the authorized_keys file to /boot/config/ssh/root.pubkeys * copy /etc/ssh/sshd_config to /boot/config/ssh * modify

1) If necessary, generate an SSH key on your Mac or Linux machines, using ssh-keygen.   2) Create an authorized_keys file for the unRAID server, using the id_rsa.pub files on all the machines which

1. On Linux or Mac, use ssh-keygen to generate a key pair, there'll be 2 files generated, a private key file (e.g. id_rsa) and a public key file (e.g. id_rsa.pub);   2. On your unRAID server, enter

Posted Images

Everything in /boot/config/ssh/root is now accessible as /root/.ssh so just keep the authorized_keys file in /boot/config/ssh/root and no need to manually copy them over or set permissions

 

  • Like 2
  • Thanks 1
Link to post
2 minutes ago, wgstarks said:

So this is no longer needed in go?


# Enable certificate based SSH login
mkdir /root/.ssh/
cp /boot/config/ssh/authorized_keys /root/.ssh/authorized_keys
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

 

yep, toss it. In Unraid 6.9.0+ there is a symlink that points /root/.ssh to /boot/config/ssh/root/, so no need to copy files around:

 

root@Tower:~# ls -al /root/.ssh
lrwxrwxrwx 1 root root 21 Mar  8 14:59 /root/.ssh -> /boot/config/ssh/root/

 

 

 

2 minutes ago, wgstarks said:

And since authorized_keys is already in /boot/config/ssh/ (that's where it's being cp'd from) I just need to delete the entry from my go file and everything should be good?

 

close, put authorized_keys in /boot/config/ssh/root/

Link to post

After trying for a while to get the certificate working I checked my ssh settings and realized nothing is configured. Help isn’t available for the ssh plugin so I’m not sure what settings to use here. I rarely use ssh but wanted to set it up for use if/when the webUI is not available.

 

Should I enable ssh for configured users?

 

Should I allow root login?

 

I’m sure require passwords should be “yes” and allow empty passwords should be “no” but could use some advice for the rest of the settings.

Link to post

well there's currently some code in /etc/profile that actually prevents non-normal users from getting via ssh (rather you can't spawn a login shell without encountering issues) so I think a review of the multi user stand of unraid vs your needs is in order. (I'm not advocating either way, just that there shouldn't be changes that break standard functionality)

 

Link to post
1 minute ago, ken-ji said:

well there's currently some code in /etc/profile that actually prevents non-normal users from getting via ssh (rather you can't spawn a login shell without encountering issues) so I think a review of the multi user stand of unraid vs your needs is in order. (I'm not advocating either way, just that there shouldn't be changes that break standard functionality)

 

I actually don't really care much about allowing users or not just not sure if I should enable my user or enable root?

Link to post
13 minutes ago, ken-ji said:

Well as it stands, you should enable root as that's the supported unraid way.

Ok, I think I understand (maybe😁). You're saying that setting a configured user doesn't work in 6.9 right? I'll set it to root.

Thanks for the help.

Link to post

One more question.😁

/boot/config/ssh/ contains quite a few key pairs.

FinderScreenSnapz002.jpg.e83a7498c92c26a37e68ab37b43d5bad.jpg

 

Are these still used in 6.9 or just leftovers from previous versions?

Wondering if they should be deleted?

Link to post

Don't touch those as they are the SSh host keys (deleting them will regenerate them on sshd restart)

If they are regenerated, you'll get warning about Man In The Middle attacks (ssh will consider your Unraid host as never before seen)

 

Link to post
Just now, ken-ji said:

Don't touch those as they are the SSh host keys (deleting them will regenerate them on sshd restart)

If they are regenerated, you'll get warning about Man In The Middle attacks (ssh will consider your Unraid host as never before seen)

 

Thanks again

Link to post
13 hours ago, ken-ji said:

Don't touch those as they are the SSh host keys (deleting them will regenerate them on sshd restart)

If they are regenerated, you'll get warning about Man In The Middle attacks (ssh will consider your Unraid host as never before seen)

 

I understand about not deleting them but shouldn't they be moved into the /boot/config/ssh/root directory, which is where /root/.ssh is symlinked? I can't see how they can even by accessed in their current location. I'm thinking they're left over from an earlier method of preserving keys across a reboot, where they were copied into the /root/.ssh directory by a line in the go file.

 

Link to post

No these are host keys - what the server uses to identify itself to the user - and all the files in /boot/config/ssh will be installed into /etc/ssh upon startup of the ssh server.

If the ssh server starts up and cannot find these host keys, it will generate new ones and scare anybody trying to ssh in with a warning message about possible Man in the Middle Attacks due to host key mismatch. Needless to say, the new ones will be saved to /boot/config/ssh as well.

For those who use the ssh plugin or know what they are doing, the configuration of the ssh service can be changed and persisted by copying the modified /etc/ssh/sshd_config file here.

Link to post

If you think the config/ssh folder is full of cruft you can delete the files and reboot, just know that the next time you connect via SSH you'll be told that the keys changed. Not a big deal if you are the only user, might be more of a concern if for some reason you have multiple users.

Link to post
  • 1 month later...

Running into an issue on 6.9.2 and the changes for authorized_keys. I have nothing in my go file (anymore) that will modify the authorized keys or ssh folders. Everytime I reboot, the authorized_keys file in /boot/config/ssh/root reverts to Jun 30 2020. I've confirmed that it's symlinked as /root/.ssh to that /boot.... folder above. After I've made the changes, I've also confirmed that the file inside /boot.... updated. Just doesn't persist through reboot. Any ideas?

Link to post

Are you absolutely sure you do not have anything in your system? user scripts plugin? cron jobs? and if you delete/rename /boot/config/ssh/root folder and reboot? does it come back?

Link to post
7 hours ago, ken-ji said:

Are you absolutely sure you do not have anything in your system? user scripts plugin? cron jobs? and if you delete/rename /boot/config/ssh/root folder and reboot? does it come back?

Just confirmed crontab is only running the default things that kick off from the webgui and userscripts.

 

My only user scripts that run right now are all unrelated to anything ssh. One is a file mover between two explicit folders (not ssh folders), one creates a ramdisk folder for tdarr, and one pauses parity until overnight if the server reboots during the day.

 

Deleted and it came back with the same date of Jun 30. It's like the folder isn't persistent at all? 

Link to post

Odd. Can you post a screenshot (or text copy) of what you are seeing now?

particularly running

root@MediaStore:~# ls -al /root/.ssh /boot/config/ssh /boot/config/ssh/root
lrwxrwxrwx 1 root root   21 Apr  8 02:48 /root/.ssh -> /boot/config/ssh/root/

/boot/config/ssh:
total 120
drwx------  3 root root 8192 Mar 22 18:44 ./
drwx------ 11 root root 8192 Apr 27 21:07 ../
drwx------  2 root root 8192 Apr 19 22:47 root/
-rw-------  1 root root  668 May  3  2019 ssh_host_dsa_key
-rw-------  1 root root  605 May  3  2019 ssh_host_dsa_key.pub
-rw-------  1 root root  227 May  3  2019 ssh_host_ecdsa_key
-rw-------  1 root root  177 May  3  2019 ssh_host_ecdsa_key.pub
-rw-------  1 root root  411 May  3  2019 ssh_host_ed25519_key
-rw-------  1 root root   97 May  3  2019 ssh_host_ed25519_key.pub
-rw-------  1 root root  980 May  3  2019 ssh_host_key
-rw-------  1 root root  645 May  3  2019 ssh_host_key.pub
-rw-------  1 root root 1679 May  3  2019 ssh_host_rsa_key
-rw-------  1 root root  397 May  3  2019 ssh_host_rsa_key.pub
-rw-------  1 root root 1773 Aug 12  2020 ssh_known_hosts
-rw-------  1 root root 3312 Mar 22 18:47 sshd_config

/boot/config/ssh/root:
total 48
drwx------ 2 root root 8192 Apr 19 22:47 ./
drwx------ 3 root root 8192 Mar 22 18:44 ../
-rw------- 1 root root  418 Mar  9 08:19 authorized_keys
-rw------- 1 root root  883 Mar  9 08:19 id_rsa
-rw------- 1 root root  209 Apr 19 22:47 id_rsa.pub
-rw------- 1 root root 3473 Apr 19 22:45 known_hosts

 

Link to post

root@FC-PS-URD1:/boot/config/ssh/root# ls -al /root/.ssh /boot/config/ssh /boot/config/ssh/root
lrwxrwxrwx 1 root root    21 Apr  7 13:48 /root/.ssh -> /boot/config/ssh/root/

/boot/config/ssh:
total 192
drwx------  3 root root 16384 Jul 26  2020 ./
drwx------ 12 root root 16384 Apr 27 08:24 ../
drwx------  2 root root 16384 Apr 27 08:54 root/
-rw-------  1 root root  1381 May  2  2020 ssh_host_dsa_key
-rw-------  1 root root   605 May  2  2020 ssh_host_dsa_key.pub
-rw-------  1 root root   505 May  2  2020 ssh_host_ecdsa_key
-rw-------  1 root root   177 May  2  2020 ssh_host_ecdsa_key.pub
-rw-------  1 root root   411 May  2  2020 ssh_host_ed25519_key
-rw-------  1 root root    97 May  2  2020 ssh_host_ed25519_key.pub
-rw-------  1 root root  2602 May  2  2020 ssh_host_rsa_key
-rw-------  1 root root   569 May  2  2020 ssh_host_rsa_key.pub
-rw-------  1 root root  3245 Apr 27 08:24 sshd_config

/boot/config/ssh/root:
total 128
drwx------ 2 root root 16384 Apr 27 08:54 ./
drwx------ 3 root root 16384 Jul 26  2020 ../
-rw------- 1 root root  2602 Jun 30  2020 authorized_keys
-rw------- 1 root root    86 Apr 23 00:37 config
-rw------- 1 root root  1823 Feb  9 20:58 id_rsa
-rw------- 1 root root   535 Apr 23 00:37 known_hosts
-rw------- 1 root root   387 Apr 23 00:37 unraidbackup_id_ed25519
-rw------- 1 root root    82 Apr 23 00:37 unraidbackup_id_ed25519.pub

 

Link to post

@ken-ji @ljm42 I have a similar issue.  Passwordless SSH logins between servers is broken for me which means my backup script fails to run properly.  The problem is that rsync will not run between servers without always prompting for a password.

 

I run a User Script that was working flawlessly for over three years until the 6.9.x upgrades.  Now it does not work.

 

The script powers on the backupnas server via IPMI and the runs a series of rsync commands to sync shares from the source server (medianas) to the backup server (backupnas).

 

Here is what was in my medianas 'go' file related to SSH file prior to 6.9.x.  It is still there, just commented out.

 

# Copy SSH files back to /root/.ssh folder and set permissions for files
mkdir -p /root/.ssh
# cp /boot/config/ssh/medianas_key /root/.ssh/id_rsa
# cp /boot/config/ssh/known_hosts /root/.ssh/known_hosts
# cat /boot/config/ssh/backupnas_key.pub > /root/.ssh/authorized_keys
# chmod g-rwx,o-rwx -R /root/.ssh

 

I have changed the password on medianas but I also have generated new _key and .pub files for both servers.

 

I ran the following on medianas:

# ssh-keygen -t rsa -b 2048 -f /boot/config/ssh/medianas_key
Generating public/private rsa key pair. 
Enter passphrase (empty for no passphrase): [press enter here] 
Enter same passphrase again: [press enter here]
# scp /boot/config/ssh/medianas_key.pub root@[IP address of backupnas]:/boot/config/ssh
cp /boot/config/ssh/medianas_key /boot/config/ssh/root/id_rsa
cat /boot/config/ssh/backupnas_key.pub > /boot/config/ssh/root/authorized_keys

 

I did the same on backupnas but with server names reversed.

 

I currently have the following newly-generated files in /boot/config/ssh/root on both servers:

  • authorized_keys
  • id_rsa
  • known_hosts

Here's a look at the pertinent directories from medianas:

 

image.png.a0bfb19059818928d7b4967d9786a170.png

 

When I run an rsync command from the script using a test directory (or anything else), it always prompts for a password, thus the script fails.

 

image.thumb.png.c868f01e7e16447d84803a9bef62152f.png

 

Not that it should matter as /root/.ssh is symlinked to /boot/config/ssh/root by I tried replacing the id_rsa path with /boot/config/ssh/root with the same result.

 

The problem is the same in either direction (medianas --> backupnas or backupnas --> medianas).  There is always a prompt to enter the passphrase for id_rsa even though the passphrase was supplied when each server key was generated and each known_hosts file has an entry for the other server.

 

What am I doing wrong?

 

Edited by Hoopster
Link to post
1 hour ago, Hoopster said:

What am I doing wrong?

Might not be the issue but one thing you should do is to check the syslog for any errors, some plugins change permissions on install and cause issues with key based SSH login, it happened to me recently, if that is the problem you'll see something like this:

 

Apr 20 18:27:30 Tower15 sshd[15259]: Authentication refused: bad ownership or modes for directory /

 

Link to post
2 hours ago, JorgeB said:

Might not be the issue but one thing you should do is to check the syslog for any errors,

Thanks for the suggestion. I do not see any similar sshd errors in the syslog.  I see other errors from a week ago but that was when I was doing some tests and had made a few ssh mistakes.

 

There is nothing recent in the syslog with respect to sshd.

Link to post
8 hours ago, Hoopster said:

The problem is the same in either direction (medianas --> backupnas or backupnas --> medianas).  There is always a prompt to enter the passphrase for id_rsa even though the passphrase was supplied when each server key was generated and each known_hosts file has an entry for the other server.

 

Hi! I think this is the issue. Normally when I do this I don't put a passphrase on the key. It's not the password of the server, it's a special passphrase to make your key more secure. If you want automation, redo your key generation and press enter when you get prompted for a passphrase.

You can also test with the verbose flags -v through -vvv in your ssh command to give you a little more feedback about what is failing. Try something like:
 

# ssh -vvv root@mytower.local 

 

That should sort this out.

Del

Edited by Delarius
Link to post
3 hours ago, Delarius said:

It's not the password of the server, it's a special passphrase to make your key more secure. If you want automation, redo your key generation and press enter when you get prompted for a passphrase.

I think you are correct.  I set this up over three years ago and forgot the passphrase should be [enter] for automation.

 

I will have time to test this later, but am fairly certain you have identified the problem.

 

UPDATE: Confirmed and fixed.  This was the problem, I had entered a passphrase when creating the keys instead of leaving them blank.  I confused that with the requirement that the root account have a password.

Edited by Hoopster
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.