# Failed connection with scp

## paradigm-X

I find it convenient to use 'scp' to transfer files from the host to a guest, or to retrieve files from the guest, especially with NAT interfaces because it works even when the guest is disconnected from all the rest of the LAN for whatever reason. Recently I had a problem with this procedure, for which I cannot understand the cause. So I just ended up working around it instead of properly solving it because I was pressed for time, and because patience is not really a virtue of mine.   :Razz: 

Previously I had made an scp connection with a particular guest, and its authentication file was put into '/known_hosts' when I did. Then I needed to reinstall the guest and reconnect with scp. While trying to do so, I was getting an authentication warning about its RSA fingerprint having changed and that I could not establish another connection because I have "strict checking" set. However, I double-checked the host's '/etc/ssh/ssh_config' file to see the setting for "StrictHostKeyChecking", and it was assigned the value "ask", both by default apparently and by the fact that I specifically uncommented this line. I am not aware of another parameter in this configuration file, or elsewhere, capable of overriding StrictHostKeyChecking option. If anyone has an idea concerning this issue, I would appreciate hearing about it.

As it is, I simple removed the offending entry in the 'known_hosts' file and made the connection regardless. Both of these hosts are under my control on the same machine on the LAN.

-----------------

Despite the fact that the local admin has graciously assigned me a new appelation of "Tux's lil' helper", I have to question his judgment in this regard because I do still feel like a "noob" more often than I care to admit!  Nevertheless, with all due respect I shall accept his learned decision and do my best to live up to his due! Gracias, amigo, muchas gracias.   :Smile: 

----------

## Hu

Could you explain what you want to know?  According to the man page, you received exactly the expected result.  You were asked about the key when it was new, and warned+refused when it was known to be different from what was presented.

----------

## paradigm-X

Hello, Hu.

"I double-checked the host's '/etc/ssh/ssh_config' file to see the setting for "StrictHostKeyChecking", and it was assigned the value "ask".

You see, if I have the setting on "ask", then it seems to me I should be asked something about whether I want to make a connection with the other host, and, naturally, be given the opportunity to connect based on my response. However, I was not asked anything. I was simply advised that the host key was invalid and then disconnected. The refusal occurred both whe comment and uncommented settings were in place. What am I missing?

----------

## Hu

The manual page states: *man 5 ssh_config wrote:*   

>  If this flag is set to ``ask'',
> 
>              new host keys will be added to the user known host files only
> 
>              after the user has confirmed that is what they really want to do,
> ...

 You were asked whether to connect when the host was unknown.  When the host was known and presented the wrong host key, you were refused a connection, exactly as designed.  Hosts do not change their ssh keys lightly, so users should not lightly accept unexpected keys.

----------

## paradigm-X

Yes, I see now the error of my ways.  I merely interpreted the scope of its asking a bit too liberally.  Well, excellent then! Thanks for the clarification, Hu.

----------

