September 22, 20205 yr What's the _unraid way_ of turning on key-only login access to unraid host? Can see there are some set of keys in /boot/config/ssh but there's no sshd_config found under /boot to enforce their usage. Why are there keys under boot/config/ssh to begin with if they're not used? Just to be clear, the goal is to secure ssh access so no bad actor on LAN can wreak havoc.
September 29, 20205 yr Unraid needs a method to configure SSH without needing the old SSH plugin. I also want to see 2FA in SSH.
October 2, 20205 yr Author On 9/29/2020 at 7:28 PM, Darksurf said: Unraid needs a method to configure SSH without needing the old SSH plugin. I also want to see 2FA in SSH. Have you configured unraid SSH with key-only? If so, could you walk me through?
October 21, 20205 yr On 10/2/2020 at 2:58 AM, tuxbass said: Have you configured unraid SSH with key-only? If so, could you walk me through? It should be just like any other SSH config setup. /root/.ssh is a soft link to /boot/config/ssh/root/ . So inside /boot/config/ssh/root/ , create authorized_keys file via "touch authorized_keys". Then you can copy and paste your info from you local machine's .ssh/id_rsa.pub key file. Remember to use the PUBLIC key file, not the private.
March 23, 20242 yr On 9/22/2020 at 10:16 AM, tuxbass said: What's the _unraid way_ of turning on key-only login access to unraid host? Can see there are some set of keys in /boot/config/ssh but there's no sshd_config found under /boot to enforce their usage. Why are there keys under boot/config/ssh to begin with if they're not used? Just to be clear, the goal is to secure ssh access so no bad actor on LAN can wreak havoc. There were two main things that I had to do to make this work across reboots: The path "/root/.ssh" is a symlink to "/boot/config/ssh/root/" -- so, any keys added to /root/.ssh/authorized_keys should persist across reboots. Copying "/etc/ssh/sshd_config" to "/boot/config/ssh/sshd_config" and only editing the copy in "/boot/config/ssh/sshd_config". This way, changes to the sshd_config file should be persistent across reboots as well. In my particular case, the actual changes I made to "/boot/config/ssh/sshd_config" were the 3 lines below (which already exist in the file; I just uncommented/changed where needed): PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no Once the changes to "/boot/config/ssh/sshd_config" have been made, you should be able to just restart the SSH daemon via "/etc/rc.d/rc.sshd restart". There's a section in that script that copies the contents over from /boot/config/ssh/* over to /etc/ssh/* (minus directories). Search for "sshd_start" in the script to see the actual section that does this. This has worked for me & I've been using this setup for quite some time.
January 15, 20251 yr On 3/23/2024 at 12:44 PM, Fafson said: There were two main things that I had to do to make this work across reboots: The path "/root/.ssh" is a symlink to "/boot/config/ssh/root/" -- so, any keys added to /root/.ssh/authorized_keys should persist across reboots. Copying "/etc/ssh/sshd_config" to "/boot/config/ssh/sshd_config" and only editing the copy in "/boot/config/ssh/sshd_config". This way, changes to the sshd_config file should be persistent across reboots as well. In my particular case, the actual changes I made to "/boot/config/ssh/sshd_config" were the 3 lines below (which already exist in the file; I just uncommented/changed where needed): PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no Once the changes to "/boot/config/ssh/sshd_config" have been made, you should be able to just restart the SSH daemon via "/etc/rc.d/rc.sshd restart". There's a section in that script that copies the contents over from /boot/config/ssh/* over to /etc/ssh/* (minus directories). Search for "sshd_start" in the script to see the actual section that does this. This has worked for me & I've been using this setup for quite some time. This really seemed the part, until I tried logging in without my key to check – I'm still prompted for my password and can log in with it. It seems to just be straight up ignoring the settings in sshd_config, but I've no idea what's going on really. Here's my terminal output, including the contents of sshd_config: me@my-machine ~ % ssh root@123.123.123.123 -p 2122 (root@123.123.123.123) Password: Last login: Wed Jan 15 10:43:19 2025 from 321.321.321.321 Linux 6.1.103-Unraid. root@Cube:~# cat /boot/config/ssh/sshd_config # $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 AddressFamily inet ListenAddress 192.168.10.123 # br0 ListenAddress 10.0.0.1 # br1 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # limetech - lets be verbose LogLevel VERBOSE # Authentication: # limetech - we need to allow root AllowUsers root PermitRootLogin yes #LoginGraceTime 2m PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no PermitEmptyPasswords no # Change to no to disable s/key passwords #KbdInteractiveAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the KbdInteractiveAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via KbdInteractiveAuthentication 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 # and KbdInteractiveAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes # limeteh - disallow forwarding but see below AllowTcpForwarding no #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server # limetech - permit only root SSH tunneling Match Group root AllowTcpForwarding yes root@Cube:~# Edited January 15, 20251 yr by emsixteen
January 15, 20251 yr 7 hours ago, emsixteen said: This really seemed the part, until I tried logging in without my key to check – I'm still prompted for my password and can log in with it. It seems to just be straight up ignoring the settings in sshd_config, but I've no idea what's going on really. Here's my terminal output, including the contents of sshd_config: me@my-machine ~ % ssh root@123.123.123.123 -p 2122 (root@123.123.123.123) Password: Last login: Wed Jan 15 10:43:19 2025 from 321.321.321.321 Linux 6.1.103-Unraid. root@Cube:~# cat /boot/config/ssh/sshd_config # $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 AddressFamily inet ListenAddress 192.168.10.123 # br0 ListenAddress 10.0.0.1 # br1 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # limetech - lets be verbose LogLevel VERBOSE # Authentication: # limetech - we need to allow root AllowUsers root PermitRootLogin yes #LoginGraceTime 2m PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no PermitEmptyPasswords no # Change to no to disable s/key passwords #KbdInteractiveAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the KbdInteractiveAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via KbdInteractiveAuthentication 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 # and KbdInteractiveAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes # limeteh - disallow forwarding but see below AllowTcpForwarding no #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server # limetech - permit only root SSH tunneling Match Group root AllowTcpForwarding yes root@Cube:~# I created a bug report for this,
January 17, 20251 yr Thanks for pointing this out, otherwise I probably would not have noticed. Since I've already upgraded, I'm not sure if this is something that started with unRAID v7.0.0 or if I just completely overlooked what the /etc/rc.d/rc.sshd script does. This appears to be the script that copies the files from /boot/config/ssh/* into /etc/ssh/* (minus sub-directories). Line 51 in "/etc/rc.d/rc.sshd" has the following: cp -n $SSH_BOOT/* $SSH_ETC 2>/dev/null With the "-n" parameter, the cp command will not overwrite any existing files. I had to work around this by adding the following lines to /boot/config/go: # ensure that the custom sshd_config file is copied to /etc/ssh cp /boot/config/ssh/sshd_config /etc/ssh/sshd_config So this is what my /boot/config/go file looks like: #!/bin/bash # ensure that the custom sshd_config file is copied to /etc/ssh cp /boot/config/ssh/sshd_config /etc/ssh/sshd_config # Start the Management Utility /usr/local/sbin/emhttp I restarted my unRAID server and looks to be working as expected: ❯ ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected] [email protected]: Permission denied (publickey,keyboard-interactive). ❯ ssh [email protected] Last login: Thu Jan 16 18:28:43 2025 from 192.168.1.149 root@alexandria:~#
January 17, 20251 yr 11 hours ago, Fafson said: Thanks for pointing this out, otherwise I probably would not have noticed. Since I've already upgraded, I'm not sure if this is something that started with unRAID v7.0.0 or if I just completely overlooked what the /etc/rc.d/rc.sshd script does. This appears to be the script that copies the files from /boot/config/ssh/* into /etc/ssh/* (minus sub-directories). Line 51 in "/etc/rc.d/rc.sshd" has the following: cp -n $SSH_BOOT/* $SSH_ETC 2>/dev/null With the "-n" parameter, the cp command will not overwrite any existing files. I had to work around this by adding the following lines to /boot/config/go: # ensure that the custom sshd_config file is copied to /etc/ssh cp /boot/config/ssh/sshd_config /etc/ssh/sshd_config So this is what my /boot/config/go file looks like: #!/bin/bash # ensure that the custom sshd_config file is copied to /etc/ssh cp /boot/config/ssh/sshd_config /etc/ssh/sshd_config # Start the Management Utility /usr/local/sbin/emhttp I restarted my unRAID server and looks to be working as expected: ❯ ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected] [email protected]: Permission denied (publickey,keyboard-interactive). ❯ ssh [email protected] Last login: Thu Jan 16 18:28:43 2025 from 192.168.1.149 root@alexandria:~# the problem is that rc.sshd actually generates part of the sshd_config dynamically. A better approach would be to prepend the following into the config and restart the daemon Include /etc/ssh/sshd_config.d/*.conf Then instead of a full sshd_config file create a custom.conf with only the values you want modified.
January 18, 20251 yr On 1/17/2025 at 6:20 AM, DiscoverIt said: the problem is that rc.sshd actually generates part of the sshd_config dynamically. A better approach would be to prepend the following into the config and restart the daemon Include /etc/ssh/sshd_config.d/*.conf Then instead of a full sshd_config file create a custom.conf with only the values you want modified. The "/etc/rc/rc.sshd" script only has a single function (sshd_build) that removes the existing ListenAddress & AddressFamily entries, irrespective of what their current values are. It then adds new entries for these two right after the "Port" line. This script is called during the boot process, before many services (including the sshd daemon) are even started. So even if going with the "Include" directive method, there shouldn't be a need to restart the daemon. At the very least, this is what is currently working for me and seemed like the simpler approach for my use case scenario.
January 19, 20251 yr Its a your mileage may vary situation. I'm simply suggesting the sshd_config.d/*.conf approach as its a more correct mentality. Nearly all distros have gone this approach as the individual values in this file override what is present in the base sshd_config file. The blanket override approach is dangerous because if required upstream changes to the config occur they will not be represented automatically in your custom sshd_config file.
January 26, 20251 yr this is do dumb, at least on Unraid 7 the sshd_config on your flash drive is ignored... my workaround that actually works made a file /boot/config/scripts/fix_sshd_config.sh #!/bin/bash SSHD_CONFIG="/etc/ssh/sshd_config" BACKUP_CONFIG="/boot/config/ssh/sshd_config" cp "$SSHD_CONFIG" "$SSHD_CONFIG.bak" sed -i '/^PermitRootLogin/d' "$SSHD_CONFIG" sed -i '/^PasswordAuthentication/d' "$SSHD_CONFIG" sed -i '/^PubkeyAuthentication/d' "$SSHD_CONFIG" echo "PermitRootLogin prohibit-password" >> "$SSHD_CONFIG" echo "PasswordAuthentication no" >> "$SSHD_CONFIG" echo "PubkeyAuthentication yes" >> "$SSHD_CONFIG" cp "$SSHD_CONFIG" "$BACKUP_CONFIG" /etc/rc.d/rc.sshd restart chmod +x /boot/config/scripts/fix_sshd_config.sh then in the go file nano /boot/config/go bash /boot/config/scripts/fix_sshd_config.sh
January 26, 20251 yr +1 to this, I just found out that password auth was back on on my server (7.0.0) https://docs.unraid.net/unraid-os/release-notes/6.9.0/#ssh-improvements does not seem to be respected anymore. I checked the rc.d script mentioned in the docs, but there's nothing that would be changing the PasswordAuthentication directive, it is only setting the listen addresses Edit: as mentioned in earlier comments, cp -n is preventing the already existing sshd_config from being copied so that explains this behaviour Edited January 26, 20251 yr by vagaerg
January 26, 20251 yr 32 minutes ago, vagaerg said: +1 to this, I just found out that password auth was back on on my server (7.0.0) https://docs.unraid.net/unraid-os/release-notes/6.9.0/#ssh-improvements does not seem to be respected anymore. I checked the rc.d script mentioned in the docs, but there's nothing that would be changing the PasswordAuthentication directive, it is only setting the listen addresses Edit: as mentioned in earlier comments, cp -n is preventing the already existing sshd_config from being copied so that explains this behaviour I've initially thought that it was the tailscale plugin messing around as reported by some redditors, but after reviewing the plugins code there is no relevance. As you mentioned the problem is within the rc.d script however I think that's read only. I've tried the following turned of ssh from UI removed the /etc/ssh/sshd_config turned on ssh from UI the config was actually copied from the usb flashdrive password login is not allowed But after reboot it still somehow replaces it with the default one, probably somewhere in the image on the usb drive.
January 26, 20251 yr 6 hours ago, el Romano said: this is do dumb, at least on Unraid 7 the sshd_config on your flash drive is ignored... my workaround that actually works made a file /boot/config/scripts/fix_sshd_config.sh #!/bin/bash SSHD_CONFIG="/etc/ssh/sshd_config" BACKUP_CONFIG="/boot/config/ssh/sshd_config" cp "$SSHD_CONFIG" "$SSHD_CONFIG.bak" sed -i '/^PermitRootLogin/d' "$SSHD_CONFIG" sed -i '/^PasswordAuthentication/d' "$SSHD_CONFIG" sed -i '/^PubkeyAuthentication/d' "$SSHD_CONFIG" echo "PermitRootLogin prohibit-password" >> "$SSHD_CONFIG" echo "PasswordAuthentication no" >> "$SSHD_CONFIG" echo "PubkeyAuthentication yes" >> "$SSHD_CONFIG" cp "$SSHD_CONFIG" "$BACKUP_CONFIG" /etc/rc.d/rc.sshd restart chmod +x /boot/config/scripts/fix_sshd_config.sh then in the go file nano /boot/config/go bash /boot/config/scripts/fix_sshd_config.sh That's way too complicated of an approach. Go the linux correct route with an override to the included file. nano /boot/config/ssh/sshd_custom.conf PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes nano /boot/config/go sed -i '1i Include /etc/ssh/sshd_custom.conf\n' /etc/ssh/sshd_config /etc/rc.d/rc.sshd restart Reboot or cp -r /boot/config/ssh/sshd_custom.conf /etc/ssh/sshd_custom.conf && /etc/rc.d/rc.sshd restart Edited January 26, 20251 yr by DiscoverIt
January 26, 20251 yr 32 minutes ago, DiscoverIt said: That's way too complicated of an approach. Go the linux correct route with an override to the included file. nano /boot/config/ssh/sshd_custom.conf PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes nano /boot/config/go sed -i '1i Include /etc/ssh/sshd_custom.conf\n' /etc/ssh/sshd_config /etc/rc.d/rc.sshd restart Reboot or cp -r /boot/config/ssh/sshd_custom.conf /etc/ssh/sshd_custom.conf && /etc/rc.d/rc.sshd restart you can remove parts of the script for simplification, but otherwise nothing wrong with it and instead of rewriting the sshd_config like in your case it actually injects the needed values, so my approach is actually better, byt ymmv.
January 26, 20251 yr Just now, el Romano said: you can remove parts of the script for simplification, but otherwise nothing wrong with it and instead of rewriting the sshd_config like in your case it actually injects the needed values, so my approach is actually better, byt ymmv. Modifications to daemon core config files is not a suggested work flow. It’s the reason why apt and other package managers ask how to proceed when the daemon gets updated. This way any changes to the core config file are allowed by the maintainer without breaking your config. It’s also the reason why default sshd config contains this include statement on nearly every distro, except unraid.
January 26, 20251 yr Obviously best fix is for LT to create a dedicated SSH settings page for all these settings.
January 28, 20251 yr On 1/27/2025 at 1:04 AM, DiscoverIt said: Modifications to daemon core config files is not a suggested work flow. It’s the reason why apt and other package managers ask how to proceed when the daemon gets updated. This way any changes to the core config file are allowed by the maintainer without breaking your config. It’s also the reason why default sshd config contains this include statement on nearly every distro, except unraid. Your suggestion to use an included file (sshd_custom.conf) is a valid approach, but it doesn't fully address the issue in Unraid. My script ensures the desired configuration is applied consistently, even if the core file is regenerated. While your method is more "Linux-correct," it doesn't account for Unraid's unique behavior. My solution is tailored to Unraid's specific workflow. Again as I mentioned my solution works, it is replicatable. Your works as well. What's the point of the discussion if it's not going to get fixed by LT
January 28, 20251 yr .. I just want to know which approach I should use which will get me this functionality, or if I should wait for Unraid changes. 😅
February 26, 20251 yr I just added this to my go file. # Restore custom sshd_config cp --update=all /boot/config/ssh/sshd_config /etc/ssh/sshd_config /etc/rc.d/rc.sshd restart But my vote would be adopt the use of customization files in an /etc/ssh/ssh.d directory. Seems to be more of a linux standard.
March 25, 20251 yr I'm officially confused... /boot/config/ssh - from my understanding this is basically the USB drive and is persistent What are these two folders for then: /etc/ssh /root/.ssh ? I can successfully SSH into my Unraid server using keys that I entered in the GUI via Settings -> Users -> root -> SSH authorized keys. Now I am trying to git commit to my Gitea docker container using SSH keys but I am unsure where to put the Gitea keys.
March 25, 20251 yr /root/.ssh is linked to /boot/config/ssh/root/ (so they are effectively the same folder) to help with making keys persistent.
March 25, 20251 yr On 2/26/2025 at 1:48 AM, Gex2501 said: my vote would be adopt the use of customization files in an /etc/ssh/ssh.d directory. Seems to be more of a linux standard. Agree with this. I prefer the method recommended by DiscoverIt method as it is a little closer to Linux standard but I've made a few adjustments below, along with explanations on how it works and why I chose this method. Guide 1. Run this command in terminal: nano /boot/config/ssh/sshd_custom.conf 2. Copy the following into sshd_custom.conf: PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes 3. Save and exit the editor (Ctrl+X, then Y, then Enter) 4. Run this command in the terminal: nano /boot/config/go 5. Copy the following into go: cp -p "/boot/config/ssh/sshd_custom.conf" "/etc/ssh/sshd_custom.conf" sed -i '1i #\n# CUSTOM SSHD INCLUDED IN LAST LINE\n#\n\n' "/etc/ssh/sshd_config" sed -i '$a \\n\n\n\n\n\n\n# Include overriding sshd_custom.conf for SSH key login only\nInclude "/etc/ssh/sshd_custom.conf"' "/etc/ssh/sshd_config" /etc/rc.d/rc.sshd restart 6. Save and exit the editor (Ctrl+X, then Y, then Enter) 7. Optionally, you can run each of the 4 commands individually from Step 5 in the terminal to apply the changes right away without rebooting. Explanation sshd_custom.conf is a custom configuration file for sshd that we created in Step 1 using nano. It is used to override or extend the settings in the default sshd_config file. go is a script that runs automatically at system startup as part of Unraid. It allows you to define custom commands or scripts that should execute each time Unraid boots. cp -p "/boot/config/ssh/sshd_custom.conf" "/etc/ssh/sshd_custom.conf" This command copies the sshd_custom.conf file, created in Step 1, to the /etc/ssh/ folder. sed -i '1i #\n# CUSTOM SSHD INCLUDED IN LAST LINE\n#\n\n' "/etc/ssh/sshd_config" OPTIONAL This adds a few comment lines at the start of sshd_config to indicate that changes have been made. While not necessary, it helps to alert you if you ever need to diagnose SSH settings, especially if Unraid changes how SSH is configured. sed -i '$a \\n\n\n\n\n\n\n# Include overriding sshd_custom.conf for SSH key login only\nInclude "/etc/ssh/sshd_custom.conf"' "/etc/ssh/sshd_config" By default, sshd_config has PermitRootLogin yes, but this will be overridden to PermitRootLogin prohibit-password as stated in sshd_custom.conf. The SSH daemon applies settings in order, which is why the Include command is placed at the end. This ensures that any default settings or future Unraid changes are overridden by your custom configurations. /etc/rc.d/rc.sshd restart This restarts the SSH daemon to apply the new configuration changes. Edited March 27, 20251 yr by unraid_user11
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.