1

I am connecting to my server provided by institution via ssh. It is an Ubuntu server.

Home folder contains many users. Each user has a password. But I am not sure whether any user can enter into my folder.

I want to either hide or encrypt my folder. What I need to execute on my terminal?

hanugm
  • 169
  • 1
  • 4
  • 2
    What is the permission on your home directory. What's the output of `ls -ld "$HOME"`? Do you trust the system administrator? – Kusalananda Feb 14 '21 at 18:54
  • @Kusalananda `drwxr-xr-x 7` .... – hanugm Feb 14 '21 at 19:00
  • @Kusalananda I don't trust. – hanugm Feb 14 '21 at 19:01
  • And I need to keep so many passwords also in different `rc` files..... – hanugm Feb 14 '21 at 19:02
  • 2
    If you don't trust the system administrators, I would consider that system as "tainted" and not store anything on it, nor use it for anything. In particular I would never enter a password or any sensitive information while logged into it. In short, if you don't trust your admin, then the system is more or less useless to you. You could use it to _store_ encrypted data, but de- and encryption should happen elsewhere. Even on a home system, you would probably want to avoid storing passwords in plain sight in text files. Use something like `password-store`, depending on what passwords these are. – Kusalananda Feb 14 '21 at 19:06
  • @Kusalananda But, it is mandatory to store. Else I cannot access internet. I need to store passwords for internet access... – hanugm Feb 14 '21 at 19:13
  • 1
    I think we need a bit more context to be able to say very much more. What is your intended use of this system, what sort of data do you need to store on it, and why do you think you need to store important passwords on that system and not on a safe private machine? You mention "institution", is that a university? If so, you should probably not store personal data on that system in any case (only things related to your studies or your employment). – Kusalananda Feb 14 '21 at 19:50
  • If it's not your machine and someone else is the admin, then all bets are off for a regular user. As Kusalananda said, you either trust the admins, or you don't. NB: no admins I've seen would ever go poking around in some user's files without a reason. And even if they accidentally saw something personal while going about some admin task, they would respect your privacy and not talk about it or exploit it. Of course, they need to report anything illegal, and they'll ban-hammer your ass if you're doing anything to exploit or compromise the system. – cryptarch Feb 14 '21 at 20:45
  • Something to keep in mind is that sysadmin vs user is kind of an executor/trustee vs beneficiary kind of relationship. I.e. the computer hardware your system is running on is owned by your institution, not the sysadmins; the sysadmins are hired by the institution to ensure the needs of the users are met. Sysadmins take this relationship seriously. The power they have over the system is only available to them because they have certain responsibilities to uphold. If it were found out that some sysadmin was going around spying on user files arbitrarily, it would be a big scandal. – cryptarch Feb 14 '21 at 20:56
  • Weird that so many people commented here by nobody bothered to mention `chmod`. It's better to offer help and explain its limitations than simply asking fore more context and offering nothing. – Philip Couling Feb 14 '21 at 21:47

2 Answers2

2

As others have pointed out, you can't stop system administrators (anyone with sudo access) accessing your files. Even if you encrypt them, if you need to access their content on the server, then an admin can snoop on you while you do. This is true in most/all operating systems.

Your home directory is readable by all other users, usually by default. In comments you said your home directory had read permissions by all users.

Often all you need to do to stop other regular users is change the permissions on your home directory;

chmod 700 ~

This will block all users except for root (admin) from your home directory.

If you need to encrypt your data for legal or commercial reasons then this is often not enough unless you have been informed that the drives are encrypted.

Philip Couling
  • 17,591
  • 5
  • 42
  • 82
0

reading the title "hide/encrypt my files " ...

To encrypt a file (in the example below, denoted F);

(e.g with openssl,

using AES with CBC as Mode Of Operation)

AES - Advanced Encryption Standard

CBC - Cipher Block Chaining

openssl aes-256-cbc -base64 -pbkdf2 -in F

Note: pbkdf2 and -iter is not supported by lower versions than OpenSSL 1.1.1

One could use -iter <integer> to add a extra layer of security.

This, makes it harder(by making it slower) to try to brute force(guess) the password, but if a ridiculous amount of iterations is used, it will take very long - although, this is symmetric encryption and that is quite fast most of the time, just thought of mentioning this.

Note: use >= 10000 iterations

openssl aes-256-cbc -base64 -pbkdf2 -iter 10000 -in F

Decrypt

Denoting encrypted file "file.enc":

cat file.enc | openssl aes-256-cbc -base64 -pbkdf2 -d

Encrypt multiple files

(With the same extension) instead of encrypting every file:

For example,

to encrypt all files ending with .odt, in the folder odtFiles with a unique password (which is asked for interactively) and output the encrypted files to <originalfilename>.enc:

find odtFiles/ -name "*.odt" -type f -exec openssl aes-256-cbc -base64 -pbkdf2 -in {} -out {}.enc \;

References:

Related OpenSSL 1.1.1b warning: Using -iter or -pbkdf2..

OpenSSL Manual

William Martens
  • 174
  • 8
  • Optionally, if you prefer GUI rather than bash. I would suggest using Veracrypt. https://www.veracrypt.fr/en/Documentation.html – William Martens Feb 14 '21 at 22:46
  • 1
    Even assuming OpenSSL 1.1.1 (lower versions don't support `enc -pbkdf2 [-iter $n]`) the _default_ iter count is 10000 so 850 is a big _decrease_ in security; it is even lower than was recommended by RFC2898 in _2000_! – dave_thompson_085 Feb 15 '21 at 06:48
  • @dave_thompson_085 Hey! Thanks so much for pointing these things out! You can't imagine how thankful I am that there are people like you; thanks again - Will edit; GOSH thanks again for pointing those 2 crucial things out! – William Martens Feb 15 '21 at 10:14
  • 1
    Just a comment about readability: The first thing that one reads of this answer is "Don't use 850 Iterations", and one needs to reed _much_ further to figure out what that's about. It would be better if you incorporated edits into the natural flow of the text, so that the answer, at any time, is coherent when reading it from top to bottom, without any "Edit:" or "Updated:" markers. Also, avoid section headings for a short post like this. – Kusalananda Feb 15 '21 at 11:25
  • Okay - noted down, thanks for the explanation, *Just one question, avoid section headings for a short post - you mean I should not use ## or # (bold text) if the post is very short? - If there's something I have misunderstood (I've tried to edit according to your comment) please tell me that, or feel free to edit - I appreciate it! – William Martens Feb 15 '21 at 11:37