Beiträge von kwon

    Hi there,


    I usually install OMV on an encrypted Debian, following this.

    No issues, thanks by the way for making this a possibility, using an encrypted OS is very important for some use cases.


    I now have built a machine for someone who wants to use a USB-Drive with a keyfile to unlock the system. Not really tricky either, I did that as follows:


    1. create keyfile and chmod it

    2. cryptsetup luksAddKey /DEVICE /PATH2KEYFILE

    3. add it to cryptsetup:

    sdf3_crypt UUID=XYZ /dev/disk/by-uuid/ABC:/KEYFILE luks,keyscript=/lib/cryptsetup/scripts/passdev

    4. update-initramfs -uv


    Two questions I got about that:

    a) is the above the preferred method to do it? Or is there another way I'm not aware of?

    b) main problem: fallback to password does not work. If I do it this way and the USB is inserted all works fine, but if the USB with the keyfile is not present the machine does not start but hangs with no way to insert the LUKS password, so the OS could be unlocked.


    My main concern is that the user might loose / damage the USB-Stick with the keyfile, so a fallback might be important.


    Thanks and happy tinkering through the holidays.

    Hi there,


    when installing from debian following the docs here [1] I get a gpg error.


    Code
    uname -a:
    Linux RoRu0 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux


    Code
    dpkg --print-architecture:
    amd64


    I Installed debian today, from netinstall with only ssh server and standard system utilities.

    Possibly important: the reason to install it from debian is I want a fully encrypted system.

    I did the exact same thing on a different machine a couple of days ago with no issue.



    However now when entering this command:

    Code
    wget --quiet --output-document=- https://packages.openmediavault.org/public/archive.key | gpg --dearmor --output --yes "/usr/share/keyrings/openmediavault-archive-keyring.gpg"


    I get the following error:

    Code
    gpg: '/usr/share/keyrings/openmediavault-archive-keyring.gpg' kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden
    gpg: Entfernen der ASCII-Hülle ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden


    I suspect it's nothting major, but I couldn't find any solution or posts of others having this problem, hence I put it here.






    [1] https://docs.openmediavault.or…stallation/on_debian.html

    Very helpful, thank you for the detailed explanation.

    Where do you see the advantage to use KVM instead? Wouldn't that sort of achieve the same thing? With of course more overhead, since you need to use a whole VM, but that these days has gotten rather simple to manage as well and the resources are not that much of a difference for my purposes anyway.


    I'm a lot more used to qemu / kvm as well, so you see, "if you hold a hammer everything looks like a nail" etc. :)

    Zitat

    It really sounds more like a copy&paste problem than anything. Sometimes if you copy a string from one framework (gtk2 for instance) and try to paste into another (qt5 for instance), the paste will paste nothing since it thinks the copy buffer is empty. I would try pasting into byobu before typing ssh (and then erase) since you can't see how many characters are being input into ssh password prompt. Or just use ssh keys.

    Let me clarify what i did (numeroous times now, since I just like you could not believe it) in detail:


    1. password: EXampl3 --> is stored in Keepnote

    2. copy this via GUI (right-click copy) or strg+c (no difference)

    3. paste it to byobu terminal --> exactly how it should be, no spaces etc

    4. delete that, ssh into the machine, paste *the same thing from buffer* --> no log in

    5. type it in by hand --> log in works

    6. disconnect ssh

    7. reconnect and paste "the same thing from buffer* --> log in works


    EDIT:

    I also tried pasting it into gedit in between in case some strange formating thing might cause it

    Zitat

    Personally, I think anything that connects to the internet like syncthing should at least be containerized.

    Interesting. I thought it might be better to keep the surface minimal for security reasons, your argument seems to be exactly to do the docker-route for the same reason. I need to check with my friend, he somehow worked the security-aspect differently.


    Zitat

    But if you install docker from omv-extras and the compose plugin, you just have to cut&paste the compose file from guide and tweak the settings.

    Hm. That sounds rather simple, but tbh the [How to] Prepare OMV to install docker applications seemed to be quite a bit of a hassle for just wanting syncthings webinterface available. The How-To is great, as in very detailed, but right now I tend to wanna try both routes, yet for tonight I'm worried I might fuck something up with docker and ruin my sunday. :)

    And I'm not sure which advantage the containerization would offer - which is mainly because I have no experience with it, so feel free to advise if you want to.

    docker is so simple that it is fine for a single purpose. You will probably configure more by not using docker. Did you read the guide? - [How-To] Install Syncthing using Docker

    I did.

    I'm very familiar with syncthing, not at all with docker.

    If you recommend it even for this I'll at least give it a try.

    Gotta be sure with one machine to have it ready by tomorrow, so I was hesitant to use docker since - if anything goes wrong I got no idea how to fix it. :)


    Setting it up without docker pretty much is only installing the .deb file and making sure in systemd that it automatically starts, plus setting up a user, right?

    If byobu is trying ssh protocol v1, that would be the problem - it is disabled in sshd configured by OMV and by sftp in the sftp plugin.

    If we'd assume that's the problem - then why does the problem occur *only* once after restart?

    After I logged in once by typing by hand it also works again in byobu via copy&paste. (which I just verified again before I posted this)


    :) If you'd be here I'd offer a glass of scotch now. Really weird this one...

    I know there's a tutorial for setting up syncthing with docker.


    I'm not too keen on docker and would wanna avoid setting it up just for this single purpose.


    Questions:

    a) is there anyone else who tried setting it up just as headless on OMV and are there any recommendations / advise you'd offer? Or reasons not to do it that way?

    b) if not - is there any interest in a HowTo if I do it? A friend of mine uses it like that already, so it shouldn't be a big deal to set this up.

    Zitat

    Have you tried not using byobu? Or maybe just try xterm by itself?

    Just did. And it actually really might be byobu, after restarting, same thing again with byobu, but a pure gnome terminal the same paste just works.

    This is *really* weird, because like I said before, I only have this on debian 11/ OMV6 servers. All the not yet updated machines work just fine.

    Zitat


    25 years of using Linux and I've never seen something like this.

    Dude, if I were you I would totally assume some user error as well. I'm not you - and I still am suspecting some user error, that's why quadruple and quindruplechecked everything over and over, to avoid making a fuzz about just some stupid typo.


    But like I mentioned earlier - I'm a real documentation-nazi, I love checklists and doing things step by step. I've installed so many OMVs I can't count them, and I use a checklist for it that I copy for every new install and then tick what I have done. I do nothing, not even a quick click in the WebGui, without checking it in my log. :)


    So what I wrote above here is *exactly* what I did, nothing more, nothing less. I did it all this morning, so my memory is fresh as well:

    I also still need to check it with another client PC, just to see what that does.


    Zitat

    Does /var/log/auth.log tell you the password is incorrect?

    !! Good point!

    Found something


    Code
    Sep  3 11:39:16 f4p-lit sshd[1063]: error: kex_exchange_identification: Connection closed by remote host
    Sep  3 11:41:43 f4p-lit sshd[1068]: error: Protocol major versions differ: 2 vs. 1
    Sep  3 11:41:43 f4p-lit sshd[1068]: banner exchange: Connection from 1xx.xxx.xxx.xxx port 51872: could not read protocol version
    Sep  3 11:41:43 f4p-lit sshd[1069]: Unable to negotiate with 1xx.xxx.xxx.xxx port 51906: no matching host key type found. Their offer: ssh-dss [preauth]

    The not matching host key is just since I didn't set up keyauth yet, right?

    But the "protocols differ" thing - that shouldn't be should it? However if it's about different protocols for ssh on the clients - why then does that effect byobu and not non-byobu?!?


    EDIT:

    forgot to mention:

    authentication does fail, so something about the pasted password is different it seems:

    Code
    Sep  3 18:59:58 f4p-lit sshd[1069]: Failed password for root from 1xx.xxx.xxx.xxx port 46160 ssh2
    Zitat

    I have no idea how you are having this problem. What ssh client?

    :) glad I'm not the only one puzzled here.

    I'm using the Gnome Terminal, only possibly unusual here is byobu (not sure if you know it, works like tmux)


    Zitat

    I use complex passwords and have never had this issue. All I can think is you are using some special character that doesn't copy&paste well? Can you give an example of the password? I really don't think this is a Debian issue either. I use ssh all day long and each system has a unique, complex 16+ character password that I use copy&paste with.

    For the three machines I'm testing now it is only letters and numbers, so pretty certain that's not it.

    I had a bunch of other things to deal with myself, but now I can offer some further results and I'm quite irritated still and wonder what the heck I might do that is different since it does not seem to effect others:


    - I had a completely different machine (different hardware) installed two weeks ago, exactly the same issue. In this case it was a bit of a problem, since it went to a friends place, so being able to log in remotely was kind of important. In the end I couldn't really fix it before we had to take the machine to his place. Here is my log of what I did:

    1. install with freshly downloaded openmediavault_6.0.24-amd64

    2. install bunch of cli-tools (I'll go into that later, not the issue even though I suspected those first)

    3. installed plugins (backup, borg, diskstats, mergerfs, resetperms, rsnapshot, sftp, snapraid, symlinks, cputemp)

    4. formated HDDs, created shared folders and activated SMART checks

    5. backupjobs for rsync and rsnapshot

    6. at that point I noticed the notifications aren't sent, I had that issue before, that after a while they suddenly appear. I guess this is another issue.

    7. dashboard activated, set userpassword for webinterface, added two users.


    After a restart I again could

    - login to the webinterface with no issue

    - login locally on the machine with root

    - could NOT log in with SSH

    - after changing the root-password locally it works again, until the next restart.


    I originally thought it is related to the complexity of the password, with easier passwords it seemed the problem does not occur, but that was false. See below.


    So the strongest indicator what somehow creates the problem is the restart. (??!??)


    Now today I had time again to fiddle with the three machines I had the problem first with. And this is weird, stay with me:

    I intentionally did only very rudimentary things and logged everything yet still I get the same problem:


    1. install with freshly downloaded openmediavault_6.0.24-amd64 (on three identical machines, installed with three separate USB-thumbdrives, but created from the same ISO)

    2. NO cli tools installed at all this time to be sure it's not them.

    3. loaded updates via webinterface

    4. plugins: backup, borg, rsnapshot - nothing else

    5. settings: set timezone, logout to an hour, powerbutton to shutdown

    6. restart

    --> same fucking shit...


    During the installation of updates I got this error which I'm pretty sure is not related:

    Code
    Setting up Salt environment ...
    [ERROR   ] Command '/usr/bin/patch' failed with return code: 1
    [ERROR   ] stdout: patching file /tmp/__salt.tmp.lv7pru4c (read from /lib/python3/dist-packages/salt/fileserver/roots.py)
    Reversed (or previously applied) patch detected!  Skipping patch.
    1 out of 1 hunk ignored -- saving rejects to file /tmp/__salt.tmp.cr2of4lk
    [ERROR   ] retcode: 1


    Solution / sort of work around:

    because it seemed just unreal I tried again a couple of different ways to log in and varying ways to insert the password:

    - remember, locally always no problem, only via SSH the login fails

    - I safe the passwords in a passwordsafe / during installation in keepnote

    a) if copy and paste from keepnote --> does not work after restart, but once changed the password locally it works again (????)

    b) if instead of GUI for copy paste I use strg+shift+v -> same result, no login

    c) if I type it in by hand --> no problem (which sucks, since I use rather complex passwords) but at least I can log in now

    d) Now the funny bit: I type the password by hand in another line (directly below to make sure there's no typo), copy it --> NO login

    e) AFTER I once had logged in by typing by hand THEN it works again with copy and paste, no matter of GUI or strg+shift+v


    It took me a while to get through all the possible variants. And it fuckin sucked!!! :)

    But I guess this is not a OMV issue. I'm using Debian Buster on the client, might be that one (unlikely, since it only occurs with OMV6 machines) or maybe some weird thing how debian 11 deals with copypasted passwords.


    Does anyone of you have regular contact to someone in the debian-universe to investigate this further?


    If nobody else has had this issue it may mean

    a) everybody instantly switches over to keys once installed (unlikely)

    b) everyone uses way to simple passwords and don't mind typing them (I hope this is unlikely but am not sure)

    c) there's something else involved I haven't figured out yet (might very well be)


    In any case, this was not fun. I'm gonna get some chocolate ice now. And rethink my choices... :)

    Can you try a simple password without cut & paste? I have a dozen OMV boxes and use root on all of them. I have no idea how you are getting this issue.

    I do too, and never had that issue before.

    I can try that with one of those already installed that show the issue, but to be honest, I'd like to keep two of them as is for now, so I can investigate further if necessary in the logs.

    And I'll install the third one on another SSD with - like you suggested - a simple password and try to recreate the issue. Since I have a log of everything I did in detail that should not be a problem.

    Also as mentioned above I get the same result with another user, which I specifically created to test if that one can log in. With the password I created I can log in locally, not via SSH.


    Edit:

    just had an idea and changed the password of that user in the webinterface, to something very simple (xxx) - and now I can log in.

    OK, I really wanna know if I can replicate this... I'll report back on that once I did all that on another machine.


    In the mean time:

    - resetting the password over cli locally is the simple solution for now I guess to get the machines back to work. If anyone should ever have an issue like this. Which is... so weird.


    edit2:

    I can't get my head around how I could log in as "kwon" locally, not via SSH but after resetting the password I suddenly can?!??


    also I get at login via ssh:

    Zitat

    Could not chdir to home directory /home/kwon: No such file or directory

    Do you have fail2ban installed? The configs say it should allow root unless you have the wrong password or the service hasn't been restarted.

    - no fail2ban, only the plugins listed above

    - dashboard says SSH runs fine, also it does respond with "Permission denied" and I did restart SSH before and restarted the machine a couple of times by now


    Zitat

    Have you looked at /var/log/auth.log when the connection is being rejected? I really don't know why your system is working this way.

    Three systems. All the same behavior. I am sort of irritated as well...

    I could install on another SSD to see if this can be replicated. But like I said - I did exactly the same thing on three machines, and the same result.


    /var/log/auth.log

    I just went through it, didn't know that one, thanks.

    So I can see that the problems started after I installed the plugins (I had a list of plugins i would need and got through that list on all three machines simultaneously).

    Now what is interesting:

    Zitat

    Failed password for root from XXX.XXX.XXX.XXX port 49154 ssh2

    Is the port normal?


    Now in case you didn't notice what I wrote above I'd like to stress this again - I'm a documentation nerd. I got a hierarchical lists I'm working through in an outliner when I install OMV (so mostly copy and paste) and I installed quite a lot of them this way.

    But if I were you I'd suspect user-error - which is why I tried to eliminate those above. But still - if I may have overlooked anything lets verify. However the only explanation I got at this point would be that the root password got changed somehow - which just can't happen...


    To clarify:

    - I use the same password to login locally just fine

    - I used the exact same document to copy the password from before to login just fine, (before installing the plugins)

    - now that password does not work, copied or typed by hand

    - just to make sure I didn't make some stupid mistake without noticing (even though I guarantee I'm as precise about these things as it gets) I tried all three different passwords of all three machines - so one of them would have to be the one, even if I would have mixed things up - which I did not.


    I got nothing.

    managed to do it via USB


    sshd_config


    omv_sftp_config

    Since I didn't have any better idea:

    - there's no AllowUsers restriction etc. apart from the above mentioned AllowGroups


    - restarting SSH --> no change

    - turn off root login via webinterface -->

    /etc/ssh/sshd_config RootLogin No (as it should)

    --> exactely same behavior as before, root AND the non-root user can not login, same "permission denied" response. All on port 22.

    - changing it back also no problem, but still same result, no login via SSH.


    I thought this is just a small thing but I sort of am irritated now...

    Just to be sure I just tried a local login with the second user I mentioned, no problem.

    So both can login locally, both can't via SSH.

    I also made sure it's not the keyboard and copy-pasted the password.


    So unless I'm missing something: somewhere the login isn't permitted, but it is neither deactivated PasswordAuth nor PermitRootLogin.

    I'm not aware of another switch for that...