-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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: