As we announced, we've made some important changes to the way that API consumers manage SSH keys.
Finer-grained OAuth scopes
To help third party applications request only permissions that they need, the API now supports three new scopes for working with a user's public SSH keys.
read:public_keyprovides read access to the user's SSH keys
write:public_keyallows an app to read existing keys and create new ones
admin:public_keyenables an app to read, write, and delete keys
user scope has provided full access to manage a user's SSH keys. Now that we have dedicated scopes for managing a user's SSH keys, we have removed those permissions from the
user scope. Now
user scope will no longer provide access to SSH keys. Applications that need this access should request one of the new scopes described above.
Keys are now immutable
To simplify the security audit trail for SSH keys, we're making keys immutable. API consumers can continue to create keys and delete keys as needed, but keys can no longer be changed. To change an existing key, API consumers should delete the existing key and create a new one with the desired attributes. This change applies both to a user's SSH keys and a repository's deploy keys.
Deleting keys when revoking a token
Also any keys created via an OAuth token from this point forward will be deleted when that token is revoked.
As always, if you have any questions or feedback, please get in touch.