[20502] in Athena Bugs
Re: Athena 9.1 - SSH (sshd_config) changes
daemon@ATHENA.MIT.EDU (Tom Cavin)
Wed Jul 17 19:01:15 2002
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15669.63289.440401.909518@lap1-wccf.mit.edu>
Date: Wed, 17 Jul 2002 19:01:13 -0400
From: Tom Cavin <cavin@MIT.EDU>
To: Garry Zacheiss <zacheiss@mit.edu>
Cc: Tom Cavin <cavin@mit.edu>, Athena Bugs list <bugs@mit.edu>
In-Reply-To: <200207172231.SAA24675@riff-raff.mit.edu>
Hi Garry,
You're right. The /etc/sshd_config,v file was ours. My mistake.
I'm going to have to look into SSH v2 for the other systems I support that
aren't running Athena. All the work I duplicate on those systems really
makes me appreciate the vast number of things I *don't* have to do with my
Athena system thanks to the Athena development team. :-)
The reason I've used RSAAuthentication in the past is for those cases when
I need to fix something as root on a system without srvtabs or on a
non-Athena system. I'm changing my policy to include srvtab/krb5.keytab
files on all my Athena systems. However I'm still stuck with a bunch of
non-Kerberized systems for the indefinite future. :-(
Thanks for the answers.
--Tom
Garry Zacheiss writes:
> >> The first thing I noticed is that the file is apparently under RCS control
> >> (with the /etc/sshd_config,v file), and the installed version is different
> >> from the latest version in the RCS file.
>
> We maintain our source tree in CVS, not RCS; sshd_config is certainly
> revision controlled, but nothing is going to be installed
> /etc/sshd_config,v, so if you have such a file, you put it there
> yourself. As it happens, there is a newer version in our repository
> than is present in 9.1.11; the newer version will go out in 9.1.12.
>
> >> The second thing I noticed is that the format now seems to use both ssh
> >> protocol version 1 and version 2. I assume that this is a good thing, and
> >> I am wondering about the differences.
> >>
> >> What are the benefits of protocol version 2 over the previous version?
>
> The SSH v2 procotol is a better designed protocol, more
> cryptographically sound, and has fewer theoretical vulnerabilities. It
> also has a few more interesting features such as sftp, an interactive
> ftp-alike via ssh. There are some popular client programs out there
> that only support v2 of the SSH protocol, which is the primary reason we
> wanted to have it deployed.
>
> >> The third thing I noticed is that RSAAuthentication is turned off by
> >> default. Up until this point I had been using RSAAuthentication via
> >> ssh-agent with /root/.ssh/authorized_keys files to gain root access on the
> >> systems that I support that do not have their own srvtab records. (I use
> >> the same technique to access non-Athena Unix systems.)
>
> RSA Authentication was disabled under 9.0 and previous Athena
> releases as well. If it was enabled on your machine, it's because you
> manually enabled it. You can of course continue to do so if you like;
> we disable it's not possible to enable it on a per-account basis, and
> allowing people to RSA Auth into Athena machines would result in them
> not having Kerberos tickets and AFS tokens on the other end, which is
> confusing and potentially a support hazard.
>
> >> If so, is there another preferred method of granting such access for
> >> systems without srvtab or krb5.keytab files?
>
> The preferred method involves giving remotely accessible machines a
> kerberos keytab and logging in using a principal listed in root's
> .k5login file.
>
> >> Is the "PubkeyAuthentication" the equivalent for protocol version 2?
>
> Yes.
>
> >> I'd be delighted to have either answers to these questions or pointers
> >> to the documentation. I still need reasonable root access to a large
> >> number of systems with different root passwords and would like to be
> >> able to use something like the old ssh-agent/RSAAuthentication scheme
> >> for the hosts I support that don't have srvtabs.
>
> Restoring your local modification to the sshd_config to enable RSA
> authentication should work fine. In the long term, were I you, I would
> look into getting keytabs for all of the machines you maintain remotely.
>
> Garry
