project ssh keys: work around 404 bug

[grahamc]

When creating a project's SSH key with a project's API key, the SSH
key gets created but the response is a 404.

This patch works around that issue and allows the code to continue.

Upstreamed from input-output-hk@4baec99

Note the backstory of this PR is in customer issue TUVD-0107-UIKB.

[mmlb]

I think you can say nope and give it only public ones right, somehow? I don't think drone is able to ask for less perms in this old version. Might move this over to cloud.drone.io actually.

[mmlb]

fyi failed due to lint

[mmlb]

I'm checking with api folks about the 404 though, don't really want to merge in this hack.

[grahamc]

Just a follow-up comment on the issue here, because I misremembered.

Right now, a project's API token gets a 404 while creating an SSH key:

>>> x =  requests.post(url='https://api.packet.net/projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys', headers = { "X-Auth-Token": os.environ['PACKET_ACCESS_KEY'], "Content-Type": "application/json" }, data=json.dumps({"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL/w0nE8ezh9UX88pT3BLtn9Sx2dFZcDSR1+tv4oBjSj", "label": "grahamc-test"}))
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.packet.net:443
DEBUG:urllib3.connectionpool:https://api.packet.net:443 "POST /projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys HTTP/1.1" 404 24

interestingly, it does work: the key is created. But, the reply is still a 404. I then deleted the key from the UI.

I also tested with curl:

$ curl -v --header "Content-Type: application/json" --header "X-Auth-Token: $PACKET_ACCESS_KEY" --data '{"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL/w0nE8ezh9UX88pT3BLtn9Sx2dFZcDSR1+tv4oBjSj", "label": "grahamc-test"}' https://api.packet.net/projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys; echo
*   Trying 104.18.159.21:443...
* TCP_NODELAY set
* Connected to api.packet.net (104.18.159.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.packet.net
*  start date: Nov  1 00:00:00 2018 GMT
*  expire date: Oct 31 23:59:59 2020 GMT
*  subjectAltName: host "api.packet.net" matched cert's "*.packet.net"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x14ddbd0)
> POST /projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys HTTP/2
> Host: api.packet.net
> user-agent: curl/7.68.0
> accept: */*
> content-type: application/json
> x-auth-token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> content-length: 116
>
* We are completely uploaded and fine
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 404
< date: Mon, 22 Jun 2020 18:15:26 GMT
< content-type: application/json; charset=utf-8
< content-length: 24
< set-cookie: __cfduid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; expires=Wed, 22-Jul-20 18:15:26 GMT; path=/; domain=.packet.net; HttpOnly; SameSite=Lax; Secure
< cache-control: no-cache
< vary: Origin
< x-request-id: ed9fe361-7e73-4425-9fca-6eb7390bfce9
< cf-cache-status: DYNAMIC
< cf-request-id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-EWR
<
* Connection #0 to host api.packet.net left intact
{"errors":["Not found"]}

running this request a second time returns a 422 and {"errors":["Key already exists"]}.

I confirmed that the Packet API team still has a ticket open to fix this issue. One option (sigh) could be catching the 404 and then querying to see if the key is listed?

[grahamc]

DEBUG:packet.baseapi:POST https://api.packet.net/projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys {'key': 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL/w0nE8ezh9UX88pT3BLtn9Sx2dFZcDSR1+tv4oBjSj', 'label': 'grahamc-test'} {'X-Auth-Token': 'TOKEN', 'X-Consumer-Token': None, 'Content-Type': 'application/json'}
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.packet.net:443
DEBUG:urllib3.connectionpool:https://api.packet.net:443 "POST /projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys HTTP/1.1" 404 24
DEBUG:packet.baseapi:POST https://api.packet.net/projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys {'key': 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL/w0nE8ezh9UX88pT3BLtn9Sx2dFZcDSR1+tv4oBjSj', 'label': 'grahamc-test'} {'X-Auth-Token': 'TOKEN', 'X-Consumer-Token': None, 'Content-Type': 'application/json'}
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.packet.net:443
DEBUG:urllib3.connectionpool:https://api.packet.net:443 "POST /projects/86d5d066-b891-4608-af55-a481aa2c0094/ssh-keys HTTP/1.1" 422 33
DEBUG:packet.baseapi:GET https://api.packet.net/ssh-keys {} {'X-Auth-Token': 'TOKEN', 'X-Consumer-Token': None, 'Content-Type': 'application/json'}
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.packet.net:443
DEBUG:urllib3.connectionpool:https://api.packet.net:443 "GET /ssh-keys HTTP/1.1" 200 None
SSHKey: 3088ab9e-af4d-4f5a-b301-94d90384b2f9

w00t

[mmlb]

Nicely done!