On 03/15/2019 12:49 AM, Jeremy Lin wrote:> [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...]Doesn't StrictHostKeyChecking=no do what is wanted?
On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh at davidnewall.com> wrote:> > On 03/15/2019 12:49 AM, Jeremy Lin wrote: > > > [...] connecting to hosts where the host key > > changes frequently. I realize this is a fairly niche use case [...] > > Doesn't StrictHostKeyChecking=no do what is wanted?None of the StrictHostKeyChecking options currently allow you to use password auth if the host key has changed. The only way we can log into a reimaged device is to use the initial default username and password.
On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh at davidnewall.com> wrote:> >> On 03/15/2019 12:49 AM, Jeremy Lin wrote: >> >> > [...] connecting to hosts where the host key changes frequently. I >> > realize this is a fairly niche use case [...] >> >> Doesn't StrictHostKeyChecking=no do what is wanted?>None of the StrictHostKeyChecking options currently allow you to use password auth if the host key has changed. The only way we can log into a reimaged > device is to use the initial default username and password.What about deleting the hostkey from known_hosts?
On 16/3/19 5:46 am, Jeremy Lin wrote:> On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh at davidnewall.com> wrote: >> On 03/15/2019 12:49 AM, Jeremy Lin wrote: >>> [...] connecting to hosts where the host key >>> changes frequently. I realize this is a fairly niche use case [...] >> Doesn't StrictHostKeyChecking=no do what is wanted? > None of the StrictHostKeyChecking options currently allow you to use > password auth if the host key has changed. The only way we can log > into a reimaged device is to use the initial default username and > password.I suspect you have left out some important details, because setting StrictHostKeyChecking to off does allow use of password authentication.? In fact, you say that you can use the default username and password, hence why I think you've left out important detail. I'm using Ubuntu and it's possible they added a patch that makes this work, but, quick perusal of debian/patches shows nothing that suggests such a change. $ ssh example.com The authenticity of host 'example.com (203.0.113.80)' can't be established. ECDSA key fingerprint is SHA256:62i5qiSlaACj1MmjPwpXNIZaPqyMwtBoWhSoK8Z8x8E. Are you sure you want to continue connecting (yes/no)? ^C $ ssh -oStrictHostKeyChecking=off example.com Warning: Permanently added 'example.com,203.0.113.80' (ECDSA) to the list of known hosts. user at example.com's password: Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-142-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage Last login: Thu Mar 14 23:38:13 2019 from 198.51.100.12 user at example.com:~$ Are you wanting to use host-based authentication in the normal case, falling back to password if the host's key has changed?
Hi, On Fri, Mar 15, 2019 at 12:16:32PM -0700, Jeremy Lin wrote:> On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh at davidnewall.com> wrote: > > > > On 03/15/2019 12:49 AM, Jeremy Lin wrote: > > > [...] connecting to hosts where the host key > > > changes frequently. I realize this is a fairly niche use case [...] > > > > Doesn't StrictHostKeyChecking=no do what is wanted? > > None of the StrictHostKeyChecking options currently allow you to use > password auth if the host key has changed. The only way we can log > into a reimaged device is to use the initial default username and > password."UserKnownHostsFile=/dev/null" was already mentioned, that in combination with "StrictHostKeyChecking=no" should do what you're looking for. Harold