StrictHostKeyChecking=no #5029
jonaseberle
started this conversation in
General
Replies: 2 comments
-
I think I'd be fine with this. However, since the known_hosts does not normally persist, it's not that relevant, and everything should work out fine. If |
Beta Was this translation helpful? Give feedback.
0 replies
-
We've seen it being persisted in a project where we had that enabled with a custom SSH config. So it might produce some support tickets where the host key actually changed. Yet OpenSSH is actually very helpful in its warning message in that case. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I'd like to discuss the current default SSH client config
StrictHostKeyChecking=no
.For outgoing connections that removes a layer of protection against MITM.
We use DDEV for parts of our deployment pipeline and were adding
.ddev/homeadditions/.ssh/config
(withStrictHostKeyChecking=yes
or since OpenSSH 7.6StrictHostKeyChecking=accept-new
) in some projects (but not in all which raised some security question...). I like to keep things easy but I agree with the security folks that this is unexpected for SSH users.I would suggest to use
accept-new
by default which would require the user to deal with it if the host key really changed (clear the line from/home/.ssh-agent/known_hosts
) but would not get in the way while host keys are not changing.What do you think?
man ssh_config
:Relates: #1266
Beta Was this translation helpful? Give feedback.
All reactions