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

[solsglasses]

I think that this issue https://github.com/99designs/aws-vault/issues/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.

[lox]

Could you tell us a bit more about your config? Are you assuming a role, or just using creds? Does your profile have MFA?

At a minimum you will have your root credentials in your keychain and a session, so if you aren't ticking "Don't ask me again" you should expect 2 prompts and then 1 prompt.

Are you running an official build? If so, what version?

[solsglasses]

Could you tell us a bit more about your config?

Absolutely, I am at your disposal, ask me anything you need to know

Are you assuming a role, or just using creds?

Yes I originally experienced this problem (and decided to create this github issue) while I was assuming a role. I almost never authenticate directly as my root IAM user/readonly user. I always use roles.

Does your profile have MFA?

I am not using MFA

Are you running an official build? If so, what version?

Installed via brew:

$ aws-vault --version
v4.2.0

[solsglasses]

Hey @lox and team, I want to help, is there any other questions I can answer/things I can try out?

[conzy]

If its any help I experience the same thing on OSX Sierra. Brew version aws-vault --version v4.2.0

[tomquisel]

I have the same issue, same version as the last poster. I use an assumed role, but actually not for the profile that has an issue. It's a vanilla profile with no MFA or roles.

[stevencarpenter]

I am also experiencing this issue. I am running on mac 10.13.3. It is very frustrating to get repeatedly asked when assuming a role. I am running aws-vault 4.2.0. I am using MFA.

[lox]

How many times are you prompted for a single usage? Both on the first time you use it (which creates and stores a session) and then for when you are using the session?

Use something like aws-vault --debug exec <profile> -- aws s3 ls to test.

[stevencarpenter]

One time for a single run of the command you provided, and then if I run it again right after I have to authenticate again. Occasionally I will auth once and the keychain password will be asked for, then I will be asked to auth again in the same command, but this time it will have an Always Accept option. Despite clicking that, I will be asked to re-auth again in like 5 minutes.

[lox]

I believe the default timeout of the keychain vault we create is 5 minutes. So you should be re-prompted for your Keychain password every five minutes.

[lox]

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

[FernandoMiguel]

hugops @lox

[stevencarpenter]

Is there a way I can make that a little longer?

[lox]

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.

[talbright]

Hrmm:

ls ~/Library/Keychains/aws-vault.keychain                                                                                               Thu Mar 29 21:00:34 2018
ls: /Users/{user}/Library/Keychains/aws-vault.keychain: No such file or directory

[FernandoMiguel]

@talbright you are probably using the login key chain

[irgeek]

I think there are multiple issues happening here -- there are several things that cause OS X to prompt for the keychain password. Below are three that I've encountered. There are probably others.

Keychain locked

If a keychain is locked, the password is needed to unlock it. The prompt for this (on High Sierra) has "OK" and "Cancel" buttons and reads like this:

<application> wants to use the "<keychain>" keychain.
Please enter the keychain password.

If you're seeing this prompt repeatedly, using the login keychain and/or increasing the lock timeout will probably help.

Application access to a specific keychain

Applications need to be given permission to access each _keychain_ separately. The prompt for this has "Allow", "Deny" and "Always Allow" buttons and reads like this:

<application> wants to access key "<item description>" in your keychain.
To allow this, enter the "<keychain>" keychain password.

Assuming you click "Always Allow" on this one, you shouldn't be seeing it often. It should appear again with the aws-vault binary changes, but otherwise it should be infrequent.

Application access to a specific item in a keychain

As well as being granted access to a keychain, applications must also be granted access to each _item_ within the keychain before they can access the actual password data. The prompt for this has "Allow", "Deny" and "Always Allow" buttons and reads like this:

<application> wants to use your confidential information stored in <item label>
 in your keychain.
To allow this, enter the "<keychain>" keychain password.

When you click "Always Allow" here the application being authorised with appear in the list of applications on the "Access Control" tab of the item information window in Keychain Access. This one, I think, is where the issue comes from for many people.

I did a bit of digging and found this:

https://github.com/99designs/keyring/blob/ccd0779e6f10beb398c339c6fe4557e709dbf40c/keychain.go#L109-L121

    if isTrusted {
        debugf("Keychain item trusts aws-vault")
        kcItem.SetAccess(&gokeychain.Access{
            Label:               item.Label,
            TrustedApplications: nil,
        })
    } else {
        debugf("Keychain item doesn't trust aws-vault")
        kcItem.SetAccess(&gokeychain.Access{
            Label:               item.Label,
            TrustedApplications: []string{},
        })
    }

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 <profile> 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.

Does that shed some light on what may be going on here?

[arkadiyt]

Also constantly getting re-prompted for keychain access, even after clicking "always allow", regardless of if I use the default aws-vault keychain or my login keychain. I am using 2fa if it makes a difference.

[lox]

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?

[eddieramirez]

Can we make KeychainNotTrustApplication an optional setting one could disable? I utilize multiple roles during some sessions (>10), so repeatedly typing in my password is more of a security risk than the implicit risk of an unlocked keychain. I'm also spoiled because I have a touch bar mac, so typing in passwords seems so barbaric nowadays.

[irgeek]

I like that I can opt-in to certain sessions not needing re-prompting

While it's true that we can already opt-in, the only option now is per-session opt-in. I'd really like to be able to have per-profile opt-in as well.

At the moment, the only way I can live with aws-vault is to use very long (12 hour) session TTLs. For me, inputting passwords is something that has a high likelihood of interrupting my thought process and breaking my flow. I'd much prefer to use 15 minute sessions, but I just can't deal with the hit to my productivity.

[lox]

@irgeek I hear ya! It's something we would absolutely consider adding. I prefer the idea of short-lived sessions that are automatically trusted to long-lived sessions too.

[johnlinvc]

The keychain location in my newly installed high Sierra is ~/Library/Keychains/aws-vault.keychain-db

[segevfiner]

I don't understand what kind of security benefit could there be for the keychain not to trust the very same application that added the key. Especially since the user is more than likely going to hit "Always Allow" which will add this trust anyhow.

I think that if KeychainNotTrustApplication is simply set to false (The line removed), than the key will be created with trust only on aws-vault. Which I believe is the desired behavior.

[lox]

Especially since the user is more than likely going to hit "Always Allow" which will add this trust anyhow.

@segevfiner that is entirely up to the user. For instance, I don't always allow for access to my root keys, but I do for sessions. The whole point is to prevent drive-by emptying of credentials from the keychain.

[segevfiner]

Especially since the user is more than likely going to hit "Always Allow" which will add this trust anyhow.

@segevfiner that is entirely up to the user. For instance, I don't always allow for access to my root keys, but I do for sessions. The whole point is to prevent drive-by emptying of credentials from the keychain.

I see... So I guess the right thing is to make this configurable? Perhaps there should be a separate setting for the secret key and the session keys for this.

[lox]

Yes, I think having it configurable makes a lot of sense @segevfiner. I'd be fine defaulting sessions to not prompting too.

[StevenACoffman]

@solsglasses Please see if the new v4.5.0 release resolves your issue. On mac, installed with homebrew, brew cask upgrade aws-vault should update to this release.

[acdha]

4.5.1 appears to have fixed this problem for me

[solsglasses]

@solsglasses Please see if the new v4.5.0 release resolves your issue. On mac, installed with homebrew, brew cask upgrade aws-vault should update to this release.

Excellent, thank you. I upgraded to v4.5.1 just now. I'll let you know what I find.

[madsem]

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.

@lox would you mind telling me how? I'm looking into this myself atm, but it doesn't seem possible to sync the login keychain with iCloud from what I've read so far. Documentation also doesn't say anything about how to do that.

[mtibben]

@madsem AWS_VAULT_KEYCHAIN_NAME=login

[madsem]

Thanks @mtibben :) but that’s why I was asking, the login keychain isn’t synced via iCloud.
Not by default, so when @lox said that I was curious how to, as that would be very convenient

[romanr]

Having this issue in 4.7.1 asks for password after 15 minutes

[ruionwriting]

Having this issue in 4.7.1 asks for password after 15 minutes

Same here.

[bleachbyte]

10 minutes, in my case!

[mtibben]

Resolved in v5

[Sytten]

How was this fixed? I still need to enter the password every 10m or so :S

[mtibben]

Hey @Sytten a bunch of these issues were fixed in the refactoring in the v5 release. If you're experiencing problems with v5 it will be new - can you open a new issue?