Point taken, the intention is to make each command more succinct and we overloaded the functionality of `kr add` to do so.

`kr add` will add your public key if no members are specified. The user being modified is whichever is being logged into. So if you have an ssh alias "bastion" that specifies user "jump" in your SSH config, `kr add bastion` adds your public key to user "jump". Just like when SSHing into a server, you can override the default user in the form `kr add user@bastion`.

This is only the first iteration of `kr add`, and we will be adding more advanced access control in the near future, including authenticating as one user but modifying another.

Totally agree with 3., we'll add this to our roadmap.

Thanks!

Problem with `kr add user@bastion` is that you as `user1` won't normally have access to ssh as `user2`, but "authenticating as one user but modifying another" would work of course. Maybe add a option for team-members to save their username for servers, then mass-add would be easy :)