Mailing List Archive

Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ?
Question
--------

I often know and accept that portX on serverY is not the same as it was
10 minutes ago. Therefore I don't want to use ~/.ssh/known_hosts. So
I use "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
-p portX serverY" but it is very lengthy to type and always yields this
message:

Warning: Permanently added '<host>,<ip>' (RSA) to the list of known hosts

where 'list of known hosts' presumably is /dev/null.

Is there a better way to suppress using host keys? I wish there was a
--no-hostkeys or similar option to do this.

If not, is there a way to avoid the above warning? It is misleading, and
I prefer not to train myself to avoid warnings.

(Yes, there are security problems when not using host keys. I know.)

I've tried to search the mailing list, but
http://marc.info/?l=secure-shell&w=2&r=1&s=stricthostkeychecking&q=b
shows some really weird results (try it!)

Further background
------------------

- We're on a LAN where our DHCP server is messed up. And corporate
wisdom dictates that it isn't worth it to ensure that hosts get the same
IP address at every reboot. We have to deal with it.

- We use port forwarding a lot, so port 2223 on serverX is forwarded to
a particular host right now, but a different one in 10 minutes. That is
reality for us.

- Also, we often test fresh installations, where each test involves
installation of the ssh package and hence the host keys differ from test
to test.

From a security standpoint an easy option to disable host keys when we
*know* they won't work is better than putting the
StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null in
~/.ssh/config and then teaching the eye not to see the "Warning:
Permanently added..." message, isn't it?

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
Maybe you are misunderstanding how this works and what it is supposed to do....

If you do allow it to save to a real known_hosts file it should no longer ask you or warn you about "man in the middle" attacks because you do have "StrictHostKeyChecking=no". As that is the whole purpose of that is to warn you when a host has changed and there is a possible "man in the middle" attack.

I do not know of a way to avoid that initial adding to the "known_hosts" file. But if you allow it to save to a regular known_hosts file, you should only have to hit (y) 1 time to add that initial known_hosts signature and that is it. So, even if the host changes, it won't matter. It shouldn't prompt you again to add it again or warn you that it has changed since you have "StrictHostKeyChecking=no".

Hope that helps...


Brian



----- Original Message -----
From: "\"Peter Valdemar Mørch (Lists)\"" <4ux6as402@sneakemail.com>
To: secureshell@securityfocus.com
Sent: Tuesday, March 3, 2009 10:04:10 AM GMT -05:00 US/Canada Eastern
Subject: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ?

Question
--------

I often know and accept that portX on serverY is not the same as it was
10 minutes ago. Therefore I don't want to use ~/.ssh/known_hosts. So
I use "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
-p portX serverY" but it is very lengthy to type and always yields this
message:

Warning: Permanently added '<host>,<ip>' (RSA) to the list of known hosts

where 'list of known hosts' presumably is /dev/null.

Is there a better way to suppress using host keys? I wish there was a
--no-hostkeys or similar option to do this.

If not, is there a way to avoid the above warning? It is misleading, and
I prefer not to train myself to avoid warnings.

(Yes, there are security problems when not using host keys. I know.)

I've tried to search the mailing list, but
http://marc.info/?l=secure-shell&w=2&r=1&s=stricthostkeychecking&q=b
shows some really weird results (try it!)

Further background
------------------

- We're on a LAN where our DHCP server is messed up. And corporate
wisdom dictates that it isn't worth it to ensure that hosts get the same
IP address at every reboot. We have to deal with it.

- We use port forwarding a lot, so port 2223 on serverX is forwarded to
a particular host right now, but a different one in 10 minutes. That is
reality for us.

- Also, we often test fresh installations, where each test involves
installation of the ssh package and hence the host keys differ from test
to test.

From a security standpoint an easy option to disable host keys when we
*know* they won't work is better than putting the
StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null in
~/.ssh/config and then teaching the eye not to see the "Warning:
Permanently added..." message, isn't it?

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
Thanks for your response.

Brian Torbich btorbich-at-voicemarketing.net |Lists| wrote:
> Maybe you are misunderstanding how this works and what it is supposed
> to do....

Perhaps. And perhaps you are misunderstanding my question.

> If you do allow it to save to a real known_hosts file it should no
> longer ask you or warn you about "man in the middle" attacks because
> you do have "StrictHostKeyChecking=no". As that is the whole purpose
> of that is to warn you when a host has changed and there is a
> possible "man in the middle" attack.
>
> I do not know of a way to avoid that initial adding to the
> "known_hosts" file. But if you allow it to save to a regular
> known_hosts file, you should only have to hit (y) 1 time to add that
> initial known_hosts signature and that is it. So, even if the host
> changes, it won't matter. It shouldn't prompt you again to add it
> again or warn you that it has changed since you have
> "StrictHostKeyChecking=no".

For the fun of it, I edited my regular ~/.ssh/known_hosts file, and
assigned a wrong fingerprint to a host.

Running with "StrictHostKeyChecking=no" only gets me 24 lines of warning
output containing

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

and especially:

Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid
man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.

So it *does* actually log in, but uhm, the output is much worse than the
one warning I now get, and this is not what I want. I would like to
gracefully disable key checking entirely so I get zero lines of warnings.

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
David R Green wrote:
> Is it just the warning output you're worried about or the key
> checking?

As I tried to describe in my original post I want disable the key
checking intentionally.

> Can't you supply the "-q" switch to suppress the warning?

Excellent! Or even "-o LogLevel=ERROR". Yes, that takes care of the
warning too! Fantastic. (But it does also remove all other warnings,
which I'm guessing might be dangerous...)

So now, to disable host keys without getting warnings, I need to:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
LogLevel=ERROR user@server

Sure wish there was a simpler way to do that, such as:

$ ssh --no-hostkeys user@server
or
$ ssh -o HostKeys=no user@server
or
$ ssh -o HostKeyAlias=none user@server
or
$ ssh -o HostKeyAlias= user@server
or something similar

But I'm assuming from this thread that there isn't. ;-) Thanks, Brian
and David, for your time and help.

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
(answers assume OpenSSH, since that's what the options look like.)

Peter Valdemar Mørch (Lists) wrote:
> Question
> --------
>
> I often know and accept that portX on serverY is not the same as it was
> 10 minutes ago. Therefore I don't want to use ~/.ssh/known_hosts. So
> I use "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
> -p portX serverY" but it is very lengthy to type and always yields this
> message:
>
> Warning: Permanently added '<host>,<ip>' (RSA) to the list of known hosts
>
> where 'list of known hosts' presumably is /dev/null.
>
> Is there a better way to suppress using host keys? I wish there was a
> --no-hostkeys or similar option to do this.
>
> If not, is there a way to avoid the above warning? It is misleading, and
> I prefer not to train myself to avoid warnings.

You could use LogLevel quiet.

> (Yes, there are security problems when not using host keys. I know.)
>
> I've tried to search the mailing list, but
> http://marc.info/?l=secure-shell&w=2&r=1&s=stricthostkeychecking&q=b
> shows some really weird results (try it!)
>
> Further background
> ------------------
>
> - We're on a LAN where our DHCP server is messed up. And corporate
> wisdom dictates that it isn't worth it to ensure that hosts get the same
> IP address at every reboot. We have to deal with it.
>
> - We use port forwarding a lot, so port 2223 on serverX is forwarded to
> a particular host right now, but a different one in 10 minutes. That is
> reality for us.

For this one you can use "HostKeyAlias serverX" and "CheckHostIP no".

> - Also, we often test fresh installations, where each test involves
> installation of the ssh package and hence the host keys differ from test
> to test.

This one is not so easy to handle automatically, since it's pretty much
indistinguishable from a MITM attack.

You could use ssh-keygen -R [machine you just reinstalled] or the
StrictHostKeyChecking / UserKnownHostsFile / LogLevel combination
described above only for the install-test machines.

> From a security standpoint an easy option to disable host keys when we
> *know* they won't work is better than putting the
> StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null in
> ~/.ssh/config and then teaching the eye not to see the "Warning:
> Permanently added..." message, isn't it?
>
> Peter

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
Perhaps rlogin or rsh would be a better tool? ssh wasn't designed to do this.

On Tue, Mar 3, 2009 at 8:25 PM, "Peter Valdemar Mørch (Lists)"
<4ux6as402@sneakemail.com> wrote:
> David R Green wrote:
>> Is it just the warning output you're worried about or the key
>> checking?
>
> As I tried to describe in my original post I want disable the key
> checking intentionally.
>
>> Can't you supply the "-q" switch to suppress the warning?
>
> Excellent! Or even "-o LogLevel=ERROR". Yes, that takes care of the
> warning too! Fantastic. (But it does also remove all other warnings, which
> I'm guessing might be dangerous...)
>
> So now, to disable host keys without getting warnings, I need to:
>
> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
> LogLevel=ERROR user@server
>
> Sure wish there was a simpler way to do that, such as:
>
> $ ssh --no-hostkeys user@server
> or
> $ ssh -o HostKeys=no user@server
> or
> $ ssh -o HostKeyAlias=none user@server
> or
> $ ssh -o HostKeyAlias= user@server
> or something similar
>
> But I'm assuming from this thread that there isn't. ;-) Thanks, Brian and
> David, for your time and help.
> - Show quoted text -
>
> Peter
> --
> Peter Valdemar Mørch
> http://www.morch.com
>
>



--
" ' With the first link, the chain is forged. The first speech
censured, the first thought forbidden, the first freedom denied,
chains us all irrevocably.' Those words were uttered by Judge Aaron
Satie as wisdom and warning... The first time any man's freedom is
trodden on we’re all damaged." - Picard, quoting Judge Aaron Satie
- Alex Smith (K4RNT)
- Nashville, Tennessee USA
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
Peter Valdemar Mørch (Lists) wrote:
> So now, to disable host keys without getting warnings, I need to:
>
> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
> LogLevel=ERROR user@server
>
> Sure wish there was a simpler way to do that, such as:

How about creating a stub script:

dan@parakeet ~ $ cat bin/ssh-nh
#!/bin/sh
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
LogLevel=ERROR "$@"
dan@parakeet ~ $


Or an alias:

dan@parakeet ~ $ alias | grep ssh
alias ssh-nh='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
LogLevel=ERROR "$@"'
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
Dan Wallis mrdanwallis-at-gmail.com |Lists| wrote:
> How about creating a stub script:

I do exactly that, actually. But it doesn't help when administering many
installations, many of which don't have my svn-maintained ~/bin.

What I'm asking is that this be made easier accessible from a vanilla
ssh installation instead of requiring three separate options.

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Re: Alternative to -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ? [ In reply to ]
there's not a ssh_config used by the client to do that ?



On Sat, Mar 21, 2009 at 5:32 PM, Dan Wallis <mrdanwallis@gmail.com> wrote:
> Peter Valdemar Mørch (Lists) wrote:
>> So now, to disable host keys without getting warnings, I need to:
>>
>> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
>> LogLevel=ERROR user@server
>>
>> Sure wish there was a simpler way to do that, such as:
>
> How about creating a stub script:
>
> dan@parakeet ~ $ cat bin/ssh-nh
> #!/bin/sh
> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
> LogLevel=ERROR "$@"
> dan@parakeet ~ $
>
>
> Or an alias:
>
> dan@parakeet ~ $ alias | grep ssh
> alias ssh-nh='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
> LogLevel=ERROR "$@"'
>