[8120] in Release_7.7_team
Re: locked out of my debathena workstation
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Sat Mar 14 21:51:31 2015
Date: Sat, 14 Mar 2015 21:51:10 -0400 (EDT)
From: Geoffrey Thomas <geofft@ldpreload.com>
To: Jonathan D Reed <jdreed@mit.edu>
cc: Quentin Smith <quentin@mit.edu>,
Alexander Chernyakhovsky <achernya@mit.edu>,
Alex T Prengel <alexp@mit.edu>,
"release-team@mit.edu" <release-team@mit.edu>
In-Reply-To: <9220E3AA-D0FD-4733-81F6-39BE72276DC7@mit.edu>
Message-ID: <alpine.DEB.2.10.1503142148480.1824@cactuar.ldpreload.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-787859033-1218930786-1426384238=:1824"
Content-ID: <alpine.DEB.2.10.1503142150400.1824@cactuar.ldpreload.com>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---787859033-1218930786-1426384238=:1824
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.2.10.1503142150401.1824@cactuar.ldpreload.com>
Checking the enctype in the preinst with `ktutil` and aborting if it's=20
weak (which doesn't require network/KDC access, just the keytab to be=20
present on disk) seems pretty safe, unlike, say, rekeying on upgrade.
What's the behavior of the workstation autoupgrade script if the upgrade=20
aborts?
--=20
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com
On Sun, 15 Mar 2015, Jonathan D Reed wrote:
> Oh, good call. That would make sense. Unfortunately, there=E2=80=99s n=
o root password for Alex to trivially log in and fix this. We can reboot i=
nto single-user mode in person on Monday, of course. I vaguely wonder if b=
umping the key in kadmin would trigger a different failure in pam_krb5, suc=
h that Alex could log in, but I suspect not.
>
> If this turns out to be the cause, we=E2=80=99ll definitely need to do so=
me outreach (e.g. what jweiss has been doing with dialup users=E2=80=99 non=
-null instances) before this goes into production, I guarantee there are ot=
her machines out there which are in a similar state. Can a principal alwa=
ys getprinc itself? I assume running kadmin in the maintainer script is a =
terrible idea=E2=80=A6
>
> -Jon
>
>
> On Mar 14, 2015, at 8:47 PM, Quentin Smith <quentin@mit.edu> wrote:
>
>> It looks like Alex's host/dit.mit.edu principal is still single-DES; I'm=
guessing this failure is because pam_krb5 is trying to get a service ticke=
t to protect from the Zanarotti attack.
>>
>> --Quentin
>>
>> On Sat, 14 Mar 2015, Alex Chernyakhovsky wrote:
>>
>>> I checked on mkc, which is a fully updated alpha workstation (developme=
nt) and had no issues.
>>> Workstations take updates automatically, so you may have had the update=
happen while you where logged in.
>>> -Alex
>>> On Sat, Mar 14, 2015, 8:24 PM Alex Prengel <alexp@mit.edu> wrote:
>>> So Jon's reply answers this? But since I was logged in for a week =
at the
>>> time the problem started I couldn't have taken an update that migh=
t have
>>> caused this anyway.
>>>
>>> A.
>>>
>>> On 03/14/2015 12:35 PM, Alex Chernyakhovsky wrote:
>>> > Hi,
>>> >
>>> > On Friday, Ben Kaduk moved a new copy of kerberos-config to propo=
sed.
>>> > I believe that will affect the beta workstations; the notable cha=
nge
>>> > is that allow_weak_crypto got turned off. Is your Athena password=
by
>>> > any chance still using DES-only? That would explain these symptom=
s.
>>> >
>>> > Sincerely,
>>> > -Alex
>>> >
>>> > On Sat, Mar 14, 2015 at 11:25 AM, Alex T Prengel <alexp@mit.edu> =
wrote:
>>> >> Hi,
>>> >>
>>> >> I'm suddenly unable to log into my desktop machine (dit.mit.edu)=
, debathena
>>> >> workstation running Precise, since yesterday afternoon. I get
>>> >> "authentication failure" on a graphical login attempt, a ctrl-al=
t-f1
>>> >> terminal login attempt, and ssh attempts from other machines. I'=
m able to
>>> >> log into other Athena machines, both locally and by ssh without =
problems.
>>> >> I'm not sure if or when an update might have triggered this as I=
was logged
>>> >> into the machine continuously since last Monday.
>>> >>
>>> >> Has anyone else seen this on beta workstations?
>>> >>
>>> >>
>>> >> Alex
>
>
---787859033-1218930786-1426384238=:1824--
