When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as I
didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

It's this commit:
https://github.com/cloudfoundry/bosh/commit/34eb5dce581167082af43d69c0bf38a1e263cd7b

This was put in as a precursor to later allow Director to supply host
fingerprints for validation.

For now, it causes extra burden.

CloudOps gets around it by using this:

○ → type bosh
bosh is a function
bosh ()
{
if [ "$1" = ssh ]; then
shift;
set ssh --strict_host_key_checking no "$@";
fi;
command bosh "$@"
}

This is a stand in until the full checking behavior is implemented.


Jim

On Mon, Sep 21, 2015 at 2:36 PM Dr Nic Williams <drnic(a)starkandwayne.com>
wrote:

When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as
I didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic

We recently accepted PR that had some unintentional stricter verification.
To properly fix the issue we are pushing
https://www.pivotaltracker.com/story/show/102530088 through the CI. This
story will allow bosh ssh to trust expected host public key automatically.
Older CLI should continue to behave as it did while the fix goes through
the CI.

Are bosh-lite users supposed to be bringing custom SSL certs into

bosh-lite?

This features relates to SSH, not SSL.

On Mon, Sep 21, 2015 at 3:05 PM, Jim Park <spark(a)pivotal.io> wrote:

It's this commit:
https://github.com/cloudfoundry/bosh/commit/34eb5dce581167082af43d69c0bf38a1e263cd7b

This was put in as a precursor to later allow Director to supply host
fingerprints for validation.

For now, it causes extra burden.

CloudOps gets around it by using this:

○ → type bosh
bosh is a function
bosh ()
{
if [ "$1" = ssh ]; then
shift;
set ssh --strict_host_key_checking no "$@";
fi;
command bosh "$@"
}

This is a stand in until the full checking behavior is implemented.


Jim

On Mon, Sep 21, 2015 at 2:36 PM Dr Nic Williams <drnic(a)starkandwayne.com>
wrote:

When I deploy microbosh now & bosh-lite, no longer does `bosh ssh` just
work. Instead you get:

No ECDSA host key is known for 10.10.1.11 and you have requested strict
checking.


But I didn't "requested strict checking" at all. How do I use `bosh ssh`
without requiring the `--strict_host_key_checking no` flag?

Are bosh-lite users supposed to be bringing custom SSL certs into
bosh-lite? Doesn't sounds like a common use case - can `bosh ssh` please go
back to "just working" if the bosh doesn't have custom SSL installed?

Or at least remove "you have requested strict checking" from the error as
I didn't request it :)


Nic

--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic