SSH and Denyhosts updated for v6.1


Recommended Posts

12 hours ago, TDA said:

Just to clarify, this plugin wasn't tested with the latest RC right?
Cause it seems to not respond as it should.

If you set: PASSWORD AUTHENTICATION on "no" it doesn't change a thing.

No I have not tested with the latest RC yet. I need to double check that the plugin script does a full restart of SSH after the settings are changed. If not then it could explain what you are seeing. I'll check in a bit.

Link to comment
1 hour ago, docgyver said:

No I have not tested with the latest RC yet. I need to double check that the plugin script does a full restart of SSH after the settings are changed. If not then it could explain what you are seeing. I'll check in a bit.

Looks like I was overzealous in my "fix" to protect folks from turning off password authentication by accident. I am no longer able to turn it off either.

I also noticed I have 3 entries for PasswordAuthentication in sshd_config. I'm not sure if that is also a bug or a left over from something earlier, or, I suppose, both.

I'll work on a fix today. Thanks for letting me know.

Link to comment

New update fixes some issues bugs introduced with 2019-11-10 causing changes made in the UI to be ignored.

In addition, The part of the script which updates /etc/ssh/sshd_config (and then copies to /boot...) was updating block comment lines which happened to have Keywords in them which are maintained by the plugin.

In particular are the keywords "PermitRootLogin"and "PasswordAuthentication".

It is very likely you will now have 2 lines with PRL and 3 lines with the PA setting.

The plugin will update all of them to the value set in the UI and sshd_config will function correctly but you should consider fixing the sshd_config.

To do so you will need to manually edit the /etc/ssh/sshd_config file and then copy it to /boot/config/ssh/sshd_config. I know the whole point of the plugin is to avoid such steps and I apologize for the problem. [ lame excuses for why this happened removed by author ;) ]

 

Again, you don't have to do the cleanup but if you are inclined the steps are as follows:

  • ssh/telnet to unraid server as root
  • edit /etc/ssh/sshd_config with your favorite editor (e.g. vi /etc/ssh/sshd_config
  • look for a block of text which looks like:
    # Set this to 'yes' to enable PAM authentication, account processing,
    # and session processing. If this is enabled, PAM authentication will
    # be allowed through the ChallengeResponseAuthentication and
    PasswordAuthentication XXX
    # PAM authentication via ChallengeResponseAuthentication may bypass
    PermitRootLogin XXX
    # If you just want the PAM account and session checks to run without
    PasswordAuthentication XXX
  • Replace it with
    # Set this to 'yes' to enable PAM authentication, account processing,
    # and session processing. If this is enabled, PAM authentication will
    # be allowed through the ChallengeResponseAuthentication and
    # PasswordAuthentication. Depending on your PAM configuration,
    # PAM authentication via ChallengeResponseAuthentication may bypass
    # the setting of "PermitRootLogin without-password".
    # If you just want the PAM account and session checks to run without
    # PAM authentication, then enable this but set PasswordAuthentication
  • save the file
  • Copy to USB flash drive: cp /etc/ssh/sshd_config /boot/config/ssh/sshd_config

That's it. Going forward those lines will be appropriately ignored as will all block comment lines which contain impacted keywords.

 

doc..

 

Link to comment
21 hours ago, TDA said:

Just to clarify, this plugin wasn't tested with the latest RC right?
Cause it seems to not respond as it should.

If you set: PASSWORD AUTHENTICATION on "no" it doesn't change a thing.

There was a bug introduced with the prior version. (2019-11-10). It should be fine now with 2019-11-26 or later

Link to comment
14 hours ago, docgyver said:

There was a bug introduced with the prior version. (2019-11-10). It should be fine now with 2019-11-26 or later

Hello Docgyver,

I've followed your steps (commented the lines) & updated the plugin.
Now it's working as expected 🙂

Thumbs up !

Link to comment
2 hours ago, docgyver said:

Woot! Thanks for the feedback. Always nice to hear when it works. :)

 

I'm trying to find out how to configure the ssh key.

I've followed your readme:
 

Quote

 

Create file called "authorized_keys" in this directory and paste into it the contents of a public key from a keypair

To do this, you must have created a public and private key-pair.  Use the following steps to do this:

From command line (telnet / putty)

1. Type "ssh-keygen -t rsa -f /boot/config/plugins/ssh/<USERNAME>/.ssh/id_rsa"
   NB.  replace "<USERNAME>" with the name of the user.
   
2. When prompted, type a passphrase if you wish for additional security for the private key.  Press enter if not for no passphrase

3. Create a copy the public key into the same location and call it "authorized_keys".
   eg.  cp /boot/config/plugins/ssh/<USERNAME>/.ssh/id_rsa.pub /boot/config/plugins/ssh/<USERNAME>/.ssh/authorized_keys
   
Verify everything has been created correctly.

Upon restarting SSH, the plug-in will look for (and find) authorized_keys and copy this file to the users home directory.  eg.  /home/someuser/.ssh/authorized_keys

----------------------------------------------------------

The private part of the key is "id_rsa".  You must take this to the system you intend to connect *from*.  If you intend to use Putty to connect, then you *MUST* first convert the private key from standard OpenSSH format to Putty compatible format.

A copy of PUTTYGEN for UnRAID has been included.  To convert the private key, follow these steps:

From command line (telnet / putty):

1. Type "/usr/bin/puttygen /boot/config/plugins/ssh/<USERNAME>/.ssh/id_rsa -o /boot/config/plugins/ssh/<USERNAME>/.ssh/id_rsa.ppk
2. In Putty, create an entry to your UnRAID server and in "Connection -> SSH -> Auth" section of Putty, browse for the file you created (id_rsa.ppk).

 

But I'm encountering a problem because I receive following error:

- Server refused your key.

EDIT:
The key works, but only for the ROOT user.
How I can create / assign the key for the user.

Because I saw that under /home/<username>/.ssh there is nothing at all - so no copy of the authorized_keys

 

 

 

 

Edited by TDA
Link to comment
1 hour ago, TDA said:

I'm trying to find out how to configure the ssh key.

I've followed your readme:
 

But I'm encountering a problem because I receive following error:

- Server refused your key.

EDIT:
The key works, but only for the ROOT user.
How I can create / assign the key for the user.

Because I saw that under /home/<username>/.ssh there is nothing at all - so no copy of the authorized_keys

You can copy the same public key under multiple users on the unraid side. If you have already added the 2nd (non-root) user to the list in the ssh plugin then there should be a path /boot/config/plugins/ssh/<user>/.ssh with a readme.txt file in it. If not then add the user in the plugin UI and hit apply.

Once you have the path created you can copy the authorized_keys file from the /boot/.../root/.ssh folder to the parallel folder of the new user.

That gets it "persisted" on the USB drive. Now to get it into /home/<user> with the right owner and permissions you just need to force the plugin to refresh things.

Least impactful way is to go into the plugin UI and toggle a user and hit apply. A stop+start cycle or a reboot would also do the trick.

1 hour ago, TDA said:

 

 

 

 

Link to comment

So I've tried again and now it's working 🙂

I'll try to reboot to see if persists.


Just the last question, now I've done this for my second user and disabled the ROOT account.
Now, if I would re-enable the ROOT ACCOUNT, the PublicKey is already available for it?

Edited by TDA
Link to comment
  • 1 month later...

I've been directed to this plugin after i enquired about logging in as someone other than root via SSH. I'll check it out, though something as serious as SSH security should ideally be in the base product IMO. Frankly, i'm AMAZED that LimeTech haven't disabled password authentication by default, and forced people to use keys (and provided the GUI to do it). I thought that it was basically unheard of for people to use passwords with SSH these days.

 

A lot of people open up their unRAID to the world, and i bet many of them (most?) are just using SSH passwords. I know people are using LetsEncrypt (which has Fail2Ban) - but being in a Docker does that protect SSH connections to the unRAID host?

 

This plugin has existed for over three years. Please LimeTech - incorporate:

- SSH keys authentication by default (at least, if not stop passwords entirely).

- Fail2Ban baked into the OS.

 

  • Like 1
Link to comment
5 hours ago, Derek_ said:

A lot of people open up their unRAID to the world,

If they are, they are either only exposing specific containers, or they aren't following recommended practices.

 

For now, NONE of the base services except wireguard on Unraid should be forwarded to the internet. Wireguard is built in now, and there are multiple other ways to get secure access in to manage your server, but Unraid SSH itself should not be exposed.

 

Unraid is not a general purpose slackware box, it's just not meant to be used that way right now. We are slowly progressing towards being able to secure Unraid, but for now, keep it fully behind a proper firewall.

 

 

Link to comment

I installed this plugin and have had a small play. After a reboot, i get the error on the device monitor (not web interface):

chmod: cannot access '/user/local/emhttp/plugins/denyhosts/icons': No such file or directory.

I SSH'd in and saw that the directory does not exist.

 

Upon entering the webGUI, DenyHosts was not started. I started it via the GUI and it says it's started but ??

 

Through this exercise, it doesn't appear to alert unRAID that it hasn't successfully started - can that please added? Or is that a consequence of this error?

Link to comment
20 minutes ago, FreeMan said:

Is it? I thought it was still a plug-in until WireGuard was out of beta. Or is that what you meant by "built in"?

The WireGuard service and drivers are now built into Unraid at release 6.8.   

What is still a plugin (so it can be easily tweaked in the short term) is the GUI component for configuring the service.   You can in theory still use the built-in service by configuring it by hand but I suspect that this is not something that most users would want to contemplate.  

 

Link to comment
The WireGuard service and drivers are now built into Unraid at release 6.8.   
What is still a plugin (so it can be easily tweaked in the short term) is the GUI component for configuring the service.   You can in theory still use the built-in service by configuring it by hand but I suspect that this is not something that most users would want to contemplate.  
 
Ah! Thank you. I didn't realize the difference. I will most definitely change my thinking on this. Not that I had any concerns, I just thought the Unraid integration was still considered somewhat beta.

Sent from my moto g(7) using Tapatalk

Link to comment

As noted in my rogue General Support form post, I'm having issues accessing my Backup server via SSH now that I've rebuilt the USB stick for the server. I started with a clean install and added all plugins/dockers 1 by 1 until everything was reinstalled.

 

I can log into the WebGUI, but I cannot SSH in. I do have the plugin installed and SSH is enabled, allowing root logins:

image.thumb.png.f5ebd9e1f84909e9c0171e34055e1ba6.png.726967eb074df086351993a74f469cfb.png

This is what I get when I try to login via SSH:

image.png.8d5ca7440f891762dedf17082a5524c0.png

I click "No" to continue without saving the fingerprint (for now), then login with "root" and my password and get a simple "Access denied" response.

I would expect the fingerprint to have change after a rebuild of the flash drive, so that doesn't surprise me. What does surprise me is that the server name is now "Backup.local" - it's always reported just "Backup" in the past. I opened this PuTTY session by clicking on the same old saved session that I'd used before the rebuild. I've also tried connecting via IP and get the same response

 

Diagnostics are from my OP in the wrong forum - I've installed the preclear docker since then and currently have a drive preclearing. I wouldn't think that would impact the data in the diagnostics significantly since I had the issue both before and after installing the docker, but I can post new diagnostics if that would be preferred.

 

I'm sure there's something in the plugin that I have misconfigured. I put this server together as a backup 9-12 months ago, though, so I don't recall what configuration changed I may have made, and, of course, I failed to screen shot everything before starting from scratch... :/

 

backup-diagnostics-20200104-1517.zip

Link to comment

@itimpi in response to your question on my OP:

 

SSH is working just fine on my main server with the plugin and 6.8.0, so I don't think there are any compatibility issues on the Backup server between the plugin and 6.8.0. I haven't tried without the plugin on my Backup server, but will go ahead and do so, just because... you never know...

Link to comment
2 minutes ago, itimpi said:

Hmm :(   What about checking the content of the config/ssh folder on the flash to check that the contents look OK?

The contents of /backup/flash/config/ssh:

image.png.e47ecde2b0b3c1370624f155243bbcc2.png

 

I have no idea of what "normal" should look like, so I can't say if that's it or not... All files are dated 12/31/2019 except for sshd_config which is dated today, I presume since I just reinstalled the SSH plugin

Link to comment
18 minutes ago, FreeMan said:

What does surprise me is that the server name is now "Backup.local" - it's always reported just "Backup" in the past.

Under Settings -> Management Access -> Local TLD, it looks like that is set to "local". Mine is empty, although I don't really know what the downside is of "local" vs empty. I wouldn't expect either setting to prevent you from using SSH though

Link to comment
53 minutes ago, itimpi said:

You might want to check that none of them are 0 in size?   Typically most of them are about 1K.

 

 

None are zero bytes. They range from 93 to 3272 bytes.

 

53 minutes ago, ljm42 said:

Under Settings -> Management Access -> Local TLD, it looks like that is set to "local". Mine is empty, although I don't really know what the downside is of "local" vs empty. I wouldn't expect either setting to prevent you from using SSH though

Interesting, I don't think I'd ever looked there. Both my main and backup servers are set to "local". I'd never noticed that it said that in the title bar of the window because it only shows that when I'm logging in. Once logged in it shows "< user >@< server >" and there's no TLD displayed at all. Thanks for pointing that out!

Edited by FreeMan
Link to comment

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.