On Fri, May 8, 2015 13:23, m.roth at 5-cent.us wrote:> Devin Reade wrote:
>> --On Friday, May 08, 2015 09:58:32 AM -0400 "James B. Byrne"
>> <byrnejb at harte-lyne.ca> wrote:
>>
>>> While attempting to debug something else I ran across this:
>>>
>>> ssh -vvv somehost
>>> . . .
>>> debug1: Connection established.
>>> debug1: permanently_set_uid: 0/0
>>> debug1: identity file /root/.ssh/identity type -1
>>> debug1: identity file /root/.ssh/identity-cert type -1
>>> debug3: Not a RSA1 key file /root/.ssh/id_rsa.
>>> debug2: key_type_from_name: unknown key type '-----BEGIN'
>>> debug3: key_read: missing keytype
>>> debug3: key_read: missing whitespace
>>>
>>> [snip]
>>>
>>> The password-less connections complete in any case but I am
>>> perplexed
>>> as to what is the problem with the root identity key that ssh is
>>> reporting.
>>>
>>> Can anyone explain to me what this means?
>>
>> IIRC there was a time when id_rsa could refer to either an
>> RSA1 key or RSA2 key. I believe ssh is first trying to read
>> the file as an RSA1 key, finding problems, and then opening it
>> as an RSA2 key. In fact, if you scroll down from there you probably
>> see a line like the following:
>>
>> debug1: identity file /home/somebody/.ssh/id_rsa type 1
>>
>> which is a successful read (note the type is 1 and not -1).
>>
>> In other words, it's nothing to worry about. The messages are
>> a bit different under CentOS 7 (I suspect you're running CentOS 6
>> on the client), but they say about the same thing.
> <snip>
> I would *strongly* recommend editing your /etc/ssh/sshd_config, and
> comment or delete the fallback, and replace it, like:
> #Protocol 2,1
> Protocol 2
>
> That way, it won't even try.
>
> mark
>
If the problem is indeed a lookup on id_rsa for an rsa1 type key then
the setting you suggest does not prevent it. All of the sshd_conf
files in our CentOS-6 systems already have that set and I believe that
it is the default setting for the distro.
# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2
However, your suggestion causes me to consider whether or not there is
a similar setting for ssh_config. The problematic key lookup occurs
on the client side of the connection. It seems unlikely that sshd
server settings on client host would have much of an effect. Indeed
there is no reason to suppose that sshd is even present.
Respecting the other recommendations offered in various messages:
These are, insofar as I can determine, already in effect. There are
no AVCs reported, the ssh connections complete as expected, and there
are no odd messages in /var/log/secure or /var/log/messages.
The user in this case is root. The problem being debugged was
automated internal network rsync transfers over ssh. All permissions,
contexts and ownerships of the associated files and directories are as
they were originally created by ssh-keygen. It seems to me likely
that these messages are the result of code in the client application
which simply reports and ploughs on when it runs into a file format it
is not expecting leaving the final determination of whether or not the
encounter is an error condition to somewhere later in the program.
Thank you for the guidance.
P.S.
Also thanks for the info on SYN in ACK, . . ., SYN. Due to the
problems some on the list are having with my emails I now find myself
avoiding simple acknowledgements of help given. But it is gratefully
received nonetheless.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
