Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #27708 > unrolled thread

command line password manager

Back to article view | Back to comp.os.linux.misc

Contents

  command line password manager Eli the Bearded <*@eli.users.panix.com> - 2019-07-26 19:21 +0000
    Re: command line password manager Rich <rich@example.invalid> - 2019-07-26 20:36 +0000
      Re: command line password manager Eli the Bearded <*@eli.users.panix.com> - 2019-07-26 22:07 +0000
    Re: command line password manager John Forkosh <forkosh@panix.com> - 2019-07-27 01:44 +0000
      Re: command line password manager Eli the Bearded <*@eli.users.panix.com> - 2019-07-27 06:11 +0000
        Re: command line password manager Rich <rich@example.invalid> - 2019-07-27 15:18 +0000

#27708 — command line password manager

I've had to use a number of different password managers during my
employment career. I dislike having to use a web browser or a special
GUI to access passwords, but I can understand why companies might
prefer such systems.

My method of choice for my personal stuff has been encrypted plain text
files for a long time now. I decrypt when needed and copy the values
of interest. My method works very well for my usual workflow of
memorizing commonly used usernames and passwords and also allowing me to
associate relevant things together. Eg: I have a work file with gmail,
github, and web forum accounts all tied to my work identity. My personal
github account has a seperate file. 

But recently I've been doing some work that requires me to enter
passwords over and over and it's made me think about how this could be
made more friendly to my workflow methods.

I'm envisioning a simple command line program that can just push the
password into the copy/paste buffer (actually "| xclip -i"). I could
write such a tool. I can see how Hashicorp's 'vault' would do a good
job providing the backend. But is there something already written for
this sort of use case?

Example vault version:

    $ cat getpw
    #!/bin/sh
    export VAULT_ADDR=http://127.0.0.1:8200
    vault kv get -field=value secret/"$1" | xclip -i
    exit $?

    $ cat setpw
    #!/bin/sh
    export VAULT_ADDR=http://127.0.0.1:8200
    printf "Enter password for $1: "
    read value
    vault kv put secret/"$1" "value=$value"
    exit $?

But immediately one can see flaws like no error handling, sanity checks,
or even setting the terminal to not echo back the password in the setter
program. (Access control to that would be governed by having the correct
VAULT_TOKEN environement variable set.)

So before I actually embark on this, what else is there? I do kinda see
this as a encrypted-in-RAM cache tool to supplement other password
stores so maybe nothing else exists and is better.

Elijah
------
vault is easy to set up...

[toc] | [next] | [standalone]

#27709

Eli the Bearded <*@eli.users.panix.com> wrote:
> I'm envisioning a simple command line program that can just push the 
> password into the copy/paste buffer (actually "| xclip -i").  I could 
> write such a tool.  I can see how Hashicorp's 'vault' would do a good 
> job providing the backend.  But is there something already written 
> for this sort of use case?

There are a few CLI password managers out there.  Only you can 
determine if they are appropriate for your use cases.

A quick google search turned up (among other web pages):

https://www.passwordstore.org/

https://opensource.com/article/18/4/3-password-managers-linux-command-line

https://linoxide.com/linux-how-to/best-command-line-password-managers-linux/

[toc] | [prev] | [next] | [standalone]

#27710

In comp.os.linux.misc, Rich  <rich@example.invalid> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
> > I'm envisioning a simple command line program that can just push the 
> > password into the copy/paste buffer (actually "| xclip -i").  I could 
> > write such a tool.  I can see how Hashicorp's 'vault' would do a good 
> > job providing the backend.  But is there something already written 
> > for this sort of use case?
> There are a few CLI password managers out there.  Only you can 
> determine if they are appropriate for your use cases.

There are quite a few *text mode* password managers out there, but CLI
(as demonstrated by my example code) fewer.

> A quick google search turned up (among other web pages):
> 
> https://www.passwordstore.org/

This is the only one that meets my CLI rule. As described there, it
doesn't use an internal shell for commands nor start a full terminal
text-instead-of-graphics-UI (a "TUI").

> https://opensource.com/article/18/4/3-password-managers-linux-command-line

[describes titan, gopass, and kpcli]

> https://linoxide.com/linux-how-to/best-command-line-password-managers-linux/

[describes passmgr and titan]

None of those are truely command *line*. They are all terminal based.
Think difference between 'ifconfig' and 'nmtui' or 'sed' and 'vi'.

The pass program described at passwordstore.org is easy to install and
intriguing. It's not too different in philosophy from my existing main
workflow, but I haven't figured out how to make master password entry
command line. By default it creates a GUI window to read the master
password. I managed to coerce not to do that, but instead it creates
a TUI window:


   ┌───────────────────────────────────────────────────────────────┐
   │ Please enter the passphrase to unlock the secret key for the  │
   │ OpenPGP certificate:                                          │
   │ "pass-testing (July 2019) <bogus@qaz.wtf>"                    │
   │ 2048-bit ELG key, ID 1ADB457C,                                │
   │ created 2019-07-26 (main key ID 97FB9CCC).                    │
   │                                                               │
   │                                                               │
   │ Passphrase __________________________________________________ │
   │                                                               │
   │         <OK>                                   <Cancel>       │
   └───────────────────────────────────────────────────────────────┘


And it seems to ignore the PASSWORD_STORE_X_SELECTION environment
variable that is supposed to let me specify "primary" (instead of
"clipboard").

So at first blush, not going to work for me.

Elijah
------
always thinks he asks a clear question and then finds how it wasn't clear

[toc] | [prev] | [next] | [standalone]

#27713

Eli the Bearded <*@eli.users.panix.com> wrote:
> <snip>
> But recently I've been doing some work that requires me to enter
> passwords over and over and it's made me think about how this
> could be made more friendly to my workflow methods.
> <snip>

Isn't >>that<< the real problem? ... i.e., "enter passwords over
and over" (in cleartext) is itself a vulnerability for various
kinds of attacks. So that's the aspect of your workflow which
really should be changed in some way. And then a password manager
is moot.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#27716

In comp.os.linux.misc, John Forkosh <forkosh@panix.com> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> But recently I've been doing some work that requires me to enter
>> passwords over and over and it's made me think about how this
>> could be made more friendly to my workflow methods.
> Isn't >>that<< the real problem? ... i.e., "enter passwords over
> and over" (in cleartext) is itself a vulnerability for various
> kinds of attacks. So that's the aspect of your workflow which
> really should be changed in some way. And then a password manager
> is moot.

There are things I can change and things I can't change. And in this
case entering a password for sudo a bunch of times ends up being a
recurring theme at $WORK. But *next* time the current problem comes
up (which it does from time to time), now at least I have a prepared
script to deal with it on all of the machines.

Of course, a problem other than the current one is another matter.

Elijah
------
can leverage ssh keys only for getting onto the machines

[toc] | [prev] | [next] | [standalone]

#27717

Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, John Forkosh <forkosh@panix.com> wrote:
>> Eli the Bearded <*@eli.users.panix.com> wrote:
>>> But recently I've been doing some work that requires me to enter
>>> passwords over and over and it's made me think about how this
>>> could be made more friendly to my workflow methods.
>> Isn't >>that<< the real problem? ... i.e., "enter passwords over
>> and over" (in cleartext) is itself a vulnerability for various
>> kinds of attacks. So that's the aspect of your workflow which
>> really should be changed in some way. And then a password manager
>> is moot.
> 
> There are things I can change and things I can't change. And in this
> case entering a password for sudo a bunch of times ends up being a
> recurring theme at $WORK. But *next* time the current problem comes
> up (which it does from time to time), now at least I have a prepared
> script to deal with it on all of the machines.
> 
> Of course, a problem other than the current one is another matter.
> 
> Elijah
> ------
> can leverage ssh keys only for getting onto the machines

Is it a case where you are doing the same function on the machines, 
just repeating it across multiple machines?

If so, could you leverage 'expect' 
(https://core.tcl-lang.org/expect/index) to handle the login, entry of 
password to sudo, and execution of the various steps.

But if it is a matter of "one offs" everywhere, then this is a much 
less useful suggestion.  Although even then, you could leverage expect 
to do, in effect:

  ssh machine_a
  sudo /bin/bash
     (entry of password)

and now you can have an interactive shell interface at your local 
terminal, that is connected to and already "su'ed" to the proper user 
remotely.  (this does assume the machines have not been configured to 
disallow a "sudo /bin/bash" to get a shell with the alternate 
permissions launched.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web