# ssh key auth fails with remote home on afs [solved]

## Oo.et.oO

Hi all, 

    i'm at a loss this time.   I have several linux servers of various types that i ssh/scp/rsync to often and for various reasons.  for most of them i use public key authentication and it works great and as i expect. 

   there are a few, however, upon which i do not have root access, that i just can't get key authentication to work on.  i can log-in interactively with a password just fine.  

there are several possibly compounding factors that may be preventing this.   on these servers that don't work, my home is mounted via afs.  i've set my .ssh directory and authorized_keys(2) to world readable as well as world readable via afs (fs sa).

here is the only debug/verbose info i could get using ssh -vvv:

```
debug2: key: /home/erict/.ssh/id_rsa (0x13141b0)

debug2: key: /home/erict/.ssh/id_dsa (0x1315940)

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

debug3: preferred publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/erict/.ssh/id_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password

debug1: Offering public key: /home/erict/.ssh/id_dsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: remaining preferred: ,password

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

```

i guess i can try forwarding my afs/kerberos token..

rebuilt openssh with kerberos use flag.  didn't do any good. not surprised.

i just noticed that the above verbose output says "Offering public key: /home/erict/.ssh/id_dsa"   but that file is my private key, that ssh_keygen produced.   wth?   i think that must be an implied filename?  

if i use -i to specify the pub key, it doesn't work either.

any ideas at all would be a huge help

thanks!Last edited by Oo.et.oO on Wed Oct 27, 2010 2:47 pm; edited 1 time in total

----------

## eccerr0r

What would be ideal is the log from the server receiving your ssh request...

But I suspect that sshd is complaining about permissions.

It's been over a decade since I had access to an AFS cell.  But I recall you can still chmod files and directories like regular unix files/directories.  Permissions on these need to be just as they would appear on a non-AFS machine, though the home directory still needs to be directory listable as well as the .ssh directory being world readable via afs...

If the permissions on the path up to the home directory are world writable (but AFS permissions trump)... then you may be SOL on this and have to get the SA to fix it...

That is if the sshd isn't afs aware... is it?

----------

## Oo.et.oO

thanks for your reply.  

others can read/list my .ssh/authorized_keys(2) files (but they have afs tokens) 

i just don't know how sshd acts when $HOME is /afs/cell/u/userid

i have .ssh afs acl set so anyuser can read and list.

i could TRY to read the sshd log, but i doubt that is going to be possible.  i don't own/administer these machines.

even if i could tell the SA to "fix it".  what do i tell them to fix?

some of these SAs are notoriously thick and will undoubtedly think i'm trying to lessen their security.  HA

it appears publickey auth is turned on, based upon the -vvv output above

----------

## Oo.et.oO

interestingly enough i can run dmesg.   but of course there is nothing in there for sshd.

i don't have access to /var/log/security not surprisingly.

----------

## eccerr0r

Do you know if that system's sshd is afs aware or not?  Is it known if it will grab afs tokens for you (else you will need to klog or whatever it was, to access write perms to your account?)

what are the permissions (UNIX ugo permissions) of all directories leading up to your home directory, as well as your .ssh directory, despite they not being honored by AFS?

One rule of "standard" sshd is if any directory is writeable by anyone but the owner or root of all directories through .ssh it will deny access...

This doesn't quite make sense for afs as ACLs determine the real permissions... hence the afs-aware sshd or not...

----------

## Oo.et.oO

i don't know how to check if the ssh servers are afs aware or not.  however, i never explicitly klog, and this isn't in my .profile/etc.  but it could be in the host level configs, but i don't see it in /etc/profile (host is most probably a rhel machine)

supposedly even if they are, from my understanding this means they are compiled with the kerberos stuff.

in this case they don't klog for you, they just accept forwarded afs tokens from the client prior to auth.

i tried compiling my ssh client with kerberos flag turned on.  this of course did nothing, even though passing afs tokens is supposedly "on" by default.

but again, if my .ssh folder is world read/listable, then i shouldn't need afs tokens to access my authorized_keys files.

.ssh is not set world writable, nor is anything in it.  i'm not sure what you mean by "leading up to" since i don't have control of the parent directories and i have a few directories that are world/group writable with quota limits on them in my home.

----------

## eccerr0r

 *Oo.et.oO wrote:*   

> i'm not sure what you mean by "leading up to" since i don't have control of the parent directories and i have a few directories that are world/group writable with quota limits on them in my home.

 

Yes, that's exactly why a SA needs work with them.  I've seen some directories in afs cells with 777 permissions, though it seems insecure, AFS ACLs still gives security to them.  But sshd might see that 777 and prohibit people from using public key authentication... and thus out of your control to get public key working.

But once again, I would imagine an AFS-aware sshd would know about this and ignore it.  But if it's kerberos-only sshd, then that's a different story.

----------

## Oo.et.oO

i dont' think there is a difference btwn afs/kerberos aware sshd.  but i could be wrong.   that's just the use flag that gentoo uses.

so yeah, my remote afs/home dir is set to 777.   not sure if this is the issue, but i guess i can try by setting my local home dir to 777 on a virtual host and try to ssh into it using keys.

u is set to 776

----------

## eccerr0r

That's what the regular sshd will barf on, if your /home directory is 777 it will fail.  All directories leading to and your home dir must not be writeable by anyone but the user, and the .ssh directory must not be readable by anyone but you *with traditional UGO permissions*.

Of course this does not mean insecurity for AFS.  But if the directory /afs/cell is 777, you can't change it, and if sshd checks it... it's instant fail for key based login and there's nothing a non SA can do about it.

----------

## Oo.et.oO

none of the afs docs say anything about the permissions of home, just .ssh.  

and this works!   of course i DO have access to change the permission on my user $HOME.  duh.

i'll have the SA update it for everyone else/new people.

thanks!!

----------

## eccerr0r

cool... just as clarifcation, for traditional sshd...

if your path to your ssh authorized_hosts is

/big/long/path/to/home/you/.ssh/authorized_hosts2

all directories of /big/long/path/to/home = must not be writeable by anyone but root (or some system account, I don't remember all the details)

/big/long/path/to/home/you = must not be writeable by anyone but you... since you own this directory, you can chmod it.  Also you must own your own $HOME.

/big/long/path/to/home/you/.ssh must not even be readable by anyone but you.

This all is somewhat confusing with AFS thrown in because UGO permissions are not honored by AFS but rather by tokens/ACLs... but each directory still has UGO permissions for backward compatibility.

----------

## Oo.et.oO

actually my .ssh directory is world readable both in unix and afs and has to be because ssh does auth before any afs klog stuff.  so either the afs token has to be passed by the client AND accepted by the server (which one or the other of mine is not doing) and/or that dir needs to have read access.

now that i think about it, maybe it doesn't need read access using unix perms.  it would also help keep people out of you private keys if the below is true.

this makes a mess if you want to keep private keys on that machine and/or you share a common home directory with that machine (as is the case in many afs environments).   this can be worked around by keeping your private keys somewhere else and specifying them to ssh with -i

i don't share a home dir between client and server in this case and rarely ssh from remote host to remote host so i don't need private keys over there.

----------

## eccerr0r

Yes, private keys need to be in a different directory indeed...

I recall there's also a "system" account access token that matches root, so you can leave "system" account access but not "anyone" in.   Of course this is violated when people can attach their own machines with their own root to the system... still better to leave private keys in their own, user only directory.

These are all paranoia checks to make sure someone can't pull a fast one and change your authorized hosts list... just that it might not be aware of ACLs also help protect them.

----------

