What significance does the user/host at the end of an SSH public key file hold?

Question

I can’t figure out why does an SSH public key file generated by ssh-keygen have a user and host at the end of it.

Example: id_rsa.pub

ssh-rsa ... rest of file ... /CA9gyE8HRhNMG6ZDwyhPBbDfX root@mydomain

Notice the root@mydomain at the end of the file.

If I can use the public key anywhere with any user to authenticate using my private key, what significance does the root@mydomain have on the authentication process?

Or is it just a place holder to figure our who was it issued by?

Solution 1

This field is a comment, and can be changed or ignored at will. It is set to user@host by default by ssh-keygen.

The OpenSSH sshd(8) man page describes the format of a public key thus:

Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. . . . The comment field is not used for anything (but may be convenient for the user to identify the key).

The ssh-keygen(1) man page says:

The key comment may be useful to help identify the key. The comment is initialized to “user@host” when the key is created, but can be changed using the -c option.

Solution 2

This is briefly explained in manual page for sshd(8) in section about authorized keys:

Protocol 2 public key consist of: options, keytype, base64-encoded key, comment.

In openssh context of authorized keys, there is only meaning of comment. But there are SSH implementation, that give the meanings to this part, as for example SSH implementation in LANCOM modems is using this comment as a username for which the key is valid.

Solution 3

As others have pointed out, it's a comment to allow you to identify which key is which.

When looking at a single key in eg id_rsa.pub it doesn't make a great deal of difference but when looking at a potentially long list of keys, such as what you have in the authorized_keys file, it is very helpful to be able to easily identify which key is which.

Also, ssh-keygen's default is user@hostname, which for typical use-cases is a clear identifier of which key it is (user@domain would not be).

Solution 4

Very, very simple: Me and you are humans using a machine. So looking at this example you posted:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX root@mydomain

A machine can read this:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX

A human can read this comment:

root@mydomain

People tend to forget that even though things might look complicated on computer systems, they could actually be tons more complicated if the code was designed only for machine consumption. I mean look at obscured malware code. Once you decode it and format it, it’s human readable. But someone had to go out of their way to make it hard for humans to read.

By default all types of coding and configuration files on a computer system are structure for human consumption because… We are humans using machines and machines don’t need things like:

• Comments.
• Indentations.
• Variables and functions written in a human readable language.

So the comment is meant for you and me and nobody else. It would most likely work without a comment. But that one time something is not working at 3:00am and you are hunting for the right public key, you’re going to wish/dream/pray the comment is there.

View more solutions

Comments

[chicks]

I've seen some overzealous webforms that require the comment field include an @ symbol, but there isn't any technical reason for this.

[mgarciaisaia]

+1 for quoting the man

[Basil A]

Brief and to the point. Being able to change the comment at will solved the puzzle for me. I thought it had some kind of role in the ssh authentication process.

[Michael Hampton]

@BasilA I have some keys where I have removed it entirely.

[user]

"machines don’t need things like ... Indentations" cough Python cough

[hBy2Py]

@MichaelKjörling "... unless they are made to care about them." :-)

[hBy2Py]

When setting up SSH key login to an instance on Google Cloud Compute, GCC uses this comment field to identify the user name on the instance with which the key is to be associated.