x/crypto/ssh: make ClientConfig HostKeyCallback non-permissive by default
rsc opened this issue · 9 comments
ClientConfig.HostKeyCallback interprets nil as "accept any host keys". This is not a great default from a security perspective. Many clients probably should set HostKeyCallback to something real but are not.
It was written this way in golang.org/cl/9922043 to preserve backwards compatibility with the original implementation, but that was probably not the right balance to strike.
This issue is to make HostKeyCallback=nil mean "reject all host keys" and at the same time provide at least
func InsecureSkipVerifyHostKey() HostKeyChecker
func FixedHostKey(key []byte) HostKeyChecker
and maybe also
func HostKeysFile(file string) HostKeyChecker
Thanks to Phil Pennock for pointing out this problem.
CL https://golang.org/cl/38701 mentions this issue.
For reference, this is now: CVE-2017-3204
Hello,
This issue not occurred on "go1.8.1 darwin/amd64". I think that "go1.8.1 darwin/amd64" and " go1.8.1 linux/amd64" is not same in ssh package. Can "go1.8.1 darwin/amd64" commits be behind to " go1.8.1 linux/amd64". It is possible @rsc
Hello again.
I forget do "go get -u github.com/pkg/sftp" with "-u" flag. Sorry for attention :(
I had a question about the approach used to solve this. I understand the reason for the breaking change, but I'm wondering if there is a way to implement this so that the "break" occurs during build as opposed to at run time. That would lessen the impact and the surprises that come up after a build was successful and then the first run in production fails for some error that you've never seen before.
Thoughts?
@CameronGo, had there been a nice solution with that property (failing at compile time instead of run time), we would've used it. But e.g. renaming renaming ssh.ClientConfig to ssh.ClientConfig2 would've been super gross.
Understood - (and agreed on the latter point for sure).
How can agent forwarding be supported this this case, the mux ssh server
client -> mux -> remote