<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Disable SSH Known Host Checking</title>
	<atom:link href="http://cubiclegeneration.com/linux-help/disable-ssh-known-host-checking/feed" rel="self" type="application/rss+xml" />
	<link>http://cubiclegeneration.com/linux-help/disable-ssh-known-host-checking</link>
	<description>omgz cubicles</description>
	<lastBuildDate>Thu, 01 Dec 2011 13:35:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: bikerbreath</title>
		<link>http://cubiclegeneration.com/linux-help/disable-ssh-known-host-checking/comment-page-1#comment-5670</link>
		<dc:creator>bikerbreath</dc:creator>
		<pubDate>Sun, 10 Apr 2011 00:14:32 +0000</pubDate>
		<guid isPermaLink="false">http://cubiclegeneration.com/?p=120#comment-5670</guid>
		<description>Thanks, Cody, good point... I am keeping all my eggs in one basket by using one set of keys for ssh.

Yes, the underlying problem is NAT.  I suppose the real solution is to wait for IPv6 to hit the streets here.</description>
		<content:encoded><![CDATA[<p>Thanks, Cody, good point&#8230; I am keeping all my eggs in one basket by using one set of keys for ssh.</p>
<p>Yes, the underlying problem is NAT.  I suppose the real solution is to wait for IPv6 to hit the streets here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cody</title>
		<link>http://cubiclegeneration.com/linux-help/disable-ssh-known-host-checking/comment-page-1#comment-5439</link>
		<dc:creator>Cody</dc:creator>
		<pubDate>Fri, 25 Mar 2011 05:14:42 +0000</pubDate>
		<guid isPermaLink="false">http://cubiclegeneration.com/?p=120#comment-5439</guid>
		<description>You shouldn&#039;t disable this globally but only client side as it opens you up for MITM attacks. Part of the protocol and usefulness of storing the fingerprints of each host is you can ensure that future connections are to the same host - encryption &amp; authentication :).

If you have to do this (behind NAT?) I&#039;d suggest using a local SSH config instead (~/.ssh/config) and only disable the checks for known for known hosts.

@BikerBreath

That&#039;s not really a good idea. If one set of keys was compromised then every machine would be affected.

It&#039;s *good* that SSH asks you by default if you&#039;re connecting to a new host. This allow you to establish the trust in the initial connection - once you do that you can ensure all subsequent connections to that host is 100% that host and 100% encrypted with no snooping. If the fingerprints don&#039;t match from your known one SSH will warn you possibly preventing you from being victim of a MITM attack.</description>
		<content:encoded><![CDATA[<p>You shouldn&#8217;t disable this globally but only client side as it opens you up for MITM attacks. Part of the protocol and usefulness of storing the fingerprints of each host is you can ensure that future connections are to the same host &#8211; encryption &amp; authentication <img src='http://cubiclegeneration.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p>
<p>If you have to do this (behind NAT?) I&#8217;d suggest using a local SSH config instead (~/.ssh/config) and only disable the checks for known for known hosts.</p>
<p>@BikerBreath</p>
<p>That&#8217;s not really a good idea. If one set of keys was compromised then every machine would be affected.</p>
<p>It&#8217;s *good* that SSH asks you by default if you&#8217;re connecting to a new host. This allow you to establish the trust in the initial connection &#8211; once you do that you can ensure all subsequent connections to that host is 100% that host and 100% encrypted with no snooping. If the fingerprints don&#8217;t match from your known one SSH will warn you possibly preventing you from being victim of a MITM attack.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bikerbreath</title>
		<link>http://cubiclegeneration.com/linux-help/disable-ssh-known-host-checking/comment-page-1#comment-5438</link>
		<dc:creator>bikerbreath</dc:creator>
		<pubDate>Fri, 25 Mar 2011 03:58:21 +0000</pubDate>
		<guid isPermaLink="false">http://cubiclegeneration.com/?p=120#comment-5438</guid>
		<description>Using openSSH, this also works -- but only if you have root access to the machines you are ssh-ing into:

Copy one set of host ssh key files to all ssh servers behind the same ip address.  These keys are in several files named similarly to
/etc/ssh/ssh_host_dsa_key

Some of those key files (the private keys) are only root-readable.  Keep them that way.

With the same host keys on all ssh servers, there will be no complaint about &quot;host key has changed&quot; from your ssh client, and you can keep strict host key checking enabled.

Of course, I have no idea about cryptography, so I wouldn&#039;t know if the act of sharing your host keys across many disparate servers is a good idea.  So far, so good, though.

Can someone comment on security issues, or other issues that could result from sharing of these host keys?

-- Kevin</description>
		<content:encoded><![CDATA[<p>Using openSSH, this also works &#8212; but only if you have root access to the machines you are ssh-ing into:</p>
<p>Copy one set of host ssh key files to all ssh servers behind the same ip address.  These keys are in several files named similarly to<br />
/etc/ssh/ssh_host_dsa_key</p>
<p>Some of those key files (the private keys) are only root-readable.  Keep them that way.</p>
<p>With the same host keys on all ssh servers, there will be no complaint about &#8220;host key has changed&#8221; from your ssh client, and you can keep strict host key checking enabled.</p>
<p>Of course, I have no idea about cryptography, so I wouldn&#8217;t know if the act of sharing your host keys across many disparate servers is a good idea.  So far, so good, though.</p>
<p>Can someone comment on security issues, or other issues that could result from sharing of these host keys?</p>
<p>&#8211; Kevin</p>
]]></content:encoded>
	</item>
</channel>
</rss>

