Frank Steinmetzger wrote: > Am Tue, May 14, 2024 at 06:28:17AM -0500 schrieb Dale: >> Howdy, >> […] >> remember either, or write notes to remember them. I also wanted to >> avoid the desktop copy and paste, or clipboard, mechanism. I'm not sure >> how that data is stored in the clipboard and how good it is at erasing >> it when I clear it. > The mark-and-middleclick you describe further down is the very same as the > “normal” clipboard. It is just accessed differently. >
I thought that too. I highlighted some text in a Konsole and then looked in the KDE clipboard, what I highlighted was not there. It wasn't there after I pasted it either. It goes to a clipboard somewhere but it appears it only remembers one entry then forgets when you highlight something else. I'm not aware of a way to access it yet. I've looked for it but can't find it. To be honest, I wish there was a way to clear it, wherever it is. I clear my KDE clipboard that is on my desktop pretty regular. I always do so after copying passwords or something important. I'm wondering if that clipboard is a part of Konsole itself. I've never seen anything in the KDE clipboard that I just highlighted in Konsole. Now if I highlight and right click to copy, that goes to the KDE clipboard as expected. I'm not sure where the Konsole clipboard info goes. >> First, I needed to generate a password. I googled, a lot. I had >> trouble finding a way to generate the type of passwords I wanted but I >> finally found one. > Care to elaborate regarding the “password you wanted”? There is the obvious > pwgen, which can generate passwords with given character sets and length. > Keepass can do this, too, so I assume, Bitwarden (which you use) has a > similar function. > > And if you don’t like parts of the generated PW, keep the part you like, > generate new and pick the part you like again. Or just let pwgen generate a > big bunch and pick what you like best from the output. > I could use Bitwarden to generate passwords but then I'd need to copy it to my regular clipboard to get it to the Konsole. I wanted to avoid that. Bitwarden is a awesome tool. It's like LastPasss but open source. When LastPass got bought and started limiting basic features, I switched to Bitwarden. Honestly, I wish I had started with Bitwarden to begin with. I like my passwords to have all sorts of characters in as random a order as possible. Most all password tools do a good job of this. The thing I like about the method I posted, I can control exactly what characters are used, individually. I had a website once that allowed some characters, like above the number keys on older keyboards, but didn't allow a few odd ones. LastPass and Bitwarden have the option to turn them off or on as a set but not individually. Luckily that website wasn't something sensitive like a bank or anything but still, some websites do limit what can be used and some are a bit weird. With the command I use, I can easily, in a one time way, leave out anything that I need to but leave the rest. >> […] >> Now that I have a password, how do I keep track of them? I did some >> more searching. I wanted something that was command line not GUI. >> After all, I have BitWarden for websites and such already. Thing is, >> it's GUI since it is a Firefox add-on. I'd need to use the clipboard to >> copy and paste. I want to avoid that remember? I also wanted something >> that is on its own, separate from my main password tool BitWarden. I >> found kpcli in the tree. > I didn’t know about kpcli and it is not available in Arch. So I looked it > up. Turns out it is a non-graphical Keepass client (that’s what the kp > stands for, after all). > > Interestingly, there is also a bitwarden CLI client. > > Did you know Keepass (the graphical one) has an autotype feature? This means > that it simulates the pressing of keys, so it bypasses the clipboard > entirely. Another advantage of that is that you can set up custom key > sequences in the autotype field, so you can for example say “first enter the > username, then press enter, then wait for a second, then enter the password > and press enter again.” Useful for sites that use a dynamic login screen > with animations or non-standard input fields. > I didn't know KeePass had that feature in the GUI version. I did know kpcli was based on KeePass in some way tho. I read that somewhere. Kpcli just fit the need I had and was in the tree to install. Now that I got it setup, it does what I want, no need switching. ;-) >> Then I needed some way to handle if the password file kpcli uses got >> lost or damaged. If I were to lose that file, all drives and the data >> on them is lost. I'd lose everything because there is no way to >> remember the password. > The obvious answer is: backup – encrypted or not. ;-) > My Keepass database is a simple file in my home that is backed up together > with all the other home files by Borg. Meaning I even have a versioned > backup of my passwords. Needless to say my backup drives are LUKSed with a > long passphrase that I have never ever once written down anywhere on paper. > I’ve been using it for so long now and on several drives, that it is > ingrained in my brain. > Right now, /home is not encrypted. I only encrypt the data drives and the drives I backup too. What you describe tho is a good method. As long as /home is not open yet, the other drives are safe since the keys are in /home and not available. Bonus is, key files used to open the other drives can be thousands of characters long. If I ever encrypt /home, that is a good way to go. That actually gives me a good reason to encrypt /home. I may have found a excuse to use the drive I'm about to replace with a larger drive. >> The kpcli file itself appears to be encrypted. >> So, it protects itself. That's good. I don't need to put the file on >> something that is also encrypted, just copy it to a plain file system as >> it is. I have a USB stick that I store things on. Things like drive >> info, what drives go to what volume group, what drive has the OS on it >> etc and the portage world file on it. I also have some scripts in /root >> that I don't want to lose either so I copy them to the stick as well. > Be mindful that USB sticks aren’t very reliable. The flash chips in them are > what is left after quality control deemed them unfit for duty in SSDs (first > tier) and memory cards (second tier). So always keep several copies, > possibly on different types of storage media (HDDs, SSDs, optical, whatever). I have two more sticks on the way. They are a better brand too. Still, I plan to have several copies of them. I've never had a stick go bad but as soon as I put something priceless on one, it will. Murphy's law. I do have /root backed up to two separate hard drives tho. The USB sticks are just easier to plug in and copy back over or access directly. >> Then one important file, my file that contains frequently used >> commands. It is rather lengthy and is 15 years or more of additions. I >> copied all that info to a USB stick. It lives in the fire safe. > TBH, I wouldn’t put all my horses on one USB stick in a fire safe. (Or > however the saying goes) After a flimsy USB stick with questionable flash > chips has been subjected to high temperatures for a longer time, chances are > you may not be able to access its data ever again. I actually back up /root to my backup drives as well which is where the kpcli files is put and my scripts, if you want to call them that. I have several copies of that. I have two backup drives that have important parts of /home, Documents and such, /root and other small but important files. Just like now, I'm about to install another large drive in one of my encrypted LVMs. The smaller drive I remove, it will become a backup drive. I don't know what will go on it yet but I'll figure out how much important stuff I can fit on it. It's a 6TB drive but I'm sure the kpcli file will be on that too. So, I'll have at least two USB sticks with the kpcli file, plus two backup copies that I already have plus the new one. What I need, is more external eSATA drive enclosures. I don't like USB connected external drives. I've bricked a few drives before using USB. If I use eSATA, they work just fine. USB, they die. I have no idea. Maybe it is something wonky with my mobo or something. They work for everyone else. >> How I use all this. I do this in a Konsole, within KDE, which has >> tabs. Might work on a plain console to tho. If I need to open a >> encrypted drive, or set of drives, I open kpcli and get it to show the >> password for that drive in one tab. I then run the little script to >> open and mount that drive in another tab. When it asks for the >> password, I highlight the password from kpcli tab and then switch tabs >> and middle click to paste the password in. > Since you’ve already scripted most of it, you could possible go the full > way. Use the HDD’s UUID as key and either store the password in a file that > is named with the UUID, or in keepass with the UUID as entry title. Then you > can let the script retrieve the password all by itself without any need for > copy-pasting – except for unlocking the keepass file. > > I don’t know how often you insert, unlock and mount a drive. But given you > have so many drives, I imagine it to happen regularly. I have a standing appt to get shots on Thursday morning. I close all the encrypted drives before I leave. Usually, that is just one, sometimes two. So once a week on those. I update the OS on Saturday. When the OS update is done, I drag out the backups and update those if needed. One is a set of three drives for a large amount of data. Two are smaller and backup /root, parts of /home, portage world file and other little things. I have two other drives that backup other things. I plan to eventually set up a large set of drives and using LVM, divide them into parts and back stuff up that way. I'm thinking about getting a large drive cage or something or make something myself to hold several drives. That way I can still fit them in the fire safe but hook everything up when needed. My current method isn't hard or anything but still kind of kludgy. Maybe after I get my new rig built, I'll buy four or five 16 or 18TB drives and use those like above. I dunno. >> I don't use the desktop >> clipboard to do this. Once the drive is open, I then highlight random >> things, 3 or 4 of them, to make Konsole forget the password. It seems >> to only remember one thing at a time. I'm not aware of any history >> being stored within Konsole. > It’s not Konsole that does any of the clipboard handling. It merely accesses > it. You have the primary clipboard (Ctrl+X/C/V) and optionally the KDE > clipboard manager that remembers the last x entries. And you have the > secondary clipboard (marking text and pasting with middle-click). That’s an > X feature from yesteryear. There is an option in the KDE clipboard manager > whether it should observe the secondary clipboard or not. > > BTW: if you copy something within the Keepass GUI (a username, password > etc), then Keepass itself will clear the clipboard after a configurable > delay (default is 10 seconds). But how does one access that or clear it? Or is there a way to do that? You know one thing I wish, when I quit kpcli, it would clear the screen. That way it erases anything I did inside kpcli. I checked the options, I didn't see that listed. >> So, found a way to generate some pretty random passwords, whatever >> length and characters I want. I found a good way to store them. > Is your home encrypted with a good passphrase? And your home backup, too? If > the answer is yes to both, then any additional encryption step may be nice > for peace of mind, but technically unnecessary. My keepass file is > passphrase-protected, because it stores my entire digital life. > But for stuff like offlineimap and fetchmail/fdm, I have no problem with > storing passwords in plaintext in their config files, because those files > are protected by the file system encryption. > My /home is not, yet. As mentioned above tho, you gave me a good reason to do so. I will do this on my new build. >> I'm also able to copy and paste them in a way that has no history of the >> passwords that I'm aware of. > Clipboard history is a desktop feature – if you enabled it. If you want to > be fully sure, use alternatives like the aforementioned autotype or reading > files directly into your script. > >> I've also made copies of the file in case >> the OS drives goes out on me or the file gets erased or corrupted. > That’s always a good idea. > >> I get a LOT of help from this mailing list. Rich, Micheal, Neil and >> several others. I hope at least one person will read all this and find >> it useful in some way and I get to give back a little. Having a way to >> generate and remember passwords is a important thing if you encrypt your >> drives. > There is of course also the possibility to let KDE remember the passphrase. > I have some LUKS passphrases in my KDE wallet and the wallet itself has no > password – because all filesystems are encrypted anyways. > I've never used KDE wallet. Heard of it but never used it. I use Bitwarden in Firefox for websites already tho. I used LastPass before that. Just never had the need I guess. While my way is not likely what many would want, someone may take bits and pieces of this and use it. You mentioned you had never heard of kpcli before, you learned something. You may not use it but you learned something. I learned something to from your reply. If I encrypt /home, I can use key files that are stored on /home to open everything else. One password for /home and then everything else comes alive. Now you started something. ROFL Dale :-) :-)
