You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to submit a PR to include the option of an interactive prompt for host key verification in the case where the host key is not present in the known_hosts sources. Adding a prompt like what exists with the ssh CLI tool would be nice for other interactive tools that use this package.
Example:
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:un8VXgUIyeqFIkd/l+avJyKOQvIvuthI8wkva0OmclU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
There are a few different ways I could see this going, so I'm requesting feedback on what would be most preferable.
Approach 1
I think this would be most easily done by adding a function to the x/crypto/ssh/knownhosts package to specify that verification should be interactive. This could be added at this line.
Proposed added function:
// NewInteractive creates a HostKeyCallback with an extended HostKeyFallback that// shows an interactive prompt. If the user accepts the host key signature, then the// key will be added to all sources specified by the 'files' parameter.funcNewInteractive(files...string) (ssh.HostKeyCallback, error)
Approach 2
Alternatively, an option to include a handler for this functionality could be added so the user can make their own determinations about how to handle this situation. This may be preferable for some, but puts the extended verification process in the hands of the devs using this package. This is arguable not ideal considering that the existing verification processes are behind unexported functions, which seems to indicate that you're not trying to expose people to much of the complexity of host cert/key verification.
// UnknownHostKeyHandler allows the caller to provide an additional handler that gets called// in the event that the host key is not revoked and not found in any of the provided known_hosts// file locations.typeUnknownHostKeyHandlerfunc(hostnamestring, remote net.Addr, keyPublicKey) error// NewInteractive enables the use of an UnknownHostKeyHandler.funcNewInteractive(unknownHandlerUnknownHostKeyHandler, files...string) (ssh.HostKeyCallback, error) {
/* ... */
}
Approach 3
Another way to extend this could be with a configuration object that is passed to a new New function. This would provide an extension point for later use and provide the desired interactive behavior. I don't think there's a whole lot that would need to be added to this package and still fit within its scope, but it's an option nonetheless.
// InteractivePrompt uses the provided information to construct an interactive prompt string// that is displayed to the user.typeInteractivePromptfunc(hostnamestring, remote net.Addr, keyPublicKey) string// HostVerificationConfig allows callers to customize host verification.typeHostVerificationConfigstruct {
InteractiveHostKeybool,
PromptInteractivePrompt,
}
// NewCustom allows the caller to provide HostVerificationConfig to customize the host verification process.funcNewCustom(verificationConfigHostVerificationConfig, files...string) (ssh.HostKeyCallback, error) {
/* ... */
}
The text was updated successfully, but these errors were encountered:
I think the interesting part of this would be the write back. Currently, it looks like all of the known host information is aggregated into one source, so it would have to be changed to include the file paths so a newly accepted/verified host key could be appended. This piece doesn't seem like a massive change beyond new functionality, as it wouldn't affect any of the existing logic except initialization, where the array of file paths could be initialized.
However, in the case where the user has selected multiple sources of verified host key information, is there a "right" source to update? The best answer I can come up with is to add the new verified host key to all sources. The rationale behind this is that the user has selected multiple sources of verified hosts as "correct". When the user accepts/verifies a host key, adding that key to only one source doesn't make a lot of sense because it would seem to indicate that one of the sources is "more correct" than the others, even though such a concept does not exist in aggregate comparison. If one of the files is the "wrong" one to add the host key to, what does that say about the validity of any of the information in that file?
Looking forward to hearing from you all. 😁
ianlancetaylor
changed the title
x/crypto/ssh/knownhosts: proposal: interactive host key verification
proposal: x/crypto/ssh/knownhosts: interactive host key verification
Aug 7, 2020
What version of Go are you using (
go version
)?I'd like to submit a PR to include the option of an interactive prompt for host key verification in the case where the host key is not present in the known_hosts sources. Adding a prompt like what exists with the ssh CLI tool would be nice for other interactive tools that use this package.
Example:
Current function:
There are a few different ways I could see this going, so I'm requesting feedback on what would be most preferable.
Approach 1
I think this would be most easily done by adding a function to the x/crypto/ssh/knownhosts package to specify that verification should be interactive. This could be added at this line.
Proposed added function:
Approach 2
Alternatively, an option to include a handler for this functionality could be added so the user can make their own determinations about how to handle this situation. This may be preferable for some, but puts the extended verification process in the hands of the devs using this package. This is arguable not ideal considering that the existing verification processes are behind unexported functions, which seems to indicate that you're not trying to expose people to much of the complexity of host cert/key verification.
Approach 3
Another way to extend this could be with a configuration object that is passed to a new
New
function. This would provide an extension point for later use and provide the desired interactive behavior. I don't think there's a whole lot that would need to be added to this package and still fit within its scope, but it's an option nonetheless.The text was updated successfully, but these errors were encountered: