Hi all,

BACKGROUND: (Just skip to issue
===========
I would like to do the following:
There is a server on which I have git repositories.
I would like to connect via ssh to this server and keep my local repositories up to date.
I have a script and then the only thing I needed was a way to be able to keep logging in to the remote server. The server does not support public/private keys, but does allow use of the GSSAPI

ISSUE:
======
I use k5start to get a ticket for user@server.com using a local keytab file:
k5start user@server.com -f keytab
This allows me to connect to gate.server.com using ssh
ssh user@gate.server.com

However, I get permission denied on the files on the server.
This is strange because I am allowed to log in.

It becomes even stranger...
When I connect using ssh from the same system and I supply a password, I no longer have any problems with permission denied.
It only seems to matter if I logged in to the remote server and not via which user/computer/ip. The extra permission seems to be granted with some lifetime, but for the purpose of having the remote connection I would also like to renew those permissions.

So to me it seems that using k5start I do not get all the permissions that I need and some of these permissions seem to be granted only when I log in using a password.

Has anyone got a clue as to what permissions I could be lacking?
And how I could keep those permissions alive?

Best,
Hugo

There are a couple of possibilities I can think of:

The directory on the server requires forwardable tickets..(possible AFS access limitations?)

the user on the server might not be the same as specified in the service ticket... I'm not sure how the mismatch may be handled with current distributions (it used to be in a .k5login to identify permitted connections, and the entry may not permit some access.. (you might check to see what an "id" command provides on the server in that case).

But it depends on the krb5_conf specifications as to what is different - specially for the forwardable tickets, as k5start takes the default which may not have the forwardable ticket flag enabled.

Note: Though I used to be a kerberos admin, it has been a number of years since, so some things may have changed.

1 members found this post helpful.

Thanks a lot, this helped me recover the true problem, which is a missing afs token.

I checked that ticket forwarding is allowed, but I do not have AFS on my CentOS7 computer.

I guess the solution should be to use the kerberos ticket to obtain an AFS token on the server.
Or to at least keep an existing AFS token alive.

Any hints as to how to do this?

I don't know if this will help, but since you do have an AFS environment:

http://kb.mit.edu/confluence/pages/v...pageId=4981395

There they direct that the ssh command use the -K option on ssh to forward tickets as forwarding may not be the default.

It may also be that you need to get an AFS ticket before the ssh (not sure, I would think obtaining an AFS ticket would be automatic on the server, and that depends on having a forwarded ticket)

1 members found this post helpful.

I had already tried

Host gate1.server.com
GSSAPIDelegateCredentials yes

And I also tried the -K command, but I still get the same problem.
I also think this is because I lack an AFS token/ticket.
It should be possible to get a ticket with aklog.

However, On my CentOS computer I don't have AFS installed and I don't see any easy way (i.e. via repos) to do so.
Perhaps, I should just ask the admin of the server what they suggest.

The aklog would have to be run on the server.

OpenAFS has a repository for CentOS. reference:http://wiki.openafs.org/InstallingOpenAFSonRHEL/
though this was for CentOS 6.

It certainly wouldn't hurt to ask - they may have a quick solution.

The admins suggested I add the following lines to my .ssh/config for the specific host I try to connect to:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDns yes

This seems to work.

Thanks for the help.