Add SSH key before deploying OS image?

wankel

Hi all,

Some VPS admin interfaces offer to insert an SSH key on the deployment page.

I figured I'd paste my public key here, to be able to log in afterwards.

So far, I have never been able to do so. Switching to password login and uploading my key manually, it does work.

I don't know the names of the different admin options; today I ran into the problem on Abdullah's Webhorizon in NL. After deployment, there is an entry for SSH keys, but I can't log in with keys:

screenshot of admin interface (sorry, my image embedding-fu is flaky).

Besides, there is a 'sharing' option, with an acces--token box.

Picture of 'sharing' tab with 'grant access' button

Other than asking around, is there a generic way to figure out which admin interface a VPS provider is running?

Neoon

nevermind, didn't read fully.

skhron

WebHorizon uses VirtFusion, and there is no issues with SSH public key functionality. Are you sure you have copied the right thing?

Jab

Maybe it's like a line end or some crazy tab-space-white char at the end/start and it's getting copied/not depending where/how you paste it?
What does the ssh logs says if you try to use that deployment page?
Turn on the debug logs in ssh(d) and see if that logs any complains about the key.

yusra

@wankel said: I ran into the problem on Abdullah's Webhorizon in NL

I have multiple services from them and that functionality works fine.
I guess you are pasting a malformed SSH key.

wankel

Hi, thanks for your suggestions!

@skhron said: WebHorizon uses VirtFusion, and there is no issues with SSH public key functionality

@yusra said: I have multiple services from them and that functionality works fine.

By no means I intended to imply the functionality was broken. In various admin interfaces, I just never have been able to make use of it, so I am quite sure indeed that I misunderstand how it is supposed to work.

@Jab said: Maybe it's like a line end or some crazy tab-space-white char at the end/start and it's getting copied/not depending where/how you paste it?

Most probably, though I usually check the start and end to see they look the same. A space would go unnoticed at the end, but for the start of the string I usually use the home-button to check the cursor is at the first character.

What I do:

• cat ~/.ssh/id_rsa.pub (or id_ed25519.pub, depending on the case)
• It gives me ssh-rsa AAAAB3NzaC1....qP= username@host
• I put the AAAAB3NzaC1....qP= bit in the box reserved for the SSH key on the VPS admin page
• As user username I try to log in from host host over SSH to my VPS with root@vps (either domain or IP)
• SSH says : root@vps: Permission denied (publickey).

ssh -v shows that SSH is checking both keys,
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:pUgXalgQ...
....
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:3eYAz...
...

but neither of them is accepted.

-- edit, made a mess of markup

Jab

@wankel said: ssh -v shows that SSH is checking both keys,

server-side logs, not client side

Jab

@wankel said: It gives me ssh-rsa AAAAB3NzaC1....qP= username@host
I put the AAAAB3NzaC1....qP= bit in the box reserved for the SSH key on the VPS admin page

Wait, why did you dropped the ssh-rsa? You need that, so you should copy paste the whole thing/line, even with username@host which is a comment, not a username or host you connecting to/from.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if this option is not specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. Each line of the file contains one key (empty lines and lines starting with a ‘#’ are ignored as comments). Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. The options field is optional. The supported key types are:

[email protected]
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
ssh-ed25519
ssh-dss
ssh-rsa

AuroraZero

@Jab said:

@wankel said: It gives me ssh-rsa AAAAB3NzaC1....qP= username@host
I put the AAAAB3NzaC1....qP= bit in the box reserved for the SSH key on the VPS admin page

Wait, why did you dropped the ssh-rsa? You need that, so you should copy paste the whole thing/line, even with username@host which is a comment, not a username or host you connecting to/from.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if this option is not specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. Each line of the file contains one key (empty lines and lines starting with a ‘#’ are ignored as comments). Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. The options field is optional. The supported key types are:

[email protected]
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
ssh-ed25519
ssh-dss
ssh-rsa

Exactly needs to know what kind of key it is

wankel

@Jab said:

@wankel said: ssh -v shows that SSH is checking both keys,

server-side logs, not client side

Ah, yes... Those started to look up after logging in with a password, but it turns out I'm not able to reset the root password, since on deployment I disabled password logins for this instance :-P

The VirtFusion does seem to offer enable/disable password logins on deployment, and to reset passwords on an instance that has passwords disabled, only to come up with a 'task was doomed' notification on password reset.

@AuroraZero said:

@Jab said:

@wankel said: It gives me ssh-rsa AAAAB3NzaC1....qP= username@host
I put the AAAAB3NzaC1....qP= bit in the box reserved for the SSH key on the VPS admin page

Wait, why did you dropped the ssh-rsa? You need that, so you should copy paste the whole thing/line, even with username@host which is a comment, not a username or host you connecting to/from.

Exactly needs to know what kind of key it is

Ah, that explains: I thought the algorithm was encoded in the first characters of the key string. Yes, I dropped those bits.

After trying that as well (copying the whole line and checking for copy/paste errors) for the RSA key as well as for the ED25519 key, I let the system generate me a new keypair. I put the (full) generated text (--- BEGIN .... END etc--) in the corresponding key file in the users' ssh directory. Still no go.

I'll redeploy the image (bog standard Debian 12), this time with a correct string for the key and password login enabled, so I can check what's happening at the server's end.

I'll come back to post the results. If you got a tip beforehand, let me know ;-)

wankel

Two observations that escaped my attention before:

• when adding your own key, only the RSA 2048 bits can be 'chosen'. My rsa key might be 4092 bits.
• enabling key logins disables password logins; it is either/or, not and/and

I went with a new keypair, waited a full 30 seconds for the server to install, and... Bingo! It works :-)

I'm not looking forward to resetting/recreating private keys every once in a while I deploy a server, so I'm on my way destroying this installation and retrying with my own public key.

wankel

OK, great! It works :-)

I reinstalled, and gave the whole line to the public key field in the admin interface.

Thank you all for your patience and guidance. For the next time I'll remember: copy the full public key line

balloon

This has already been resolved,,,

but in another case, older versions of ssh clients and newer OSes may cause login attempts using public keys to fail. For example: Tera Term 4.106 and earlier. Recently improved Tera Term 4.107 and TeraTerm 5.0 has been released.