Solvedaws vault Constantly have to re-enter keychain password, part 2

I think that this issue #211 is still happening. That issue was closed after it was believed to be fixed, but myself and another person are reporting that we are still seeing the problem.

39 Answers

✔️Accepted Answer

lox
68

FML. Was testing this and accidentally entered rather than tabbed on rm -rf ~/Library/Keychains. Le sigh.

Other Answers:

lox
39

Yup, open the keychain file from ~/Library/Keychains/aws-vault.keychain and edit the timeout before it locks.

Alternately, I use my login keychain. I have AWS_VAULT_KEYCHAIN_NAME=login set in my env. It's timeout is much longer. The plan is for the login keychain to be the default in future.

lox
50

I'm by no means well versed in the OS X keychain subsystem, but it looks like the access control list for an item added with this library will always be empty. This means every time the aws-vault session for item is created -- and updates involve a delete/create cycle -- it is added with an empty access control list and aws-vault has to be authorised before it can be read again.

That is correct @irgeek. It's something @pda and I have debated a bit.

I've swapped to using the login keychain for all my creds, which avoids a lot of the password prompting for the actual keychain, so I rely on the password for access to the session. I like that I can opt-in to certain sessions not needing re-prompting, for instance if I'm doing something that will require a lot of repetitious aws-vault usage.

I'd really like to move to this model as a default for aws-vault. I think not having the separate keychain is a lot better for ergonomics and it gives us the option to synchronize credentials to Keychain in iCloud.

For those that are interested, I run aws-vault with the following env set in my shell:

AWS_VAULT_PROMPT=osascript
AWS_VAULT_KEYCHAIN_NAME=login

@pda / @mtibben where has your thinking landed on whether we move away from a dedicated keychain and use login?

More Issues: