Client Specified ID

[shanjunmei]

Is there a way to specify the identifier of the client, so that when a large number of clients connect, we can easily know which one is who

[NHAS]

Yes. Its in the readme.

[shanjunmei]

Yes. Its in the readme.

Sorry for bothering again, I'm sure there is nothing about it in the readme. From the results of ls -t, the hostname and ip address cannot be changed, nor can they identify unique identities (because hosts connected from different subnets, these There may be duplicates), but the only remaining id, I read the source code, is also generated by the server receiving the connection, not passed by the client, is there a way to pass an additional ID when the client connects to the server As for the identifier, the goal I want to achieve is that this identifier is configured by the client, so that after connecting, wecan know who it is through this identifier

[NHAS]

Ah I see what you mean. I interpreted your question as "Can I use another identifier rather than the random id" instead of "can I specify my own ID for the client".

You are correct, currently there is no way of a client to specify a custom ID.

Small comment about: "nor can they identify unique identities (because hosts connected from different subnets, these There may be duplicates),"
Generally speaking, different computers should have different hostnames, and if they are connecting from different subnets I'd expect them to have differing IP addresses (unless they are behind a NAT).

However, I think your point is a valid one. Having a way of applying a custom label to a client would make specifying clients in scripts easier.

In your ideal world, how would you specify this ID?
As it does present some user experience problems if you wanted it compiled in, as then clients would have the same ID and we'd be back at this problem all over again.

[shanjunmei]

Ah I see what you mean. I interpreted your question as "Can I use another identifier rather than the random id" instead of "can I specify my own ID for the client".

You are correct, currently there is no way of a client to specify a custom ID.

Small comment about: "nor can they identify unique identities (because hosts connected from different subnets, these There may be duplicates)," Generally speaking, different computers should have different hostnames, and if they are connecting from different subnets I'd expect them to have differing IP addresses (unless they are behind a NAT).

However, I think your point is a valid one. Having a way of applying a custom label to a client would make specifying clients in scripts easier.

In your ideal world, how would you specify this ID? As it does present some user experience problems if you wanted it compiled in, as then clients would have the same ID and we'd be back at this problem all over again.

I think it can try to read from the configuration file. If it is not read, it will be randomly generated by the program, which should solve your worries and meet some of the requirement I mentioned earlier.

[NHAS]

I think it can try to read from the configuration file

Unfortunately I want this program to be as self contained as possible, so I'd be happier with a command line flag (such as --id) rather than reading from a file.

If it is not read, it will be randomly generated by the program...

Oh, if you only want something thats unique per client (not a custom label), then I can look at changing the ID to represent the public key instead. Which I was planning on doing anyway.

Thoughts?

[shanjunmei]

Oh, if you only want something thats unique per client (not a custom label), then I can look at changing the ID to represent the public key instead. Which I was planning on doing anyway.

Of course, the same is true for reading from command line parameters. Regarding your proposal, I am not sure if I understand it properly. My idea is to let the client pass an identifier to the server to facilitate the management of the server. As for the implementation method, it does not matter. . Having said that, changing the id seems to be a lot of work, and the real unique sign should always be issued by the server to ensure global uniqueness, and if it is pure standard ssh communication, it seems that an additional parameter is passed to establish the ssh connection The difficulty is not small. On the contrary, if the client sends the tag to the server through the current connection after the ssh connection is established, it will look more reliable and the implementation difficulty will be relatively reduced. If I am wrong, please ignore

[NHAS]

Of course, the same is true for reading from command line parameters.

Depends on how you're deploying the binary. Most cases are deploying the client as a single binary, sometimes onto systems they cant directly access, so if it was a custom tag then it'd have to be supplied by command line argument, or by being baked in at compile time.

My idea is to let the client pass an identifier to the server to facilitate the management of the server

Not sure what you mean by this. How does this help managing the server? I can understand it would help identify clients.

[NHAS]

I am gonna need a bit more feedback on how you plan to use this feature. Just going to implement it, I have kind of come to the conclusion that hostname should be sufficient for what you want?

[shanjunmei]

I am gonna need a bit more feedback on how you plan to use this feature. Just going to implement it, I have kind of come to the conclusion that hostname should be sufficient for what you want?

I'm going to build a system to manage remote clients that can go directly from the web to the target machine, so I need to set up aliases for each client, they may be from different subnets, have the same hostname, or even ip

[NHAS]

Right, so are you planning on recompiling the client per each target machine?
If so, I will add public key hash to the list of identifiers and that will solve you problem as that will then be unique per client.

[shanjunmei]

Right, so are you planning on recompiling the client per each target machine? If so, I will add public key hash to the list of identifiers and that will solve you problem as that will then be unique per client.

Can we try to get it from the command line parameters first, and if can't get it, then get the hash value of the public key?

[NHAS]

Its easier to use a hash of the public key. I've implemented this on the unstable branch. Please check it out and have a play around.

[shanjunmei]

Its easier to use a hash of the public key. I've implemented this on the unstable branch. Please check it out and have a play around.

So fast, I'll try it later, thanks

[NHAS]

This will have the limitation that you will need to compile a new client for every target machine, and make sure that the public is different for every client binary. This is trivial with the link command.

[shanjunmei]

This will have the limitation that you will need to compile a new client for every target machine, and make sure that the public is different for every client binary. This is trivial with the link command.

I thought of a question, there seems to be a logical bug here, if we need to generate a public key for each client, that means that the client and the server become one-to-one binding? The public and private keys are always generated in pairs

[NHAS]

I dont understand what you mean....

[shanjunmei]

I dont understand what you mean....

Both the public key and the private key are generated in pairs, and each compilation will generate a pair of public key and private key, which means that the newly compiled client cannot connect to the previously compiled server. .

[NHAS]

The servers private key is stored in the id_ed25519 file, this is generated on first execution of the server. This key does not change, nor is it compiled into the server.

The server maintains a list of client public keys to check if clients are allowed to connect.

I dont understand what you mean by "the newly compiled client cannot connect to the previously compiled server". You should try this, and see that the server (as long as the authorized_controllee_keys contains the client public key) will allow clients to connect.

The compilation only generates new client keys.

[shanjunmei]

The servers private key is stored in the id_ed25519 file, this is generated on first execution of the server. This key does not change, nor is it compiled into the server.

The server maintains a list of client public keys to check if clients are allowed to connect.

I dont understand what you mean by "the newly compiled client cannot connect to the previously compiled server". You should try this, and see that the server (as long as the authorized_controllee_keys contains the client public key) will allow clients to connect.

The compilation only generates new client keys.

emm . as you said, it shouldn't be necessary to recompile a new client every time and just generate a new key?

[NHAS]

Yes, it would be necessary to compile it each time to have a unique public private key pair for the clients. This public key is automatically added to the servers allowed list.

This doesnt effect the server at all.

For deployment this could be done easily with the link command

[shanjunmei]

Yes, it would be necessary to compile it each time to have a unique public private key pair for the clients. This public key is automatically added to the servers allowed list.

This doesnt effect the server at all.

For deployment this could be done easily with the link command

It's a little confusing, maybe I'll change the question, how does the client specify where and which private key to connect to the server, because when I use the client to connect to the server, it doesn't ask me to specify the key, by the way, I Have tested the version you submitted about the public key hash value addition, it works, thank you very much

[NHAS]

The private key is baked into the client binary on compile time. The client then supplies the corresponding public key to the server, the server has the authorized_keys list to check if the client should be allowed.

[NHAS]

Glad to hear you've tested the new version. This issue is now closed.

[shanjunmei]

Thank you for your explanation, sorry for my ignorance. I don't know the principle of private key embedding. I just checked the source code again and found that it was embedded in the way of comments. thank you so much .