temporarily disable StrictHostChecking an allow passwordauth via keyboard?

[peter pilsl]

I use ssh for communication between all my servers I and I love
StrictHostChecking cause it makes me feel secure.

But frequently I would really prefer to disable it for a single-session
in the following scenario:

* one of the servers in the local LAN goes down and needs to be fixed
* I boot with a linux-rescue-disk and the server fetches its IP via DHCP
which is the same IP that the original server has
* I try to access this linux-rescue-booted-server from my comfy
workplace and I cannot do it because the host-key has changed

Removing the hostkey on my comfy workplace is bad cause I would need to
put it back later and thats more work then I want to invest. Usually I
just remove it and let ssh add it later which actually weakens my
securityy cause a possible attacker could choose this very moment to
perform a ManInTheMiddle-attack.

I tried:

ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication yes"
ro...@vmhost.local

but it doesnt work:

Offending key in /home/peter/.ssh/known_hosts:10
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid
man-in-the-middle attacks.
Permission denied (publickey,password).

And my standard-rescue-disk has ssh enabled but no public key installed.

any idea?

thnx,
peter

[Darren Dunham]

peter pilsl <pi...@goldfisch.at> wrote:
> I tried:
>
> ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication yes"
> ro...@vmhost.local
>
> but it doesnt work:
>
> Offending key in /home/peter/.ssh/known_hosts:10
> Password authentication is disabled to avoid man-in-the-middle attacks.
> Keyboard-interactive authentication is disabled to avoid
> man-in-the-middle attacks.
> Permission denied (publickey,password).

Right. Because "StrictHostKeyChecking" only affects whether keys are
added to the known_hosts file. It doesn't affect existing keys.

> And my standard-rescue-disk has ssh enabled but no public key installed.
>
> any idea?

Change the known_hosts file temporarily so there is no existing key.

> ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" -o
"PasswordAuthentication yes"

Or put all that into a config file and use that alternate config file:

ssh -F insecure_config <temphost>

If you use a global known_hosts file rather than just the per-user one,
you'll need to override it as well.

--
Darren

[peter pilsl]

Darren Dunham wrote:
>
> Change the known_hosts file temporarily so there is no existing key.
>
>> ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" -o
> "PasswordAuthentication yes"
>

thats perfect and exactely what I was looking for.

thnx
peter

[va...@mindsandmachines.com]

> peter pilsl wrote:
> ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" -o
> "PasswordAuthentication yes"

Thanks

[NiYa193]

在 2009年6月4日星期四 UTC+8上午12:30:38，Darren Dunham写道：

Thanks.
This command helps me.

[William Unruh]

On 2020-07-10, NiYa193 <15565...@qq.com> wrote:
> 在 2009年6月4日星期四 UTC+8上午12:30:38，Darren Dunham写道：
>> peter pilsl <pi...@goldfisch.at> wrote:
>> > I tried:
>> >
>> > ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication yes"
>> > ro...@vmhost.local
>> >
>> > but it doesnt work:
>> >
>> > Offending key in /home/peter/.ssh/known_hosts:10
>> > Password authentication is disabled to avoid man-in-the-middle attacks.
>> > Keyboard-interactive authentication is disabled to avoid
>> > man-in-the-middle attacks.
>> > Permission denied (publickey,password).
>>
>> Right. Because "StrictHostKeyChecking" only affects whether keys are
>> added to the known_hosts file. It doesn't affect existing keys.
>>
>> > And my standard-rescue-disk has ssh enabled but no public key installed.
>> >
>> > any idea?
>>
>> Change the known_hosts file temporarily so there is no existing key.
>>
>> > ssh -o "StrictHostKeyChecking no" -o "UserKnownHostsFile /dev/null" -o
>> "PasswordAuthentication yes"
>>
>> Or put all that into a config file and use that alternate config file:
>>
>> ssh -F insecure_config <temphost>
>>
>> If you use a global known_hosts file rather than just the per-user one,
>> you'll need to override it as well.

Or you can erase line 10 of the knownhosts file. It is probable that the
destination changed their ssh credentials and ths the problem If you
know they have not, then this is probably a man-in-the-middle attack and
you just gave away your password to an attacker.