Is it Possible to Use ED25519 Instead of RSA When Logging Into a Remote App Engine Instance?

Question

When a Google Cloud SDK (gcloud) user executes:

gcloud app instances ssh \
$AEF_INSTANCE_ID \
--project $GCP_PROJECT_NAME \
--service $AEF_APP_SERVICE_NAME \
--version $AEF_APP_VERSION_NAME

#=>

WARNING: The private SSH key file for gcloud does not exist.
WARNING: The public SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Generating public/private rsa key pair.
. . .

for the first time, an RSA key is generated:

ls -1 ~/.ssh/google_compute_*

#=>

google_compute_engine
google_compute_engine.pub
google_compute_known_hosts

Is it possible at this time to use ED25519 instead of RSA?

Answer 1

No.

At this time, it is not possible to use an ED25519-based key instead of an RSA-based key when logging into a running App Engine Flexible Environment (AEF) instance.

In other words, if you were to:

1. delete the old RSA key:

   rm ~/.ssh/google_compute_*
   

2. generate an ED25519 key:

   ssh-keygen -t ed25519 -C "$(whoami)@$(hostname)
   
   #=>
   
   Generating public/private ed25519 key pair.
   . . .
   

   Note: use an absolute path when prompted for a key file name and location; using a relative path returns the following error:

   Saving key "~/.ssh/google_compute_engine" failed: No such file or directory

3. and attempt to log into a running App Engine Flexible Environment (AEF) instance:

   gcloud app instances ssh \
   $AEF_APP_INSTANCE_ID \
   --project $GCP_PROJECT_NAME \
   --service $AEF_APP_SERVICE_NAME \
   --version $AEF_APP_VERSION_NAME
   

you will get the following error:

ERROR: (gcloud.app.instances.ssh) INVALID_ARGUMENT: Invalid SSH key "$(whoami):ssh-ed25519 $ED25519_PUBLIC_KEY $(whoami)". Expected "[USERNAME]:ssh-rsa [KEY_VALUE] [USERNAME]" or [USERNAME]:ssh-rsa [KEY_VALUE] google-ssh {"userName":"[USERNAME]","expireOn":"[EXPIRE_TIME]"}.

If expiration time is being specified, please refer to RFC3339 for correct format.

However, you can find an active feature request for this here.