![]() Personally, I use this flag only when I boot machines in a cloud environment with cloud-init immediately after the machine started. One should only do it if there is an absolute trust in the network or that the server was not compromised. A hostile server, which you don't own can be then used to steal a password and all sort of data.Īccepting a new unknown key is also pretty dangerous. ![]() When you do not check the host key you might land with an SSH session on a different computer (yes, this is possible with IP Hijacking). The host keys of known hosts will be verified automatically in all cases. That is what they really want to do, and ssh will refuse toĬonnect to hosts whose host key has changed. If this flag is set to ask (the default), new host keys will beĪdded to the user known host files only after the user has confirmed To the user known hosts files and allow connections to hosts withĬhanged hostkeys to proceed, subject to some restrictions. ![]() Is set to “no” or “off”, ssh will automatically add new host keys New host keys to the user known hosts files, but will not permitĬonnections to hosts with changed host keys. If this flag is set to “accept-new” then ssh will automatically add Note, StrictHostKe圜hecking=no will add the public key to ~/.ssh/known_hosts even if the key was changed.Īccept-new is only for new hosts. WARNING: use this only if you absolutely trust the IP\hostname you are going to SSH to: ssh -o StrictHostKe圜hecking=accept-new This is done with -o StrictHostKe圜hecking=accept-new. It is relatively unknown, since it's new (added in Openssh 6.5). While common wisdom is not to disable host key checking, there is a built-in option in SSH itself to do this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |