Re: known_hosts question for Ubuntu Server 14.04 and 16.04 LTS

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux