-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Issues with Mapkey Function #414
Comments
it is nice to have configs for working dir that is the very first version of sshpiper like back in 2014 everything was designed under convention over configuration yaml plugin was introduced later to cover the dark side of working dir |
Thank you for responding.
|
seem your Mapkey does not check downstream's key, no matter who the client is, you just map it to your private key |
Our motivation for the code change was that the original code is hardcoded to look for id_rsa and our users could have any of the other key options. The code change snippet is just for our dev cluster and is definitely not something we'd have in production. Ideally Mapkey should look at the downstream key and map it accordingly based on keytype. I tested with id_rsa and id_ecdsa between downstream to proxy; and that worked fine; but from proxy to upstream, it always defaults to id_rsa (which is where original code breaks - since we're using id_ecdsa [bright cluster]) |
maybe change to |
So here’s a follow up to our workflow; we proceeded with suggestion re. yaml plugin. Yaml plugin worked fine for almost everything we’re trying to accomplish with sshpiper. The only functionality it doesn’t support is the lookup of a user in groups and we’ve added that to our codebase, will submit a PR soon. |
Description
The Mapkey function in the Workingdir struct (tg123/sshpiper/plugin/internal/workingdir/workingdir.go) is misaligned with the intended configuration for SSH authentication. The current implementation reads the entire userAuthorizedKeysFile and iterates through each key using ssh.ParseAuthorizedKey, comparing each key with the provided pub parameter. This approach is redundant and inefficient, given that the configuration structure only allows specifying a single private key for upstream SSH authentication, which is hardcoded to id_rsa.
Current Behavior
Proposed Change
We have demonstrated this with our code change. We can set the key to id_ecdsa and just return that from mapkey and we get the desired behavior of using ecdsa for the upstream auth.
Overall we'd like to know the intended purpose of this function and even the necessity of it.
The text was updated successfully, but these errors were encountered: