SSH keys suddenly not working

GaijinPunch · 02-29-2008, 07:05 PM

I have a number of remote machines I connect to, and I set up my rsa keys so I don't have to type my password every time. There's one remote machine worked for months, and now, does not (prompts me for password). I've checked permissions on the ~/.ssh directory, and everything looks fine. I've double-checked ~/.ssh/authorized_keys, and it looks fine. Config file, as well, should be okay. Yet, here I am.

I ssh in with verbose output, but it's not much of a help. Just shows me "trying private key, offering public key, [fail], trying dsa key, etc.".

Any idea? In my experience, it's almost always permissions, but that doesn't seem to be the case. The other thing is the IP address not changing (didn't) or the target machine not detecting it properly. I've put my key in authorized_keys in 3 places, once by raw IP, another by hostname (as shown in /etc/hosts) and a third for safe measure as what the machine thinks is the hostname (what is shown when I run 'who').

/etc/ssh/sshd_config

Code:

       $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 11122
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel DEBUG

# Authentication:

#LoginGraceTime 120
PermitRootLogin no
StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt no
#X11Forwarding no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
PrintMotd yes
PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

DenyUsers root
DenyGroups root nossh
DenyGroups nossh

billymayday · 02-29-2008, 07:11 PM

Any chance you made the key valid for 365 days and that's passed?

GaijinPunch · 02-29-2008, 07:56 PM

Quote:

Originally Posted by billymayday

Any chance you made the key valid for 365 days and that's passed?

Definitely not. The key was made at the first of November.

anomie · 02-29-2008, 11:23 PM

Quote:

Originally Posted by GaijinPunch

I've checked permissions on the ~/.ssh directory, and everything looks fine.

Post the exact permissions for both ~/.ssh and ~ itself. (Not their contents; just the directories.)

GaijinPunch · 03-01-2008, 02:31 AM

~/.ssh: drwx------
~: drwxrwxr-x

I didn't know my homedir mattered.

jschiwal · 03-01-2008, 02:55 AM

Check /var/log/messages on the target machine. Make sure that ~/id_rsa is readable only by the user.

GaijinPunch · 03-01-2008, 04:29 AM

/var/log/messages has almost nothing about ssh in it.
id_rsa is 400 like everything else in ~/.ssh, and is owned by the user.

anomie · 03-01-2008, 11:10 AM

Quote:

Originally Posted by GaijinPunch

~/.ssh: drwx------
~: drwxrwxr-x

I didn't know my homedir mattered.

Well it does. You have made it group writable. Here's the problem with that:

Tito in your group decides to delete your .ssh directory and create his own.
He also makes his own authorized_keys file using his public key.
Now Tito can authenticate as you; successful account hijack.
From here he can put pieces back in place to make it less likely that you'll find the problem. (i.e. Appends your own public key to authorized_keys, etc.)

Remove the group writable permissions and you should be able to use pubkey authentication for this account again (assuming you don't have other unidentified issues as well). I just ran into this with a user last week.

------------------
edit: After posting this I wasn't able to reconstruct this crack on one of my own FBSD boxes. But that doesn't mean a bad guy who is lots smarter than me can't. In any event, I am sure this is what your problem is.

GaijinPunch · 03-01-2008, 06:38 PM

That was it. Moral of the story? Never forget about what Tito might do.

Cheers, from a fellow native Texan.