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