[20500] in Athena Bugs
Re: Athena 9.1 - SSH (sshd_config) changes
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Wed Jul 17 18:31:31 2002
Message-Id: <200207172231.SAA24675@riff-raff.mit.edu>
To: Tom Cavin <cavin@MIT.EDU>
cc: Athena Bugs list <bugs@MIT.EDU>
In-Reply-To: Your message of "Wed, 17 Jul 2002 17:57:39 EDT."
<15669.59475.279324.296603@lap1-wccf.mit.edu>
Date: Wed, 17 Jul 2002 18:31:28 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> 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
