ken-ji

Members
 View Profile  See their activity

  • Posts

    1245

  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Posts posted by ken-ji

    Docker Networking, VLANs and Unraid Access

    in Docker Engine

    Posted · Edited by ken-ji

    Hmm... containers in bridge networks are by default accessible by all the assigned IP of all the interfaces of the host. This is the default docker behavior and Unraid did not support the advanced mode here.

    However, think about it a bit. If you assign an ip on VLAN10 to Unraid, the containers can now be accessed on this IP in VLAN 10, but Unraid services become accessible as well.

    If there is no IP as you have it now, all containers on bridge networks, will only be accessible via the VLAN1 ip address

    So the best answer for a container to be accessible only from VLAN10, you would need to do custom docker networks and assign the desired IP (or dynamically via Docker) to the container. I think you already have this setup.

     

    Is there any reason you must run with a bridge network rather than a macvlan?

    Unraid OS version 6.9.0 available

    in Announcements

    Posted

    3 minutes ago, tuxbass said:

    That's pretty much what i've been doing so far. In go file there's this section for ssh changes: 

    
_ssh="/root/.ssh"
sshd_conf="/etc/ssh/sshd_config"

[[ -d "$_ssh" ]] || ln -s -- /boot/config/ssh "$_ssh"
find -L "$_ssh/" \( -type f -o -type d \) -exec chmod 'u=rwX,g=,o=' -- '{}' \+

sed --follow-symlinks -i '/^PermitEmptyPasswords.*/d' "$sshd_conf"
sed --follow-symlinks -i '/^PasswordAuthentication.*/d' "$sshd_conf"
echo 'PermitEmptyPasswords no' >> "$sshd_conf"
echo 'PasswordAuthentication no' >> "$sshd_conf"
# restart sshd service:
/etc/rc.d/rc.sshd restart
### /sshd

     

    Looks about right (for 6.8.3) though it is unnecessarily convoluted :D

    and its wrong for 6.9 as discussed above.

    So just put your authorized_keys file in /root/.ssh (which should now be symlinked to /boot/config/ssh/root)

    make a copy of /etc/ssh/sshd_config in boot/config/ssh and edit that

    then restart sshd with /etc/rc.d/rc.sshd restart which should make the new changes active

     

     

    Unraid OS version 6.9.0 available

    in Announcements

    Posted · Edited by ken-ji

    You also need to set 

    # To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

    To disable password login

    or since Limetech insists that only the root user be used 

    PermitRootLogin prohibit-password
#PermitRootLogin yes

     

    Remove VLAN config w/o UI?

    in General Support

    Posted

    Shutdown Unraid by Issuing poweroff command  on the terminal or press the power button for 1-2s

    Get the flash drive and delete config/network.cfg using another machine

    This will reset your network settings completely back to the initial config (DHCP, bonded)

    LSI 9200 SAS2008 not seeing any HDD

    in General Support

    Posted

    You're using the 8e (external), How is it connected to your HDDs?

    Are you using an Shelf/JBOD enclosure? SFF-8088->SFF-8088 is the usual here

    or are you feeding the cables back in SFF-8088->SATA? make sure you are using forward breakout cables as these are one directional and you can't use the other one (backward breakout) which is meant for controller/Motherboard SATA -> SAS enclosure (SFF-8088)

     

    Dockers all running; Unraid primary interface is down

    in General Support

    Posted

    Are you able to SSH into Unraid itself? if so you might be able to run diagnostics command and scp the output zip file so people can tell you what's up.

    Also bear in mind that if you have exposed the web ui (port 80/443) or the ssh port 22 to the internet  and don't have a decently strong password for the root account, there's a good chance your server has been compromised, which maybe why you can't connect to the web interface. (just exposing it to the internet even with a great strong password is not a guarantee that its been compromised.)

     

    Finally you can opt to try restarting the server with the reboot command

     

    Change adduser-Restriction

    in Feature Requests

    Posted · Edited by ken-ji

    There's a work around you can use if its acceptable to you: samba has username mapping

     

    merge this into /boot/config/smb-extra.conf (\\tower\flash\config\smb-extra.conf) - you create the file if it doesn't exist or you add the username map line under the [global] section 

    [global]
    username map = /boot/config/smb-users.map

    then create /boot/config/smb-users.map (\\tower\flash\config\smb-users.map) 

    user_name = user.name

    user_name is the name you have created in Unraid

    user.name is the name you have in the windows machines

    So two clients with both usernames  will  be treated as the same user (same password and permissions <- this is if acceptable to you.

     

    This should take effect immediately, or by restarting the samba service (/etc/rc.d/rc.samba restart) or by stopping and starting the array

    remote SSH in latest unraid with rclone

    in General Support

    Posted · Edited by ken-ji

    Well, the changes in 6.9.0 for SSH just mainly allows the ssh keys to persist across reboots without any user intervention. This eliminates the need for the hacks we've all created and pooled together to copy keys from storage during bootup.

    However, Unraid still does not have any GUI tools for generating the keys, but for most users using ssh, they already know how to do this on the CLI.

    A quick way  (if you are using Windows) is to download Putty from here https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html (or even just puttygen.exe) and use that to generate the key you need (exporting it in openssh format)

    Also SFTP is builtin in to most NAS/servers that have SSH enabled

    And if you want to get started but are bothered by the complexity of the SSH keys thing, you can encode your remote password into the rclone config (though most security experts would frown on this)

    Unraid OS version 6.9.0 available

    in Announcements

    Posted

    11 hours ago, tuxbass said:

    1) Is it safe to move all the keys files from /boot/config/ssh to /boot/config/ssh/root?

     

    Note the keys were created by unraid (likely during the very initial installation years ago), as I haven't generated them myself. Unsure what such a move might affect.

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

    My /etc/ssh/sshd_config has following line:
        PasswordAuthentication no

     

    After adding said line and restarting sshd (via /etc/rc.d/rc.sshd restart) password login is still allowed.
    2) What has changed, why isn't key-only login enforced anymore?

    only the files that should be in /root/.ssh should be in /boot/config/ssh/root. All other files will be copied into /etc/ssh whenever the sshd service is started/restarted, all the files in /boot/config/ssh are copied to /etc/ssh (non recursively) before sshd is started

     

    ssh key-only login was never enabled by default.

    To enable this, you copy /etc/ssh/sshd_config to /boot/config/ssh and edit that one.

     

     

    Additional Scripts For User.Scripts Plugin

    in Plugin Support

    Posted

    This is just sample code, but it can go into your script at line 2 (first possible code line)

    what the 1st line does is check if there exists a file /var/lock/script.lock (note the typo) and if it does, it prints "Still running" for the user reference and exits the script (lines 2 and 3)

    If the script still keeps running beyond the check (ie the file doesn't exist) it will then create the file and the script can do whatever you want.

     

    Then at the end of the script, the command I showed will forcibly delete any existing /var/lock/script.lock.

     

    All in all this means that when the script starts up, it checks if the lock file exists and will abort if it exists. this means a previously running script is still running (or crashed/aborted) and the script will no longer run until the lock file has been deleted. When the script does run, the last thing it will do is delete the lock file, thus allowing the script to run again.

    Unraid OS version 6.9.1 available

    in Announcements

    Posted

    32 minutes ago, Gico said:

    I have a lot of these messages in the syslog. No "old" (before upgrade) / other browser sessions exist to the Unraid server. Any ideas?

      

    
Mar 10 12:32:06 Juno nginx: 2021/03/10 12:32:06 [error] 9704#9704: *225050 limiting requests, excess: 20.104 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:06 Juno nginx: 2021/03/10 12:32:06 [error] 9704#9704: *225056 limiting requests, excess: 20.829 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:07 Juno nginx: 2021/03/10 12:32:07 [error] 9704#9704: *225058 limiting requests, excess: 20.731 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:07 Juno nginx: 2021/03/10 12:32:07 [error] 9704#9704: *225068 limiting requests, excess: 20.582 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:07 Juno nginx: 2021/03/10 12:32:07 [error] 9704#9704: *225071 limiting requests, excess: 20.456 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:07 Juno nginx: 2021/03/10 12:32:07 [error] 9704#9704: *225074 limiting requests, excess: 20.360 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:08 Juno nginx: 2021/03/10 12:32:08 [error] 9704#9704: *225076 limiting requests, excess: 20.207 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:08 Juno nginx: 2021/03/10 12:32:08 [error] 9704#9704: *225086 limiting requests, excess: 20.076 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:08 Juno nginx: 2021/03/10 12:32:08 [error] 9704#9704: *225092 limiting requests, excess: 20.815 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:09 Juno nginx: 2021/03/10 12:32:09 [error] 9704#9704: *225094 limiting requests, excess: 20.682 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:09 Juno nginx: 2021/03/10 12:32:09 [error] 9704#9704: *225096 limiting requests, excess: 20.583 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:09 Juno nginx: 2021/03/10 12:32:09 [error] 9704#9704: *225100 limiting requests, excess: 20.428 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:09 Juno nginx: 2021/03/10 12:32:09 [error] 9704#9704: *225103 limiting requests, excess: 20.296 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"
Mar 10 12:32:10 Juno nginx: 2021/03/10 12:32:10 [error] 9704#9704: *225105 limiting requests, excess: 20.200 by zone "authlimit", client: 192.168.168.10, server: , request: "PROPFIND /login HTTP/1.1", host: "junol"

     

    @Gico Do you know which client on your network is 192.168.168.10? its connecting to your server repeatedly via /login and nginx is complaining about it.

    • Thanks 1

    Passwordless SSH login

    in General Support

    Posted

    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.

    • Thanks 1

    Passwordless SSH login

    in General Support

    Posted

    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 1

    Passwordless SSH login

    in General Support

    Posted

    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)

     

    Unraid OS version 6.9.1 available

    in Announcements

    Posted

    Upgraded from 6.9.0 and seems to have resolved the issues with 6.9.0

    There some things that could still use fixing, like /etc/profile forcing bash to start in /root, which breaking some of my tmux scripts

    Also, I personally don't think its neccessary to force 777 access to the ./dev/dri, but I understand why you would want to take the easy way out and make things easier for users. Though it should be up to the docker image creators/maintainers to account for this.

     

    It simply is not the Unix mentality to just willy nilly assign all access to entire directories (I'm looking at the default/recommended Unraid file permissions) nor is it a good security practice.