Mailing List Archive

prompt to update a host key
As far as I can tell, there currently isn't a straightforward way to
use password authentication for connecting to hosts where the host key
changes frequently. I realize this is a fairly niche use case, but
when developing software for devices that often get reimaged
(resulting in a host key change), it can get pretty tedious to attempt
to connect, get a warning, remove the old host key via text editor or
"ssh-keygen -R", and then connect again.

I'd like to propose adding a new StrictHostKeyChecking option, named
something like "ask-update" or "ask-to-update". This would be like
"ask", except it would prompt the user to update a host key if it has
changed (after printing a suitably scary warning). When connecting to
an unknown host, it would be equivalent to "ask".

I expect users would enable it explicitly for a limited set of hosts,
e.g. by adding a config section like

Host 192.168.0.*
StrictHostKeyChecking ask-update

If this idea sounds acceptable, I could potentially work on it, but I
don't mind at all if someone else is interested in doing it.

Thanks,
Jeremy
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
Out of curiosity, why don't you just not store a host key for such systems?
That's what we do:
UserKnownHostsFile /dev/null

Historically I would have been interested in such a thing, but I've long
since given up.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
Simple, I wasn't aware of that option, and that approach never
occurred to me. :) Thanks, that should be an effective workaround.

I think the extra StrictHostKeyChecking option would be easier for
someone to find, and arguably has some minor security benefit, but
it's no longer clear to me whether it would be worth the effort.

Thanks again.

Jeremy

On Thu, Mar 14, 2019 at 4:59 PM Josh Soref <jsoref@gmail.com> wrote:
>
> Out of curiosity, why don't you just not store a host key for such systems? That's what we do:
> UserKnownHostsFile /dev/null
>
> Historically I would have been interested in such a thing, but I've long since given up.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
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 [...]

Imagine sysadminning a boatload of VMs getting IPs from a dynamic pool, a la

$ for ADDR in $CUSTOMER_1_RANGE $CUSTOMER_2_RANGE... ; do
> ping -c 1 -w 2 $ADDR >/dev/null 2>&1 && ssh root@$ADDR do_urgent_fix
> done

, and it mightn't be that much of a niche anymore ...

> [...] developing software for devices that often get reimaged
> (resulting in a host key change) [...]

If the host keypair(s) are truly useless for identifying a *single*,
short-lived target host, my suggestion would be to include "global"
keypairs into the image (and have them still replaced once in a while).
That would at least protect clients from a fake host set up by someone
who doesn't have access to the image or the legit hosts. (Or from
accidentally shredding a genuine "permanent" system that somehow
obtained the DNS name / IP of a short-lived one.)

If, however, reimaging is a standardized process that might allow the
new host pubkey(s) to be collected and distributed in one fell swoop,
there's the GlobalKnownHostsFile setting which is *supposed* to point to
a file maintained by the *sysadmins* ...

Regards,
--
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect
Re: prompt to update a host key [ In reply to ]
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?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 09:10:26AM +0000, Jochen Bern wrote:
> Imagine sysadminning a boatload of VMs getting IPs from a dynamic pool, a la
>
> $ for ADDR in $CUSTOMER_1_RANGE $CUSTOMER_2_RANGE... ; do
> > ping -c 1 -w 2 $ADDR >/dev/null 2>&1 && ssh root@$ADDR do_urgent_fix
> > done
>
> , and it mightn't be that much of a niche anymore ...

And that's when you look at using certificate based host keys.

--

rgds
Stephen
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 2:13 AM Jochen Bern <Jochen.Bern@binect.de> wrote:
>
> If the host keypair(s) are truly useless for identifying a *single*,
> short-lived target host, my suggestion would be to include "global"
> keypairs into the image (and have them still replaced once in a while).
> That would at least protect clients from a fake host set up by someone
> who doesn't have access to the image or the legit hosts. (Or from
> accidentally shredding a genuine "permanent" system that somehow
> obtained the DNS name / IP of a short-lived one.)
>
> If, however, reimaging is a standardized process that might allow the
> new host pubkey(s) to be collected and distributed in one fell swoop,
> there's the GlobalKnownHostsFile setting which is *supposed* to point to
> a file maintained by the *sysadmins* ...

These are development builds of software images that will eventually
be shipped to customers, so we'd strongly prefer not to hardcode any
host keys since that could accidentally end up getting shipped
someday.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
RE: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh@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?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Thu, Mar 14, 2019 at 8:01 PM Josh Soref <jsoref@gmail.com> wrote:
>
> Out of curiosity, why don't you just not store a host key for such systems?
> That's what we do:
> UserKnownHostsFile /dev/null
>
> Historically I would have been interested in such a thing, but I've long
> since given up.

You forgot "LogLevel Error" and "StrictHostKeyCheckng no" to
completely disable the use of $HOME/.ssh/known_hosts and make it shut
up.

If the hosts I dealt with would have consistent IP addresses and DNS
tied to host keys, I'd say "this is a potential security risk".
However, I deal with multiple raw OS images deployed into
virtualization environments with DHCP randomized IP addresses,
regenerated multiple times a day, as a matter of course. The cost of
saying "flush another old key" all the time is burdensome. That much
extra work is actually anti-security.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 6:40 AM Stephen Harris <lists@spuddy.org> wrote:
>
> On Fri, Mar 15, 2019 at 09:10:26AM +0000, Jochen Bern wrote:
> > Imagine sysadminning a boatload of VMs getting IPs from a dynamic pool, a la
> >
> > $ for ADDR in $CUSTOMER_1_RANGE $CUSTOMER_2_RANGE... ; do
> > > ping -c 1 -w 2 $ADDR >/dev/null 2>&1 && ssh root@$ADDR do_urgent_fix
> > > done
> >
> > , and it mightn't be that much of a niche anymore ...
>
> And that's when you look at using certificate based host keys.

And it fails miserably as soon as any of the intervening firewalls
block ICMP, such as, say, the security group settings for an AWS
deployed virtual host. You need to check with port 22 on TCP, not ICMP
packets. This sort of thing is also why a casually assembled "doodz,
just do this thing!!!" breaks down in the larger world.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On 16/3/19 5:46 am, Jeremy Lin wrote:
> On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh@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@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@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?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On Fri, Mar 15, 2019 at 7:49 PM David Newall <openssh@davidnewall.com>
wrote:

> On 16/3/19 5:46 am, Jeremy Lin wrote:
> > On Fri, Mar 15, 2019 at 2:37 AM David Newall <openssh@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@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@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?
>

I mentioned "if the host key has changed". If you had answered "yes" in the
first invocation, and proceeded to regenerate the host keypair on
example.com, then the second invocation would not have allowed you to enter
a password.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
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@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On 15/03/19, Nico Kadel-Garcia (nkadel@gmail.com) wrote:

> On Fri, Mar 15, 2019 at 6:40 AM Stephen Harris <lists@spuddy.org> wrote:
> > On Fri, Mar 15, 2019 at 09:10:26AM +0000, Jochen Bern wrote:
> > And that's when you look at using certificate based host keys.
>
> And it fails miserably as soon as any of the intervening firewalls
> block ICMP, such as, say, the security group settings for an AWS
> deployed virtual host. You need to check with port 22 on TCP, not ICMP
> packets. This sort of thing is also why a casually assembled "doodz,
> just do this thing!!!" breaks down in the larger world.

Hi Nico

Referencing back to the OP's question:

> > On 14/03/19, Jeremy Lin (jeremy.lin@gmail.com) wrote:
> > > As far as I can tell, there currently isn't a straightforward way to
> > > use password authentication for connecting to hosts where the host key
> > > changes frequently.

Is there an issue with using certificate based host keys, as Jochen
suggests, that means they can't easily be used for auto-generated
instances?

According to the RedHat docs: "To authenticate a host to a user, a
public key must be generated on the host, passed to the CA server,
signed by the CA, and then passed back to be stored on the host to
present to a user attempting to log into the host."
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-signing_ssh_certificates

The process of picking up the auto-generated host file
ssh_host_rsa_key.pub to the CA machine, signing the host file, copying
the resulting certificate back to the host, adding the line
"HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub" or alternative in
the host /etc/ssh/sshd_config file and restarting sshd can all be
automated.

If all users have received the CA public host key and have added it with
the requisite @cert-authority preamble to their ~/.ssh/known_hosts file,
the host warning Jeremy was complaining about would not occur.

Or am I missing something obvious?

Thanks
Rory






_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: prompt to update a host key [ In reply to ]
On 17/03/19, Jochen Bern (Jochen.Bern@binect.de) wrote:
> On 03/16/2019 07:34 PM, Rory Campbell-Lange wrote:
> >>> On Fri, Mar 15, 2019 at 09:10:26AM +0000, Jochen Bern wrote:
> >>> And that's when you look at using certificate based host keys.
> [...]
> > Is there an issue with using certificate based host keys, as Jochen
> > suggests
>
> (FWIW, that actually was Stephen Harris <lists@spuddy.org>, as in, the
> *other* guy you Cc:ed. I'm afraid that my employer could not, so far, be
> interested in using SSH certificates, in spite of clear use cases, so my
> experience with them is pretty much nil. :-/ )

Sorry about the quoting mistake.

If you do look at certificates in future, there is a couple of cool
projects on github for using a certificate authority for the client
authorisation part.

Although I haven't tried it, ssh-cert-authority looks quite good
https://github.com/cloudtools/ssh-cert-authority

Uber's pam-ussh is another possibility, but I haven't tried that either.

Perhaps a certificate authority can become part of the openssh suite in
future too?

Rory

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev