openssh unix dev - Jan 2017 - known_hosts question for Ubuntu Server 14.04 and 16.04 LTS

Hello & thanks for reading.

I'm having a problem configuring known_hosts from scripts so an accept
key yes/no prompt doesn't appear.

I'm using this command to detect if the server is known and add it to
known_hosts:

if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1;
t
hen ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi

This works fine for the machine that has only one port (22) in
sshd_config, but for a machine that is being accessed on a
non-standard port (they happen to be different versions of Ubuntu as
well, I don't think that's the difference), the code has to be changed
to this:

if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts > /dev/null
2>&1;
then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi

And, as suggested for security, if I add -H to the ssh-keyscan, then
the IP addresses are hashed and the if statement fails every time, no
matter what so the keys are added over and over again.

I figure I'm doing something wrong. Is there a generic way to cause
ssh to generate keys for known_hosts consistently across multiple
configurations with a hash?

Thanks,

Brian

On Sat, Jan 28, 2017 at 2:15 PM, Brian McKee <btmckee9 at gmail.com>
wrote:
> Hello & thanks for reading.
>
> I'm having a problem configuring known_hosts from scripts so an accept
> key yes/no prompt doesn't appear.
I'd suggest that you *stop using it*. Unless you have a well-defined
set of stable hosts, whose SSH host keys are not likely to change,
there hasn't been a point to relying on known_hosts in *years*.
There's no good signature structure for it to verify the authenticity
of published host keys, and too many environments simply re-assign IP
addresses for changing back end hosts, and or alternatively the hosts
are rebuilt with alternative SSH hostkeys with no announcement to
users. Maintaining and relying on a known_hosts has traditionally
broken more automated scripting and forced far more dangerous hacks
and workaounds than it has benefited security.

The relevant options to disable the use of known_hosts are well
explained in an article at
http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html,
and are:

* StrictHostKeyChecking no   # this gets the questions to stop being
asked for new connections
* UserKnownHostsFile=/dev/null   # This prevents the client from
retaining old, mismatched known_hosts entries that will screw up new
connections

Additionally, it can be specified in your script or your .ssh/config
on a host-by-host basis, so that if you really *want*, you can use it.
> I'm using this command to detect if the server is known and add it to
> known_hosts:
>
> if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null
2>&1; then \
>     ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
The "~/", or "$HOME/", is not set for various shell
environments. This
is especially true for cron jobs run from /etc/cron.d, for which $HOME
is always set to "/" by default
>
> This works fine for the machine that has only one port (22) in
> sshd_config, but for a machine that is being accessed on a
> non-standard port (they happen to be different versions of Ubuntu as
> well, I don't think that's the difference), the code has to be
changed
> to this:
>
> if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts >
/dev/null 2>&1;
> then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
>
> And, as suggested for security, if I add -H to the ssh-keyscan, then
> the IP addresses are hashed and the if statement fails every time, no
> matter what so the keys are added over and over again.
>
> I figure I'm doing something wrong. Is there a generic way to cause
> ssh to generate keys for known_hosts consistently across multiple
> configurations with a hash?
Probably. But it's typically not worth the effort, because if the same
IP address is re-assigned to a different host with a different key,
your saved known_hosts file is going to *break*. And in many
environments where hosts re built from images without host keys, and
create keys at boot time, and the new hosts re being cycled quickly in
a limited address space, well, the results are not going to be pretty.
There is no automatic setup in your script to *clear* mismatched
hostkeys, and frankly, they're a common problem. They're even a
problem when visiting new sites were both site happen to use the same
non-routable address space, such as 192.168.1.0/24. Been there, done
that, had to explain to people churning through address spaces for
VM's and CICD that this was a problem.

Thanks for replying Nico.

I do have stable hosts, one in the cloud and one local. My options are
to rely on known_hosts or disable host key checking (
StrictHostKeyChecking no), which opens ssh to man in the middle attacks.
I have no idea if they are common, but I'd prefer to keep people from
being able to do it.

I understand your points about the location of known_hosts. I was using
what works for the servers I'm on and realize that it may not be as
portable as it should be, but I do have control over the OSes on these
machines so I should be relatively safe from change.

I am using RSA keys to enable the machines to ssh to each other without
passwords from specific accounts, so perhaps the host keys aren't as
important?

I wonder what other's think about "StrictHostKeyChecking no".
Everything
I've read online indicates that's a dangerous thing to do.

Brian


On 01/28/17 15:36, Nico Kadel-Garcia wrote:
> On Sat, Jan 28, 2017 at 2:15 PM, Brian McKee <btmckee9 at gmail.com>
wrote:
>> Hello & thanks for reading.
>>
>> I'm having a problem configuring known_hosts from scripts so an
accept
>> key yes/no prompt doesn't appear.
> I'd suggest that you *stop using it*. Unless you have a well-defined
> set of stable hosts, whose SSH host keys are not likely to change,
> there hasn't been a point to relying on known_hosts in *years*.
> There's no good signature structure for it to verify the authenticity
> of published host keys, and too many environments simply re-assign IP
> addresses for changing back end hosts, and or alternatively the hosts
> are rebuilt with alternative SSH hostkeys with no announcement to
> users. Maintaining and relying on a known_hosts has traditionally
> broken more automated scripting and forced far more dangerous hacks
> and workaounds than it has benefited security.
>
> The relevant options to disable the use of known_hosts are well
> explained in an article at
>
http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html,
> and are:
>
> * StrictHostKeyChecking no   # this gets the questions to stop being
> asked for new connections
> * UserKnownHostsFile=/dev/null   # This prevents the client from
> retaining old, mismatched known_hosts entries that will screw up new
> connections
>
> Additionally, it can be specified in your script or your .ssh/config
> on a host-by-host basis, so that if you really *want*, you can use it.
>
>> I'm using this command to detect if the server is known and add it
to
>> known_hosts:
>>
>> if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null
2>&1; then \
>>     ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
> The "~/", or "$HOME/", is not set for various shell
environments. This
> is especially true for cron jobs run from /etc/cron.d, for which $HOME
> is always set to "/" by default
>
>> This works fine for the machine that has only one port (22) in
>> sshd_config, but for a machine that is being accessed on a
>> non-standard port (they happen to be different versions of Ubuntu as
>> well, I don't think that's the difference), the code has to be
changed
>> to this:
>>
>> if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts >
/dev/null 2>&1;
>> then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
>>
>> And, as suggested for security, if I add -H to the ssh-keyscan, then
>> the IP addresses are hashed and the if statement fails every time, no
>> matter what so the keys are added over and over again.
>>
>> I figure I'm doing something wrong. Is there a generic way to cause
>> ssh to generate keys for known_hosts consistently across multiple
>> configurations with a hash?
> Probably. But it's typically not worth the effort, because if the same
> IP address is re-assigned to a different host with a different key,
> your saved known_hosts file is going to *break*. And in many
> environments where hosts re built from images without host keys, and
> create keys at boot time, and the new hosts re being cycled quickly in
> a limited address space, well, the results are not going to be pretty.
> There is no automatic setup in your script to *clear* mismatched
> hostkeys, and frankly, they're a common problem. They're even a
> problem when visiting new sites were both site happen to use the same
> non-routable address space, such as 192.168.1.0/24. Been there, done
> that, had to explain to people churning through address spaces for
> VM's and CICD that this was a problem.

What about using host certificates rather than host keys? You still have a
known_host file, but the key has a @cert-authority marker and, assuming
your servers have host certs signed by that key, you get no prompt.

I set this up at work and we now use it extensively

On Jan 28, 2017 4:37 PM, "Brian T. McKee" <btmckee9 at
gmail.com> wrote:

Thanks for replying Nico.

I do have stable hosts, one in the cloud and one local. My options are
to rely on known_hosts or disable host key checking (
StrictHostKeyChecking no), which opens ssh to man in the middle attacks.
I have no idea if they are common, but I'd prefer to keep people from
being able to do it.

I understand your points about the location of known_hosts. I was using
what works for the servers I'm on and realize that it may not be as
portable as it should be, but I do have control over the OSes on these
machines so I should be relatively safe from change.

I am using RSA keys to enable the machines to ssh to each other without
passwords from specific accounts, so perhaps the host keys aren't as
important?

I wonder what other's think about "StrictHostKeyChecking no".
Everything
I've read online indicates that's a dangerous thing to do.

Brian


On 01/28/17 15:36, Nico Kadel-Garcia wrote:
> On Sat, Jan 28, 2017 at 2:15 PM, Brian McKee <btmckee9 at gmail.com>
wrote:
>> Hello & thanks for reading.
>>
>> I'm having a problem configuring known_hosts from scripts so an
accept
>> key yes/no prompt doesn't appear.
> I'd suggest that you *stop using it*. Unless you have a well-defined
> set of stable hosts, whose SSH host keys are not likely to change,
> there hasn't been a point to relying on known_hosts in *years*.
> There's no good signature structure for it to verify the authenticity
> of published host keys, and too many environments simply re-assign IP
> addresses for changing back end hosts, and or alternatively the hosts
> are rebuilt with alternative SSH hostkeys with no announcement to
> users. Maintaining and relying on a known_hosts has traditionally
> broken more automated scripting and forced far more dangerous hacks
> and workaounds than it has benefited security.
>
> The relevant options to disable the use of known_hosts are well
> explained in an article at
> http://linuxcommando.blogspot.com/2008/10/how-to-disable-
ssh-host-key-checking.html,
> and are:
>
> * StrictHostKeyChecking no   # this gets the questions to stop being
> asked for new connections
> * UserKnownHostsFile=/dev/null   # This prevents the client from
> retaining old, mismatched known_hosts entries that will screw up new
> connections
>
> Additionally, it can be specified in your script or your .ssh/config
> on a host-by-host basis, so that if you really *want*, you can use it.
>
>> I'm using this command to detect if the server is known and add it
to
>> known_hosts:
>>
>> if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null
2>&1;
then \
>>     ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
> The "~/", or "$HOME/", is not set for various shell
environments. This
> is especially true for cron jobs run from /etc/cron.d, for which $HOME
> is always set to "/" by default
>
>> This works fine for the machine that has only one port (22) in
>> sshd_config, but for a machine that is being accessed on a
>> non-standard port (they happen to be different versions of Ubuntu as
>> well, I don't think that's the difference), the code has to be
changed
>> to this:
>>
>> if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts >
/dev/null 2>&1;
>> then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
>>
>> And, as suggested for security, if I add -H to the ssh-keyscan, then
>> the IP addresses are hashed and the if statement fails every time, no
>> matter what so the keys are added over and over again.
>>
>> I figure I'm doing something wrong. Is there a generic way to cause
>> ssh to generate keys for known_hosts consistently across multiple
>> configurations with a hash?
> Probably. But it's typically not worth the effort, because if the same
> IP address is re-assigned to a different host with a different key,
> your saved known_hosts file is going to *break*. And in many
> environments where hosts re built from images without host keys, and
> create keys at boot time, and the new hosts re being cycled quickly in
> a limited address space, well, the results are not going to be pretty.
> There is no automatic setup in your script to *clear* mismatched
> hostkeys, and frankly, they're a common problem. They're even a
> problem when visiting new sites were both site happen to use the same
> non-routable address space, such as 192.168.1.0/24. Been there, done
> that, had to explain to people churning through address spaces for
> VM's and CICD that this was a problem.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev