Beiträge von NAS-i-Goreng

  • 1GB /tmp at 100% when storing .mp3 images from IP cam

    Hmm, yes that's what I need to figure out then: What is in there that could be needed?

    The other issue with a scheduled reboot is that it sometimes hangs on reboot (rarely but it has happened).

    And for a NAS that's not ideal.

    Hence I'd like to avoid a reboot and let the cron job do something else.


    What could be the reason for this unlimited groth of /tmp? I'm guessing that images are stored on /tmp while being processed to their final location.

  • 1GB /tmp at 100% when storing .mp3 images from IP cam

    Hello,


    This is a strange phenomenon, but maybe someone else has experienced this before:


    Setup:

    I've got some CCTV IP cameras where I store the images via a ffmpeg cronjob onto an OMV partition.

    At a set limit the first files get overwritten, so this directory wont grow unlimited.

    It is still in a test phase and not 24/7 online.


    Issue:

    However, whenever I've got this running, /tmp grows to 100% and I've experienced OMV to be completely frozen my that (no login, had to perform a cold reboot).


    Idea:

    I understand that /tmp is usually emptied on reboot, but can one manage this e.g. by setting up another cron job to empty /tmp periodically?

  • User /.bashrc empty

    Got some output. Yes missed the $ character...


    "Zugriff auf '...' nicht möglich: Datei oder Verzeichnis nicht gefunden" = "Access to '...' not possible: File or directory not found"

    To my surprise USER seems to be directed to use a bashrc in /srv/.../USER/USER2

    After this line, it only returns a long list of files, so I cut it short.

    The same command with USER2 returns the same path to this ./bashrc.


    So to test that this is correct, I assed to the ./bashrc:

    Code
    HISTTIMEFORMAT="%Y-%m-%d %T "

    However, the command works as a temporary one for a terminal session but it won't stay permanent via this entry.

    So I still wonder if this was the correct ./bashrc


    Code
    echo $( getent passwd "$USER" | cut -d: -f6 )

    returns a simple /home/USER (not USER2)

  • No PubKey Login

    Ahh yes.... [where is the had bang smiley?].


    Code
    ssh-copy-id -f -p '123' -i ~/.ssh/id_ed25519-A.pub USER@192.177.3.22

    ...did it after all.

    -n was left over from a dry-run attempt.


    This is actually a non-thread now, nobody would learn anything from this (apart from that too long hours or hot weather get your brain scrambled).


    admin: feel free to delete, I'll mark it as solved.


    Thanks Zoki once again!

  • User /.bashrc empty

    Zitat von Zoki

    This should show the .bashrc of $USER ls $( getent passwd "$USER" | cut -d: -f6 )/.bashrc


    Replace $USER by the user name. echo $( getent passwd "$USER" | cut -d: -f6 ) will print the home dirctory of $USER

    User names are case sensitive

    Code
    ls: Access to '/home/USER/.bashrc' not possible: File or Directory not found

    :/

  • No PubKey Login

    Hello,


    My OMV seems inconsistent, but I'm not sure if I should really blame it.


    From machine 1 I can login via public key authentication.

    From machine 2 I can only login via password authentication.

    The above is the same for ssh via the terminal or sftp via Nemo.

    User is the same.

    Machine one runs on Bodhi

    Machine 2 runs on Sparky


    sshd_config allows both, PW and public key as I wanted this "backdoor" still open in case I lose a key file, not ideal, I know.


    On machine 2 I generated the key and ssh-copy-id ..ed it over to the OMV however with option -f (forced mode).

    Without the forced mode, it returns:


    I named the key of machine to ...-1 to avoid potential douplicate issues.

    What explains this different behaviour for one and the same user?

  • User /.bashrc empty

    Hello,


    I tried to add some features to a user's bashrc. But if I open ~/.bashrc it is an empty (=new) file.

    The user does have a home directory and e.g. ~/.bash_history does exist (so no skeleton .bashrc as suggested here Where is bashrc?

    But where is ~/.bashrc as I'd assume the "the shared folder you select under the user's name" is the user's home directory?

  • No Shell, no SSH Login

    Yes, something to go through now before I try again. Also need to check the sections in the sshd_config as I somehow messed up the sectioning.

    I might do a dry-run on another local machine regarding the user jail before I go to OMV again.


    I'll mark this one as solved now, thanks for all help!

  • No Shell, no SSH Login

    Zitat von Zoki

    matchgroup defines a block. It should go last.


    To test, simply keep a ssh session open and restart sshd instead of rebooting.

    So keep one terminal session open, add MatchGroup last and try to open a new ssh session from another terminal?


    The manpage sshd_config(5) says:

    Zitat

    Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. If a keyword appears in multiple Match blocks that are satisfied, only the first instance of the keyword is applied.

    In other words: MatchGroup overrides all AllowGroup and as a consequence also AllowUsers unless they match the given group specification?

    And if I place it at the end of the file, it won't find anything anyway, so I could leave it out as well?!?

  • No Shell, no SSH Login

    Update:


    I've unexpectedly gained access again via terminal login directly on the machine itself without the suggested procedure in #8.

    Changed the sshd_config and commented / uncommented last changes and then I was able to log in via shell as well as sftp (via Nemo).

    So against all error messages, this didn't seem to be a permission issue. It would have surprised me because I only changed/set the permissions for the new jailed users and their homes, not for any existing one (user Andi who is not jailed and part of ssh, sudo, root).


    Below is the sshd_config with amendmends as commented.


  • No Shell, no SSH Login

    Zitat von Zoki

    Why don't you just comment it in sshd_config?

    See #8 on how to do it.

    ...

    That's an adventure for tomorrow.

    I'm indeed still hoping to fix it rather than re-setting/restoring it.

  • No Shell, no SSH Login

    Yes, just saw this:

    Zitat

    'This is caused by permissions set on the chroot directory.

    The fix is to remove the SFTP user's write access to the chroot directory.

    However, as it only accepts tokens, it seems on cannot just specify a directory where everything is present.

    I tried removing write permissions for users but that didn't make a difference.


    If I understand this reference correctly, adding ForceCommand internal-sftp to the sshd_config would get around the requirement of files in the chroot directory:

    Zitat

    Specifying a command of internal-sftp will force the use of an in-process SFTP server that requires no support files when used with ChrootDirectory


    ...or not?


    I wish I could display and potentially chmod permissions via the GUI.

  • No Shell, no SSH Login

    Ah ok, that is good to know, thanks!


    I also added the option

    Code
    ChrootDirectory %h

    This doesn't sound wrong to me as it would lead any user to his home directory.

    But the error message seems to indicate a problem with the directory.


    If I disable this option in the 'SSH' section of the GUI,

    Code
    # ChrootDirectory %h

    could this disable the existing entry or will it simply add another entry that is inactive?

  • No Shell, no SSH Login

    After I set up a new (jailed) user, I also changed the file permissions for this user's home to 0700 (recursively) along with the group.

    But I never touched root or the one pre-existing user.


    As linked above, I started along a template process that involves creating a group, new user, adjusting respective file permissions and adapting the sshd_config.


    What made me wonder is why the 'bad ownership' error refers to root "/" , not the user's specified /home directory.

    Code
    bad ownership or modes for chroot directory component "/"

  • No Shell, no SSH Login

    Zitat von Zoki

    The original sshd_config has AllowGroups root ssh. No need for AllowUsers.

    ...

    This was something that I added because I wanted to allow users who on the other hand were not part of any group.

    I created a new group 'Jailed' that was supposed to contain jailed users and intended to make the jail secure by filtering groups and users.


    What I wasn't sure about was whether AllowGroups or AllowUsers might take priority over the other (thus blocking users that aren't in any allowed group e.g.).


    I will try to add an explicit 'AllowGroups' option under SSH.


    Question: Could I potentially paste a full (re-modelled) sshd_config into the 'options' fiels under 'SSH' ?

  • No Shell, no SSH Login

    Yes, same as with one of the other users who is actually in the ssh and sudo groups as well and also listed previously as AllowedUser.


    Auth log says:

    Code
    Jun 23 16:01:18 OMV sshd[10856]: User root from 192.168.2.31 not allowed because not listed in AllowUsers
Jun 23 16:01:18 OMV sshd[10856]: Postponed keyboard-interactive for invalid user root from 192.168.2.31 port 42262 ssh2 [preauth]
Jun 23 16:01:25 OMV sshd[10860]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.31  user=root
Jun 23 16:01:26 OMV sshd[10856]: error: PAM: Authentication failure for illegal user root from 192.168.2.31
Jun 23 16:01:26 OMV sshd[10856]: Failed keyboard-interactive/pam for invalid user root from 192.168.2.31 port 42262 ssh2
Jun 23 16:01:26 OMV sshd[10856]: Postponed keyboard-interactive for invalid user root from 192.168.2.31 port 42262 ssh2 [preauth]

    So dilligently added 'root' to AllowUsers but the result is the same.


    I also rebooted the system, no change. It still thinks 'root' is illegal because it's not listed under 'AllowUsers' although this line is added under 'SSH'

  • No Shell, no SSH Login

    Now this gets interesting:


    Added user 'Help' and put him into those two groups.


    Code
    Jun 23 15:16:42 OMV sshd[2013]: User Help from 192.168.2.31 not allowed because not listed in AllowUsers
Jun 23 15:16:43 OMV sshd[2013]: Postponed keyboard-interactive for invalid user Help from 192.168.2.31 port 40808 ssh2 [preauth]
Jun 23 15:16:48 OMV sshd[2015]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.31  user=Help
Jun 23 15:16:50 OMV sshd[2013]: error: PAM: Authentication failure for illegal user Help from 192.168.2.31
Jun 23 15:16:50 OMV sshd[2013]: Failed keyboard-interactive/pam for invalid user Help from 192.168.2.31 port 40808 ssh2
Jun 23 15:16:50 OMV sshd[2013]: Postponed keyboard-interactive for invalid user Help from 192.168.2.31 port 40808 ssh2 [preauth]


    Ok, since I cannot edid the sshd_config, I added a further option under 'SSH' via the GUI:

    Code
    AllowUsers Help


    In a furthe modification, I also added previously allowed users but 'Help' should have gone through in any case- but it didn't!


    Then I added another user (just to re-confirm): sepp (and also added him to the AllowUsers list.


    AuthLog shows this however:


    On the other end I'm getting the 'broken pipe' error obviously.


    Is there any way to see the whole sshd_config or am I searching in the wrong direction here regarding the 'bad ownership' error?

  • No Shell, no SSH Login

    Hello,


    I think I locked myself out of OMV.


    This happened (probably) after I changed file permission as part of an attempt to creat a user jail (as a reference, I went along the lines of this: Chroot Jail and this (not in English): Chroot Jail - Ubuntuusers.de)


    It didn't happen immediately but only after I logged out and tried to log in again a few days later now.

    Login usually happens via public key, not PW, although I still left this option active in the sshd_config (as a backup I thought and for other machines...).


    Auth log shows this line:

    Code
    Jun 23 13:12:42 OMV sshd[1460]: fatal: bad ownership or modes for chroot directory component "/"


    Shell login attempt from the client returns:

    Code
    Enter passphrase for key '/home/laptop/.ssh/id_ed25519':
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.2.33 ([192.168.2.33]:123).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
packet_write_wait: Connection to 192.168.2.33 port 123: Broken pipe

    Similarly I obviously cannot login from a client via Nemo or any GUI file managers.


    I have a suspicion that I need to check and perhaps modify some permissions here but how can this be done w.o shell or file manager access with only the IMV GUI available?

    Another suspicion I have is that I might need to modify the /etc/sshd_config but again, this needs some writable access.


    Any suggestions would be much appreciated.

  • /tmp at 100% space - why?

    Hello,


    I wanted to open the user crontab, so typed 'crontab -e' and as a result received this:

    Code
    /tmp/crontab.SSGOfJ/crontab: No space left on device


    So checked /tmp and found three files:

    npm-26318-bc545970

    systemd-private-9599c278efaf4e8980a22942458b471c-chrony.service-jP6vh4

    systemd-private-9599c278efaf4e8980a22942458b471c-systemd-resolved.service-PKtX2n


    There is plenty of space available.


    Why do I get a "no space" reply?


    And if I try to cd into (to check what's in there)

    Code
    /tmp/crontab.SSGOfJ/crontab

    or

    Code
    /tmp/crontab.SSGOfJ/

    it returns that the file or directory is not found.


    'df -h' however shows that /tmp is at 100%

    I'm currently using FFMPEG to record a video stream in sections onto /srv/USB, so totally bypassing the local file system. I'm assuming this should not affect /tmp.


    What can fill /tmp ?