3

I am switching from a GUI based password file to a text based one and I intend to encrypt with openssl.

openssl might be employed in a way similar to the following.

The following script might have a name like encryptPw.sh

#!/bin/bash
if [ ! -f pw.txt ] ; then
  echo "pw.txt not found"
  exit 1
fi
openssl aes128 <pw.txt >pw.aes128
if [ -f pw.aes128 ] ; then
  rm pw.txt
  rm --force pw.txt~
else
  echo "failed to create pw.aes128"
fi

The plain text password file might be edited via gedit. This creates a small risk if a person obtains unauthorized access to Ubuntu if the user is absent when logged in or some other way that provides access to the file system. Does gedit leave cache files or temp files after the gedit application is closed?

Aside: I will switch to full disk encryption since 16.04 is nearing end of long term support but in the meanwhile I have an interest in an answer to this gedit question. Even when a machine has full disk encryption it might make sense to continue to use this script because one would not want this file to be plain text in backups. If the backup goes to a cloud server then you have even more reason not to have plain text in backups. Assumption: The backup itself is not encrypted so for example just boot and de-crypt the full disk and execute tar and the tar archive constitutes backup. If the backup is an image copy of an encrypted disk then obviously "plain text risk" does not apply. The bottom line: If the backup is not the fully encrypted disk, I would want to use my password scripts.

Edit: Thanks to the answer and comment below I was able to add rm --force pw.txt~ to some of my scripts.

Related script getPw.sh

#!/bin/bash
if [ ! -f pw.aes128 ] ; then
  echo "pw.aes128 not found"
  exit 1
fi
openssl aes128 -d <pw.aes128 >pw.txt

Related script peekPw.sh

#!/bin/bash
if [ ! -f pw.aes128 ] ; then
  echo "pw.aes128 not found"
  exit 1
fi
openssl aes128 -d <pw.aes128 >pw.txt
cat pw.txt
rm pw.txt
rm --force pw.txt~
4
  • you should add -f with the rm. and add ` || true` behind it. That will stop rm from asking confirmation and any other message echoing to screen.
    – Rinzwind
    Jul 22, 2020 at 18:42
  • Relevant to "command || true" is this link. unix.stackexchange.com/questions/325705/…
    – H2ONaCl
    Jul 22, 2020 at 19:09
  • @Rinzwind Thanks. command || true sounds useful in some cases but rm --force fileName seems to make failure to remove harmless. The man description... "ignore nonexistent files and arguments, never prompt". Use of command || true as a rule for all removal commands might be a good rule in the sense that if you always do it then you don't need to think. However, at this point I am undecided as to whether I want to make that a rule for myself.
    – H2ONaCl
    Jul 22, 2020 at 19:28
  • The "Edit" part looks like the solution you finally settled on. In that case you should definitely remove it from the question and post it as an answer below by clicking the 'Answer your question' button. It's absolutely fine (and very much encouraged) to self-answer your question.
    – pomsky
    Aug 5, 2020 at 3:46

2 Answers 2

3

Hidden temporary tilde-suffixed files will normally exist by default after your first save, and of course they will remain if gedit (or your OS) crashes: Recover files from gedit

The tilde-suffixed file is in the same directory as the original file.

Creation of these files is optional and it can be changed in the preferences as follows: in the gedit menu follow the sequence Edit > Preferences > Editor > find the option that says 'Create a backup of files before saving' > uncheck that option.

There should not be any other temporary files or crash files in other directories.

2
  • The tilde-suffixed file is in the same directory as the original file. Creation of these files is optional and it can be changed in the preferences. Hopefully there are no other temp files or crash files in other directories.
    – H2ONaCl
    Jul 21, 2020 at 17:14
  • rm --force pw.txt~ was added to the script because that is safer than setting the preference to disable the creation of that file.
    – H2ONaCl
    Jul 22, 2020 at 18:59
0

If it is just one file you are just accessing manually:
You could encrypt the password file with vi.
vi -x pw.txt ....and then create a password when asked.

Then you type in the password on each access.
If someone does look into the file, it can't be deciphered...humanly
The limitation is that you'd have to use vi to work in it.

I wasn't sure if you are accessing a lot of password files
.... or just trying to maintain one that you have to go into once in a while
..... or manipulating programmatically, which for this would not be any good.
...just another possible option that solves the security concern.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .