File and directory ownership and permissions are correct. Normally I create (and expand, if necessary) the authorized_keys file by doing a cat on the existing file, if any, and the new key file. This doesn't add newlines, and none of these files have ever seen a Windows system. I did a hex dump of the current file; there's a single newline at the end of each key.
What has me confused is that I can copy any of the key files as authorized_keys and login works perfectly. Cat two or more of them together, it refuses to work. A couple of GSSAPI options were on; I turned them off and restarted sshd. Still no joy. Thanks for the tips and hints! On Fri, Oct 10, 2014 at 9:04 AM, Tilghman Lesher <[email protected]> wrote: > On Thu, Oct 9, 2014 at 5:25 PM, Curt Lundgren <[email protected]> wrote: > > All was well in Linux-land until yesterday when I added another host key > to > > .ssh/authorized_keys. It's running CentOS 6.5, a VM under VMware. > > > > .ssh/ is owned by root:root. Its files are similarly owned and both > > authorized_keys and known_hosts have 600 permissions. > > You're ssh'ing as root? The files and directory should be owned by > the same user as you're ssh'ing as. Also, did you become root with > 'sudo -s', 'sudo su -', or another command that institutes the > environment? 'sudo su' doesn't, which may mess up things like that. > > > OpenSSH is version 5.3p1. > > > > After yesterday I can use a key file from any host, just one host, and it > > works perfectly. Cat together the keys from two or more hosts and it > asks > > for a password. > > I would explicitly check for aberrant newlines in the file. If you're > looking at the file with xterm, most editors will naturally resize, > when you vary the width of the terminal. Look for lines that aren't > wrapping continuously. All individual keys should be on a single > line. I've had this problem where I manually copied a key with the > mouse, and the editor inserted a newline in the middle of a key. > > Also check for a Windows newline (\r) in any of the files. You can > remove them with: tr -d '\015' <oldfile >newfile > > > I don't have hair to tear out, does anyone have ideas what might be going > > on? We have another server that's identical except it's a physical > machine, > > it's working perfectly. > > My general inclination is that you've got a bad character in one of > the files, and as soon as ssh sees that, it aborts parsing. > > One last thing to check is that you have Kerberos and GSSAPI > authentication turned off in /etc/ssh/sshd_config. This is a Red Hat > derived platform, and they have a habit of turning alternate > authentication systems on, which may mess with authorized_keys > authentication. > > -- > Tilghman > > -- > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
