-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Implement parsing for supported -o flags #2330
Comments
hi @kontsevoy @russjones, did this ever got into a release? I'm trying the latest |
@russjones re-opening because I can reproduce the problem too. |
@russjones also, when we figure out what's going on, let's assign it to me to update the docs? Thanks. |
I am getting:
For the 1st issue, it would be nice to generate a friendlier user message (maybe say "perhaps you want to use this flag as tsh ssh -o?", not sure if our command line parser allows customizing error messages for misplaced flags). For the 2nd issue it's unclear why wouldn't it work. |
- Faster docs build time due to parallel builds - Added "agentless" entry to Q&A - Documented -o flag support for `tsh ssh`. Closes #2330
- Faster docs build time due to parallel builds - Added "agentless" entry to Q&A - Documented -o flag support for `tsh ssh`. Closes #2330
For better compatibility with OpenSSH we shall consider certain subset of
-o
options to be passed totsh ssh
. We already have support for many and at the very least we should consider accepting and ignoring options which are on by default. The candidates include:Related issue: #2217
Details
-o AddKeysToAgent
should be fully supported. The default behavior is "yes" but if a user specifies "no" we should NOT add keys to the agent.-o ForwardAgent
should be full supported similarly to above.-o RequestTTY
is basically an alias to-i
so it should be fully supported.-o StrictHostKeyChecking
should be fully supported. This one is interesting because it makes no sense in a standard Teleport deployment (because all hosts are authenticated) but it does make sense when Teleport is used with OpenSSH (and yes, we ask a user if they trust a node).If any other OpenSSH option is used (see
man ssh
) it should result in aWARNING
written tostderr
sayingWARNING: option XXX is not supported
but otherwisetsh
should proceed.If anything else (not a valid OpenSSH option) is used with
-o
, it should result inERROR
written tostderr
sayingERROR: option XXX is not supported
andtsh
must exit with an error exit status/code (probably 1?)The text was updated successfully, but these errors were encountered: