By default, AWS CLI version 2 returns all timestamp response values in the ISO 8601 format. In AWS
CLI version 1, commands returned timestamp values in whatever format was returned by the HTTP API
response, which could vary from service to service.

Allow longer sessions than 12 hours - many of us work longer than 12 hours. This only requires 2 changes:

•                                   local expiry_s=$(expr $(date -r $f '+%s') + 43200 )
  

•                                   local expiry_s=$(expr $(date -r $f '+%s') + $MY_EXPIRY )
  

•                   local JSON=$(aws --output json --profile $AWS_PROFILE sts get-session-token --serial-number=$AWS_SERIAL --token-code $MFA )
  

•                   local JSON=$(aws --output json --profile $AWS_PROFILE sts get-session-token --serial-number=$AWS_SERIAL --duration-seconds= $MY_EXPIRY --token-code $MFA )
  

• some code to allow this to be saved etc,

If you have a working session and do a "get_session -d", your current session becomes corrupted and has to be restored from file.

I suggest that instead of having it as a option, we download the file (or check for updates) every time you refresh your session to ensure that you always have an up-to-date list of roles to be assumed.

When doing an import, session tool try to delete the command from the shell history.

This is not supported in zsh. The "history -d " command will just display the line number from the history file.

There does not seem to be any way to actually delete a history line from within a running zsh.

Maybe just do not execute the "history -d" command on zsh?

alk@alk-mbp - ~: get_session -s #######
Failed conversion of 2020-01-06T07:39:27+00:00'' using format %Y-%m-%dT%H:%M:%SZ''
date: illegal time format
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: option requires an argument -- r
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
expr: syntax error
date: option requires an argument -- r
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
expr: syntax error
date: option requires an argument -- r
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
-bash: [: : integer expression expected
Failed conversion of 2020-02-15T21:23:43+00:00'' using format %Y-%m-%dT%H:%M:%SZ''
date: illegal time format
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: option requires an argument -- r
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

I want to query session tool doing something like this:

$ get_session -q
Active profile: awsops
Expiration: 23:05:17

Or if the session is switched to a role:

$ get_session -q
Active profile: awsops
Expiration: 23:05:17
Role: bf-awsopslab-admin
Role expiration: 10:23:05

Today we only have the '-v' option, and that only returns true/false for the validity of the session and the '-l' option that will list stored sessions.

On some systems the check fails when doing sudo:
[[ ps -fp $$ | grep $$ =~ "bash" ]] || echo >&2 "ERROR: SHELL is not bash. session_tools will not work."

The quickest way to fix this this is to replace with:
[[ ! -n "$BASH" ] ] || echo >&2 "ERROR: SHELL is not bash. session_tools will not work."

Or just:
if [ ! -n "$BASH" ] ;then echo >&2 "ERROR: SHELL is not bash. session_tools will not work."; fi

When using session tool it would be very helpful if the shell prompt could be altered to show information about current session. Like what profile you are currently using, if the session is with the bastion account or with an assumed role, and possibly also expiration status.

The use of such modifications to the prompt should be optional and default to off. To avoid intrusive changes to peoples existing prompt modifications. One possible way of handling that would be an aws configuration setting.

Using session tool I have my default profile in ~/.aws/config set to use the profile awsops.
When authenticating with session tool and assuming a role, I am able to use the privileges of the role, by using the default profile, however, when I use the --profile option in the awscli to set the profile explicitly, the profile fails.

I noticed that in the ~/.aws/credentials file the credentials for the default profile and the awsops profiles do not match, given that the default profile is the awsops profile, these credential entries should be identical and updated at the same time.

When using 'rotate_credentials -n -p awsops' only the awsops profile is updated, not the default profile.

I can easily reproduce the failure with a simple test.
Assume role for ka2-awspreprod-admin
At the CLI run the following commands:
aws s3 ls
aws s3 ls --profile awsops
When using --profile the command fails to list buckets.

I am using the zsh branch of session tool, the issue occurs under both zsh and bash shells on my mac.

aws --version
aws-cli/1.17.0 Python/3.8.1 Darwin/19.2.0 botocore/1.14.0

aws-cli/2.0.0 Python/3.8.1 Darwin/19.3.0 botocore/2.0.0dev4

Check if osrelease contains microsoft and if true open the correct chrome app from C:\program files...

Last login: Wed Jun 20 11:31:39 on ttys002
-bash: timeout: command not found
alk-mbp:~ alk$

Issue when loading aws-session-tool with zsh on mac

complete:13: command not found: compdef
complete:13: command not found: compdef
complete:13: command not found: compdef
complete:13: command not found: compdef

https://itectec.com/askdifferent/macos-my-command-line-says-complete13-command-not-found-compdef/

autoload -Uz compinit
compinit

Seems to fix it, can be added to the install guides.

In the _prereq function, there is an OSTYPE check based on the openssl location. A case for Git Bash can be added such that it will work on Windows:

	case $OSTYPE in
		darwin*	) _OPENSSL="/usr/bin/openssl";;
		msys* ) _OPENSSL="/mingw64/bin/openssl";;
		linux* | cygwin* ) _OPENSSL="openssl";;
		*) [[ $- =~ i ]] && echo >&2 "ERROR: Unknown ostype: $OSTYPE" ;;
	esac

It seems there is some inconsistency in how the assume_role functionality works, depending on what permissions are set:

With the bf-awsopslab-admin role, I am able to run get_console_url successfully as follows:

[daven@bf-awsops-admin01 test]$ get_session -f -s XXXXXX
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
[daven@bf-awsops-admin01 test]$ assume_role bf-awsopslab-admin
[daven@bf-awsops-admin01 test]$ get_console_url 
https://signin.aws.amazon.com/federation?Action=login&Issuer=&Destination=redacted

However, when performing the exact same steps with the rut-awsprod-readonly role, I experience a failure:

[daven@bf-awsops-admin01 test]$ get_session -f -s XXXXXX
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
[daven@bf-awsops-admin01 test]$ assume_role rut-awsprod-readonly
[daven@bf-awsops-admin01 test]$ get_console_url 

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::905279427843:assumed-role/readonly/rut-awsprod is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::905279427843:role/readonly
ERROR: Unable to obtain session

A workaround as follows has been illustrated by @bentterp :

[daven@bf-awsops-admin01 test]$ get_session -s -p awsops XXXXXX
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
[daven@bf-awsops-admin01 test]$ assume_role rut-awsprod-readonly
[daven@bf-awsops-admin01 test]$ get_session -r -p awsops 
enter aes-256-cbc decryption password:
[daven@bf-awsops-admin01 test]$ get_console_url 
https://signin.aws.amazon.com/federation?Action=login&Issuer=&Destination=redacted

bent@BFW-4M5KM72:~$ rotate_credentials -n -p awsops
WARNING: This user already has two sets of access keys. If you wish to rotate both sets, please use the -t flag - but be aware, that the second set of keys will be displayed here on the screen. More information in the wiki.
bent@BFW-4M5KM72:~$ get_session -c
bent@BFW-4M5KM72:~$ get_session -s 684545
WARNING: Your API key is older than 60 days.

The way this warning is written, I would expect that the credentials in the profile be rotated and the other set left alone. But it seems that nothing is changed.

When opening a new terminal, it sources the session-tool.sh automatically (since it's in my profile).
The session-tool then checks if there is a newer version available, and prints this:
WARN: Your version is outdated! You have 1.4.2, the latest is

There should be an indication that it is actually session tool that prints this error, right now it can be any program that loads when you open a terminal window.

(Also, the "the latest is" is just empty, which i guess is a bug).

When session_tool_default_profile is set to different profile than running session, s3 get fails during the download.

Example:

An error occurred (AccessDenied) when calling the CreateAccessKey operation: User: arn:aws:iam::115071183626:user/hmelby is not authorized to perform: iam:CreateAccessKey on resource: user nullhmelby with an explicit deny in an identity-based policy
Expecting value: line 2 column 1 (char 1)
Expecting value: line 2 column 1 (char 1)
ERROR: Unable to create valid credentials for profile awsops, unsafe to continue

This error was because the user lacked the iam:CreateAccessKey action in the policy.

If the user is missing iam:ListAccessKeys, the error is much “bigger” and gives the impression that we do not care about results and error checking.

At least all AWS CLI commands should be checked. Probably will not work to create a wrapper function for it, as we can not do exit in session tool, because that will exit the user from the current shell.

Customer request: apparently, session-tool does not work with zsh

When users get emails about credientials close to expiring, there should be a smart way of rotating credentials. And smart is to build that into session-tool.

alk@alk-mbp - ~: get_session -r
enter aes-256-cbc decryption password:
ERROR: You do not seem to have a valid session in your environment.
alk@alk-mbp - ~:

If I start a terminal window without a working/slow internet connection i guess it will trying to check for a new version and it will time out after some time.
The feedback is then:
"WARN: Your version of session-tool is outdated! You have 1.4.6, the latest is "

Two things
1: I have to wait for the connection to time out before the terminal window opens (takes time to open the terminal)
2: I have the latest version

OK - I guess this is not big issue - usually you have a working Internet connection. But I'm commuting with NSB and there the connectivity is at best very limited.

a small cosmetic thing...

Using zsh
TL;DR

# Verifying new key: 1usage: sleep seconds
2usage: sleep seconds
3usage: sleep seconds
4usage: sleep seconds
5usage: sleep seconds
6usage: sleep seconds
7usage: sleep seconds
Done [8]

I swapped from the old bf_aws_tools to aws-session-tool
After the first time I ran it then logged back in it seems it has a slight amount of amnesia.

workhorse ~ # su - aws-ops
ERROR: SHELL is not bash. session_tools will not work.
aws-ops@workhorse ~ $ bash
aws-ops@workhorse ~ $ get_session -s xxxxxxxx
ERROR: No profile specified and no default profile configured.

*** first one.. not remembering the cached session,

aws-ops@workhorse ~ $ get_session -p default -s xxxxxxx
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

aws-ops@workhorse ~ $ get_console_url far-awsprod-admin
ERROR: Neither ~/.aws/default_session-tool_roles.cfg nor ~/.aws/default_roles.cfg found, please run get_session -d or create ~/.aws/default_roles.cfg

Then it does not know the roles anymore.

aws-ops@workhorse ~ $ get_session -l
awsops 02:15:32 2017-11-25 (EXPIRED)
default 10:20:43 2017-11-27

aws-ops@workhorse ~ $ get_console_url -l
ERROR: Neither ~/.aws/default_session-tool_roles.cfg nor ~/.aws/default_roles.cfg found, please run get_session -d or create ~/.aws/default_roles.cfg

aws-ops@workhorse ~ $ get_session -d
ERROR: No bucket configure to download roles from. Please configure with: aws configure set session-tool_bucketname --profile default

looking in the old session tools I found a bucket - hope thats the one we should be using ;)

aws-ops@workhorse ~ $ aws configure set session-tool_bucketname XX-XXX-XXX-XXXXX-tool --profile default
aws-ops@workhorse ~ $ get_session -d

Warning: you did not input an MFA token. Proceed at your own risk.

aws-ops@workhorse ~ $ get_session -d -s XXXXXXX
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

And then it works ;)

If the user does not have terraform installed anywhere available in the PATH, loading session tool will issue the warning:

Terraform is not installed

It will work as expected, but annoying with the message every time you start a shell.

fsa@square:~/.aws$ get_session -d
# Warning: you did not input an MFA token. Proceed at your own risk.

fsa@square:~/.aws$ get_session -u
upload: ./awsops_session-tool_roles.cfg to s3://bf-aws-tools-session-tool/session-tool_roles.cfg
# Warning: you did not input an MFA token. Proceed at your own risk.

As the MFA is not required in this case as I already have a valid session, I don't see why I get a warning after a successful download/upload. I recommend removing these confusing warnings.

On some lines you use the openssl command directly, on other you used the $_OPENSSL variable. This may lead to unexpected behavior.