Kerberos FTP ticket filename

[Tiago Elvas]

Hi all,

I am having a problem here with the FTP authentication using Kerberos.
What is happening is that when I connect from host_A to host_B using ftp,
the acquired ticket (in host_B) is being stored as "/tmp/krb5cc_503_z2fgka".

I also had this problem in SSH logins, and it seems to be related to a
bug/feature of the PAM. To fix it, I appended a piece of code in
"/etc/profile" to rename the ticket file and set the "$KRB5CCNAME"
accordingly. However this won't fix my problem with the FTP connections.

Apart from this, the system creates a new ticket for each new connection
(as expected) but does not destroy it.

Can anybody give me a hand on this topic?
Thanks in advance.

Best regards,
Tiago

[Russ Allbery]

Tiago Elvas <tiago...@gmail.com> writes:

> I am having a problem here with the FTP authentication using Kerberos.
> What is happening is that when I connect from host_A to host_B using
> ftp, the acquired ticket (in host_B) is being stored as
> "/tmp/krb5cc_503_z2fgka".

That seems like a fine name for a Kerberos ticket cache. What problem is
that causing?

> I also had this problem in SSH logins, and it seems to be related to a
> bug/feature of the PAM. To fix it, I appended a piece of code in
> "/etc/profile" to rename the ticket file and set the "$KRB5CCNAME"
> accordingly.

What are you trying to accomplish by doing that? There is probably a PAM
option that will achieve your goal more directly, which would also help
with the FTP connection, but I don't understand what that goal is.

--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

[Tiago Elvas]

Hi Russ,

Thanks for your reply!

Firstly, as for the SSH connection, I need the ticket to have a controled
name, and not a randomized one. That problem is fixed by my patch.

As for the FTP problem, the thing is that when I logout from the FTP
connection, the system does not delete the ticket file, and so I have
hundreds of tickets there.

When I login/logout in SSH, the ticket gets deleted; but in the FTP it
doesn't.. That's the problem... :)

Best regards,
Tiago

[Russ Allbery]

Tiago Elvas <tiago...@gmail.com> writes:

> Thanks for your reply!

> Firstly, as for the SSH connection, I need the ticket to have a
> controled name, and not a randomized one. That problem is fixed by my
> patch.

Depending on what PAM module you're using, you may be able to set ccache
in the PAM options to the file name pattern that you want to use.

> As for the FTP problem, the thing is that when I logout from the FTP
> connection, the system does not delete the ticket file, and so I have
> hundreds of tickets there.

Oh, okay. This sounds like a bug in your FTP server (specifically, it's
not calling pam_end in the same process context as pam_setcred). What FTP
server are you using?

[Tiago Elvas]

As for the SSH, could you tell me how to accomplish that? In my initial
attempts I believe I tried to set ccache name and dir but without success.

The ftp server is vsftpd. Does this help?

Thanks,
Tiago

[Russ Allbery]

Tiago Elvas <tiago...@gmail.com> writes:

> As for the SSH, could you tell me how to accomplish that? In my initial
> attempts I believe I tried to set ccache name and dir but without
> success.

Which Kerberos PAM module are you using?

> The ftp server is vsftpd. Does this help?

vsftpd's source appears to do the right thing. Try adding debug to the
PAM options line for vsftpd and see what syslog says about what's
happening. You should see a pam_auth -> pam_setcred -> pam_open_session
sequence at the start and a pam_close_session at the end of the FTP
session.

[Tiago Elvas]

I am not sure I fully understand your indications so I paste the contents
of the files:
/etc/pam.d/vsftpd

> #%PAM-1.0
> session optional pam_keyinit.so force revoke
> auth required pam_listfile.so item=user sense=deny
> file=/etc/vsftpd/ftpusers onerr=succeed
> auth required pam_shells.so
> auth include system-auth
> account include system-auth
> session include system-auth
> session required pam_loginuid.so


/etc/pam.d/system-auth

> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth required pam_env.so
> auth [success=done new_authtok_reqd=done ignore=ignore default=bad]
> pam_krb5.so minimum_uid=500
> auth sufficient pam_unix.so nullok try_first_pass uid < 500
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth required pam_deny.so
> auth required pam_tally.so onerr=fail no_magic_root
> account [success=done new_authtok_reqd=done ignore=ignore default=bad]
> pam_krb5.so minimum_uid=500
> account required pam_unix.so uid < 500
> account sufficient pam_succeed_if.so uid < 500 quiet
> account required pam_permit.so
> account required pam_tally.so per_user deny=5 no_magic_root_reset
> password requisite pam_cracklib.so try_first_pass retry=3
> password [success=done new_authtok_reqd=done ignore=ignore default=bad]
> pam_krb5.so minimum_uid=500
> password sufficient pam_unix.so md5 shadow nullok try_first_pass
> use_authtok remember=7
> password required pam_deny.so
> session optional pam_keyinit.so revoke
> session required pam_limits.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session optional pam_krb5.so minimum_uid=500
> session required pam_unix.so

[Russ Allbery]

Tiago Elvas <tiago...@gmail.com> writes:

> I am not sure I fully understand your indications so I paste the contents
> of the files:
> /etc/pam.d/vsftpd

>> #%PAM-1.0
>> session optional pam_keyinit.so force revoke
>> auth required pam_listfile.so item=user sense=deny
>> file=/etc/vsftpd/ftpusers onerr=succeed
>> auth required pam_shells.so
>> auth include system-auth
>> account include system-auth
>> session include system-auth
>> session required pam_loginuid.so

It looks like you're probably using Red Hat's pam_krb5 module, which is
probably why setting ccache didn't do what you want. If you wanted to
pursue that, I think the ccache directive of mine:

http://www.eyrie.org/~eagle/software/pam-krb5/

is a bit more flexible, but I'm not positive. I haven't looked at what
options Red Hat supports for ccache settings for a while.

Anyway, to debug your vsftpd problem, add "debug" to the end of the
pam_krb5.so lines in your system-auth configuration file and then check
syslog after an FTP login. I'm not sure what output the Red Hat module
produces by default, but hopefully it's still enough to figure out whether
the session is being closed properly and if there are any errors in doing
so.

[Tiago Elvas]

Still no success.
I tried adding the debug option but no conclusing messages shown..

Any other thoughts?

[Nalin Dahyabhai]

On Tue, May 21, 2013 at 10:31:22AM +0200, Tiago Elvas wrote:
> Still no success.
> I tried adding the debug option but no conclusing messages shown..
>
> Any other thoughts?

You may need to configure syslog to log LOG_DEBUG messages, if you
haven't.

Alternately (or also), add calls to pam_warn.so (likely with the control
set to "optional") to the configuration to verify that vsftpd's at least
calling into the right PAM functions.

HTH,

Nalin