Posts by Enra

    An error occurred during a connection to 192.168.1.235:90. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    In my tut, OC runs the http server on port 90.
    Did you type https://192.168.1.235:90?
    Is ssl activated in your nginx config?
    Try https://192.168.1.235:YourHttpsPort

    Hi,


    here is a little HowTo save your data encrypted on a remote SFTP server.
    My purpose is to backup my data encrypted to my webspace, which is provided by a shared hoster.


    For the encryption I use ecrytptfs which is a file based encryption system.
    Therefore you can use any file-based sync software like e.g. rsync.
    The advantage is, that only changed files are retransmitted and not an huge container.


    OK. Let's start.
    We will mount the remote drive via SFTP (could also be another protocol) to the mountpoint e.g. /mnt/hoster-encrypted.
    It is called "encrypted" because on this mountpoint we will later see the encrypted files.
    Then we will put the encryptfs above this mountpoint. I did this on /mnt/hoster-decrypted.
    You can also mount the ecrypts on the first mountpoint; for troubleshooting reasons I prefer two separate dirs.


    Create the mountpoints:

    Code
    root@omv~#mkdir /mnt (not shure whether this allready exists)
    root@omv~#mkdir /mnt/hoster-encrypted
    root@omv~#mkdir /mnt/hoster-decrypted


    Then, if not yet done, install

    Code
    root@omv~#apt-get install ecryptfs-utils
    root@omv~#apt-get install sshfs


    Import your servers ssh-key:

    Code
    root@omv:~# ssh SFTPT-SERVER.NAME
    The authenticity of host 'SFTPT-SERVER.NAME (x.y.z.a)' can't be established.
    ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'SFTPT-SERVER.NAME,x.y.z.a' (ECDSA) to the list of known hosts.
    root@SFTPT-SERVER.NAME's password: blabla
    ..
    Connection closed by ...


    Now check whether the mount of your SFTP-SHARE to /mnt/hoster-encrypted works with your credentials:

    Code
    root@omv#echo YOUR-SFTP-PASSWORD | sshfs -o ServerAliveInterval=15 -o workaround=rename -o password_stdin SFTP-USER@SFTPT-SERVER.NAME: /mnt/hoster-encrypted/


    If it works, continue with the ecryptfs overlay:

    Youre ecryptfs_sig will be copied to /root/.ecryptfs/sig-cache.txt.



    Create this file /root/.ecryptfsrc with the following content but replace "YourSignature" with the value from "/root/.ecryptfs/sig-cache.txt":


    key=passphrase:passphrase_passwd=[YourPasswordInBrackets]
    ecryptfs_sig=YourSignature
    ecryptfs_cipher=aes
    ecryptfs_key_bytes=16
    ecryptfs_passthrough=n
    ecryptfs_enable_filename_crypto=n
    ecryptfs_fnek_sig=YourSignature


    Reboot


    Create mount and unmount scripts and test them:


    Sample unmount script:
    umount-hoster.sh
    #################################
    #!/bin/bash
    umount /mnt/hoster-decrypted
    fusermount -u /mnt/hoster-encrypted


    Sample mount script:
    mount-hoster.sh
    #################################
    #!/bin/bash
    echo YOUR-SFTP-PASSWORD | sshfs -o ServerAliveInterval=15 -o workaround=rename -o password_stdin SFTP-USER@SFTPT-SERVER.NAME: /mnt/hoster-encrypted/
    mount -t ecryptfs /mnt/hoster-encrypted/test /mnt/hoster-decrypted


    Now you can mount your webspace and save the data encrypted on it.
    For example you can rsync the home dirs to it:

    Code
    root@omv:~#rsync -rut -vv --delete /mnt/hd1/homes/ /mnt/hoster-decrypted

    (read the man-pages for the rsync parameters)



    Attention:
    Your ssh password is in plain-text in the mount-script.
    Your ecrypts password is in plain-text in the file /root/.ecryptfsrc.
    Copy /root/.ecryptfsrc to a safe place.
    Test everything a couple of times. There is a risk of data loss.
    If your editor is not unix-compliant, you should run "dos2unix" to your scripts and config file.
    I tried to documentate everything exactely. But it may contain errors.
    So if you encounter errors please report them.


    More information about ecryptfs can be found here: https://help.ubuntu.com/lts/serverguide/ecryptfs.html

    Hi,


    my experience when trying to backup my data encrypted to my nextcloud server running on my shared webspace (took me a couple of days..):
    The realibility was poor; I encoutered several "MySQL has gone away"s when uploading huge directories.
    Sharing huge directories lead to time outs. Not all files were shared.
    The NC encrytion module stores the keys also on the data-directory. So if someone gets access to your files...
    For every file and user who has access to it, a separate keyfile will be created.
    As the number of files is limited in my case; that's not desired.
    Time stamps are not preserved when uploading files on a webdav server.


    Maybe it works on a dedicated server. But on a shared server I would not recommend that.

    Hi,


    three likes, but unfortunately that does'nt solve the problem.


    Where could I place an "unlock-script"?

    • The network functionalities should be "up"
    • The data-drive should be mounted (this could perhaps also be done manually)
    • The services depending on that drive (smb, MySQL etc.) should not yet be started

    What happens, if the drive is locked when the services are started?
    Will they recover, when the drive is unlocked later?


    Any help appreciated
    Thanks

    Unter "Zugriffskontrolle -> Benutzer -> Einstellungen -> Heimatverzeichnis des Benutzers" steht der Schalter auf deaktiviert.
    Könnte das der Grund für die Fehlermeldungen sein?

    Sehr gut möglich.
    Ausprobieren.


    Wenn ich ihn aktiviere, will OMV einen Speicherort angegeben haben. Es bietet mir dazu aber nur die Festplatte an, die am BananaPi angeschlossen ist.

    Das macht doch nix. Ist doch nur das Home VZ. Kannst ja dann mal schauen, was da so für Daten reinkommen.

    Dann teste mal, ob du ohne den shutdown Befehl eine ssh Verbindung bekommst.
    plink ssh-user@192.168.1.31 -i f:\z\schl2.ppk
    Damit solltest du als der ssh.user auf die Konsole kommen.


    Dann kannst du
    sudo /sbin/shutdown -r now
    probieren.


    PS:
    Den ssh-user habe ich nicht in die Gruppe sudo hinzugefügt.
    Bei mir ist er in der Gruppe "root" drin.


    Ich weiss auch nicht, ob man diesen Hinweis ernstnehmen muss:
    # This file MUST be edited with the 'visudo' command as root.#

    Mit viel Stolpern habe ich nun einen Benutzer angelegt bekommen, der sich über ssh mit einem privaten Schlüssel verbinden kann.

    Also generell funktioniert es jetzt?


    Den Windows SSH Client kenne ich leider nicht.
    Evtl. probierst du es mal mit Plink (Cmdline Tool von Putty).

    Hi,


    for theft protection I want to lock my data drive with LUKS.
    As my server has a duty cycle of only 1/24 it is only started, when I need access to it.
    Also other persons in my familiy will start the server.
    So I need an auto-unlock function but I don't want to store the keyfile on the server itself.
    This will be some kind of "two-factor-auth".
    The keyfile can reside on my OpenWRT Router where it can be accessed by wget, cifs, ftp or nfs.


    I searched a couple of hours but did'nt find any solution for this common problem. ?(


    Do you have any suggestions?
    Thanks

    Hi,

    On local network, I can access on domotique web by domotique/ url.


    in this case you use "domotique" as the ip address of your server.
    When receiving the http request (that includes the name "domotique") nginx "knows" which page to deliver.


    When I use <ip_extern>/domotique,


    In this case you call the servers IP and request to deliver the content of the file "domotique".
    But should deliver the content of the folder "domotique".
    Perhaps there is a "/" missing at the end.


    Did you have a look at the logs?

    Hi,


    habe soetwas auf meinem Linux Router laufen.
    Das sollte aber auch mit Windows funktionieren.


    Der Ansatz ist, dass OMV einen SSH Key von deinem Client importiert:

    [GUIDE] Enable SSH with Public Key Authentication (Securing remote webUI access to OMV)


    Dann kannst du einen SSH Befehl direkt und ohne PW von deinem Client ausführen.
    Bei mir (Linux) sieht das so aus:


    ssh control@10.1.1.4 -i /root/.ssh/id_rsa sudo /sbin/shutdown -h now


    Wobei "control" ein OMV user ist, der SSH darf und in der sudoers Gruppe ist:


    Auszug aus /etc/sudoers
    # User privilege specification
    root ALL=(ALL:ALL) ALL
    control ALL=NOPASSWD: /sbin/shutdown