On Tue, Sep 19, 2017 at 04:25:21PM -0400, Simo Sorce wrote:
On Tue, 2017-09-19 at 20:27 +0200, Jakub Hrozek via FreeIPA-users
wrote:
> On Mon, Sep 18, 2017 at 05:11:09PM +0200, Marius Bjørnstad via
> FreeIPA-users wrote:
> > Hi,
> >
> > When /tmp is full, it is impossible to authenticate with Kerberos.
> > Login with password over SSH and sudo don't work. Login with ssh
> > key works fine. Here is the output in the system log when I try to
> > log on via SSH with password auth (this is on RHEL 6):
> >
> > Sep 18 16:56:59 vali sshd[35157]: Set /proc/self/oom_score_adj to 0
> > Sep 18 16:56:59 vali sshd[35157]: Connection from 192.168.1.48 port
> > 49917
> > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > I/O operation failed XXX
> > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > I/O operation failed XXX
> > Sep 18 16:57:04 vali sshd[35157]: Failed password for paalmbj from
> > 192.168.1.48 port 49917 ssh2
> > Sep 18 16:57:07 vali sshd[35158]: Connection closed by 192.168.1.48
> >
> > From SSH I get:
> > Permission denied, please try again.
> >
> > The problem seems to be that Kerberos can't store its credentials
> > cache. Is this normal, and is there a way around it? Sure, ideally
> > I should limit the space usable by each user, but that doesn't help
> > when a given user needs to log in and fix their tmp usage.
>
> Well, you need to store the credentials /somewhere/...so if the
> credential storage is full, the only remaining thing is to fall back
> to
> cached passwords.
>
> Which, if they are available (through cache_credentials=True in
> sssd.conf) is what I'd expect to happen. If that doesn't happen,
> please
> post your sssd logs..
>
That should happen only if we are offline, not if krb auth fails?
Yes, you're right, sorry.
(Although we've had a request to allow to run sssd in a degraded
responder-only mode in case /var is full and the providers can't write
into the db, I guess that's what I confused the issue with)