Change Details

I would like to add a `/auth/sshkeys/<USER HANDLE or PHID-USER>` route which provides all active SSH public keys of a certain user in plain-text (in the format as the same as `~/ssh/authorized_keys`). As all SSH keys are public (`/auth/sshkey/for/<PHID-USER>`), it should be safe to do so in another response format. The use case are: make exchanging SSH pubkeys easier (`curl -o authorized_keys`, etc.) (especially for automated tools) because the existing Conduit API requires authentication but this does not.

I would like to add a `/auth/sshkeys/<USER HANDLE or PHID-USER>` route which provides all active SSH public keys of a certain user in plain-text (in the format as the same as `~/ssh/authorized_keys`). As all SSH keys are public (`/auth/sshkey/for/<PHID-USER>`), it should be safe to do so in another response format. The use case are: make exchanging SSH pubkeys easier (`curl -o authorized_keys`, etc.) (especially for automated tools) because the existing Conduit API requires authentication but this does not. Any questions or objections?

I would like to add a `/auth/sshkeys/<USER HANDLE or PHID-USER>` route which provides all active SSH public keys of a certain user in plain-text (in the format as the same as `~/ssh/authorized_keys`). As all SSH keys are public (`/auth/sshkey/for/<PHID-USER>`), it should be safe to do so in another response format. The use case are: make exchanging SSH pubkeys easier (`curl -o authorized_keys`, etc.) (especially for automated tools) because the existing Conduit API requires authentication but this does not. Any questions or objections?