ssh with public key - bad ownership or modes for directory

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • ssh with public key - bad ownership or modes for directory

      I have created a user, added him to ssh group, put public key, disabled password auth. When I try to make ssh connection it fails with the :

      Permission denied (publickey).

      omv logs says:

      sshd[21546]: Authentication refused: bad ownership or modes for directory /

      I have no idea what's wrong with that...
    • I didn't change it. Is a fresh installation. Password auth works fine.

      Source Code

      1. root@raspberrypi:~# ls -lhd /
      2. drwxrwxrwt 24 root root 4.0K Jun 11 22:26 /
      3. root@raspberrypi:~# getfacl /
      4. getfacl: Removing leading '/' from absolute path names
      5. # file: .
      6. # owner: root
      7. # group: root
      8. # flags: --t
      9. user::rwx
      10. group::rwx
      11. other::rwx
      Display All
    • Permissions on top root directory wide open. If that happen who knows what else is screw up down bottom. Look even you have sticky bit there.
      Changing permissions recursively on the rootfs is a mayor f*ck.
      I would recommend you to reinstall. Please if you had follow a web tutorial or a guide on installing something you might not entered the command correctly.
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • This is really weird... I just made a fresh install. I went to GUI to enable permitted root to do ssh and look at the premission of / :


      Source Code

      1. Welcome to ARMBIAN 5.46 experimental Debian GNU/Linux 9 (stretch) 4.14.34-v7+
      2. System load: 0.16 0.11 0.06 Up time: 7 min
      3. Memory usage: 7 % of 976MB IP: 192.168.0.19
      4. CPU temp: 40°C
      5. Usage of /: 18% of 7.2G
      6. Raspberry Pi is a slow NAS: https://forum.openmediavault.org/index.php/Thread/19871
      7. [ General system configuration (beta): armbian-config ]
      8. New to Armbian? Check the documentation first: https://docs.armbian.com
      9. Changing password for root.
      10. (current) UNIX password:
      11. Enter new UNIX password:
      12. Retype new UNIX password:
      13. root@raspberrypi:~# ls -lhd /
      14. drwxrwxrwt 24 root root 4.0K May 31 09:59 /
      Display All
      I took image : OMV_4_Raspberry_Pi_2_3_3Plus.img.xz
      bruned it to SD card and put to rpi3
      waited for 10 minutes
      access to gui to enable ssh for root
      that's all
    • Fresh installation of OMV 3 gives me the right permission:


      Source Code

      1. Welcome to ARMBIAN 5.42 experimental Debian GNU/Linux 8 (jessie) 4.9.80-v7+
      2. System load: 2.43 2.39 2.38 Up time: 18 min
      3. Memory usage: 12 % of 976MB IP: 192.168.0.19
      4. CPU temp: 46°C
      5. Usage of /: 24% of 7.2G
      6. Raspberry Pi is a slow NAS: https://forum.openmediavault.org/index.php/Thread/19871
      7. Changing password for root.
      8. (current) UNIX password:
      9. Enter new UNIX password:
      10. Retype new UNIX password:
      11. root@raspberrypi:~# ls -lhd /
      12. drwxr-xr-x 23 root root 4.0K Jun 12 2017 /
      13. root@raspberrypi:~#
      Display All
      I can confirm that on OMV 3 everything works like a charm :)

      The post was edited 1 time, last by frankja2 ().

    • tkaiser wrote:

      Currently no RPi around and I don't think I'll buy such crappy hardware ever again...
      To my surprise I did not already delete the images on the build VM. Repeated the procedure and to me it looks like only permissions of the root directory were wrong and a simple chmod should be all that's needed:

      Source Code

      1. root@ubuntu:~# chmod 755 /mnt/omv4
      2. root@ubuntu:~# ls -la /mnt/omv4/
      3. total 116
      4. drwxr-xr-x 24 root root 4096 May 31 03:07 .
      5. drwxr-xr-x 5 root root 4096 May 30 08:22 ..
      6. drwxr-xr-x 2 root root 4096 May 31 03:06 bin
      7. drwxrwxr-x 2 root root 4096 May 31 03:22 boot
      8. drwxr-xr-x 2 root root 4096 May 28 07:44 dev
      9. drwxr-xr-x 106 root root 4096 May 31 03:22 etc
      10. drwxr-xr-x 2 root root 4096 May 9 00:31 export
      11. drwxr-xr-x 2 root root 4096 Feb 23 15:23 home
      12. drwxr-xr-x 17 root root 4096 May 31 03:07 lib
      13. drwx------ 2 root root 16384 Jun 15 23:49 lost+found
      14. drwxr-xr-x 2 root root 4096 May 28 07:44 media
      15. drwxr-xr-x 2 root root 4096 May 28 07:44 mnt
      16. drwxr-xr-x 2 root root 4096 May 28 07:44 opt
      17. drwxr-xr-x 2 root root 4096 Feb 23 15:23 proc
      18. drwx------ 3 root root 4096 May 31 03:20 root
      19. drwxr-xr-x 2 root root 4096 May 31 03:12 run
      20. drwxr-xr-x 2 root root 12288 May 31 03:22 sbin
      21. drwxrwxr-x 2 root root 4096 May 31 02:59 selinux
      22. drwxr-xr-x 2 root root 4096 May 9 00:31 sharedfolders
      23. drwxr-xr-x 3 root root 4096 May 31 03:11 srv
      24. drwxr-xr-x 2 root root 4096 Feb 23 15:23 sys
      25. drwxrwxrwt 2 root root 4096 May 31 03:22 tmp
      26. drwxr-xr-x 10 root root 4096 May 28 07:44 usr
      27. drwxr-xr-x 13 root root 4096 May 31 03:18 var
      Display All
      So with new procedure (only change is the chmod call) here's the result: OMV_4_Raspberry_Pi_2_3_3Plus.img.xz

      @frankja2 can you test please? Maybe this time testing will cover all issues :whistling:

      @ryecoaaron: when testing is sufficient can you please delete the old RPi OMV 4 image at sourceforge.net/projects/openm…ngle%20Board%20Computers/ and



      I think we need to put the RPi image into this specific download directory since tons of tutorials on the net reference this already.
    • tkaiser wrote:

      I think we need to put the RPi image into this specific download directory since tons of tutorials on the net reference this already.
      The image seems to be working ok from a short test.
      RPi image removed from OMV 4.x for Single Board Computers directory and readme updated.
      Uploaded new image and readme to RPi directory.
      Will remove 3.x image in a few days.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • LostInSwiss wrote:

      same issue with OMV_4_Banana_Pi.img.xz

      Unlikely. The above mentioned problem was due to manual intervention needed when creating the RPi image (since Raspberry Pi is a closed source platform needing the primary operating system called ThreadX being present in latest version on a FAT partition). All images for real ARM boards are created fully automated so those permission errors can't happen.
    • I was having the same issue with my Odroid HC1. Changing the permissions appears to have fixed the issue (see below).

      I'm also using the OMV_4_Odroid_XU4_HC1_HC2.img.xz image, clean install then upgraded to 4.1.10.

      Source Code

      1. root@odroidxu4:~# getfacl /
      2. getfacl: Removing leading '/' from absolute path names
      3. # file: .
      4. # owner: root
      5. # group: root
      6. # flags: --t
      7. user::rwx
      8. group::rwx
      9. other::rwx
      10. root@odroidxu4:~# chmod 755 /
      11. root@odroidxu4:~# getfacl /
      12. getfacl: Removing leading '/' from absolute path names
      13. # file: .
      14. # owner: root
      15. # group: root
      16. user::rwx
      17. group::r-x
      18. other::r-x
      Display All
    • I believe I'm also seeing this on my Rock64. Just installed it and have only configured things from the web dashboard so far (add users, mount drives, no plugins though).

      SSH with private key fails, but password works.

      Same failure message:

      Source Code

      1. root@nas:/# grep sshd /var/log/auth.log
      2. ...snip...
      3. Sep 4 22:52:38 nas sshd[11762]: Authentication refused: bad ownership or modes for directory /

      Permissions do seem wrong:

      Source Code

      1. stephen@nas:/$ ls -la /
      2. total 33
      3. drwxrwxrwt 1 root root 174 Jul 16 14:01 .
      4. drwxrwxrwt 1 root root 174 Jul 16 14:01 ..
      5. drwxr-xr-x 1 root root 2516 Jul 16 14:09 bin
      6. drwxr-xr-x 4 root root 1024 Sep 4 22:27 boot
      7. drwxr-xr-x 16 root root 3540 Sep 4 22:27 dev
      8. drwxr-xr-x 1 root root 3590 Sep 4 22:48 etc
      9. drwxr-xr-x 1 root root 0 Jun 13 00:45 export
      10. drwxr-xr-x 1 root root 0 Feb 23 2018 home
      11. drwxr-xr-x 1 root root 426 Jul 16 14:01 lib
      12. drwxr-xr-x 1 root root 0 Jul 2 03:23 media
      13. drwxr-xr-x 1 root root 0 Jul 2 03:23 mnt
      14. drwxr-xr-x 1 root root 0 Jul 2 03:23 opt
      15. dr-xr-xr-x 210 root root 0 Dec 31 1969 proc
      16. drwx------ 1 root root 120 Sep 4 22:50 root
      17. drwxr-xr-x 27 root root 1160 Sep 4 22:48 run
      18. drwxr-xr-x 1 root root 4096 Jul 16 14:13 sbin
      19. drwxrwxr-x 1 root root 0 Jul 16 13:54 selinux
      20. drwxr-xr-x 1 root root 12 Sep 4 22:32 sharedfolders
      21. drwxr-xr-x 1 root root 64 Sep 4 22:30 srv
      22. dr-xr-xr-x 13 root root 0 Sep 4 23:02 sys
      23. drwxrwxrwt 8 root root 180 Sep 4 23:10 tmp
      24. drwxr-xr-x 1 root root 70 Jul 2 03:23 usr
      25. drwxr-xr-x 1 root root 138 Jul 16 13:54 var
      Display All

      root@nas:/# chmod 755 / fixes it.

      The MD5 matches sourceforge.net/projects/openm…ngle%20Board%20Computers/ so think I have a good image.

      Source Code

      1. ~ md5 OMV_4_Rock64.img.xz
      2. MD5 (OMV_4_Rock64.img.xz) = 45f04cd266294c5921c63e32ac7f88ae
    • Fixed upstream in Armbian but this will only affect new images. On the current OMV4 images (except the one for RPi and now NanoPi K1 Plus) the manual 'chmod 755 /' fix is still needed in this situation.

      @ryecoaaron: can you please upload OMV_4_NanoPi_K1_Plus.img.xz to sourceforge.net/projects/openm…ngle%20Board%20Computers/

      NanoPi K1 Plus is rather interesting: 64-bit SoC, 2 GB DRAM, Gigabit Ethernet, 3 x USB2 with no shared bandwidth, eMMC socket...