On Sun, Jan 02, 2005 at 04:01:51PM +0100, Mathieu Roy wrote: > Sylvain Beucler <[EMAIL PROTECTED]> tapota : > > > On Sun, Jan 02, 2005 at 03:15:44PM +0100, Mathieu Roy wrote: > >> Commit from yeupou on branch DEV_2004-12-28_Savannah (2005-01-02 15:15 CET) > >> ---------------------------------------------------- > >> > >> Comment out a test being made on the ssh key type: I'm not sure we can do > >> these test here. > >> # An ssh server can be configured to accept only specific protocols. > >> # Having Savane doing this kind of override looks way too > >> site-specific. > >> ' > >> > >> savane lib/Savannah/User.pm 1.31.2.6 > > > > From man sshd: > > AUTHORIZED_KEYS FILE FORMAT > > > > [...] > > > > Each line of the file contains one key (empty lines and lines > > starting with a `#' are ignored as comments). Each RSA public > > key consists of the following fields, separated by spaces: > > options, bits, exponent, modulus, comment. Each protocol version > > 2 public key consists of: options, key� type, base64 encoded key, > > comment. The options fields are optional; its presence is > > determined by whether the line starts with a number or not (the > > option field never starts with a number). The bits, exponent, > > modu� lus and comment fields give the RSA key for protocol > > version 1; the com� ment field is not used for anything (but may > > be convenient for the user to identify the key). For protocol > > version 2 the keytype is ``ssh-dss'' or ``ssh-rsa''. > > > > This is a test to test the validity of the key, so that user cannot > > put invalid stuff in ~/authorized_keys. > > > > It was setup by the FSF sysadmins. > > > > I wonder, do you think one could add "command=/bin/bash " in his key > > in a site that doesn't use an authorized_keys prefix (ie Gna!)? > > One could do that. And he would get exactly what he would get if he > simply runs > ssh [EMAIL PROTECTED] > > This command= option allows to force someone to use a specific command > whenever he use ssh. But it does not allow him to use this specific > command in a way is not able to generally. > > > > Is the problem, the fact you want to support SSH Protocol v1? > > I do not think we support ssh protocol v1. But I would not like > someone installing Savane not being able out of the box to get > sv_users working because he's not user ssh protocol v2, to name a > case. > > The problem with checking whether a key is valid or not it that it > forces us to reimplement what is already part of SSH. Fortunately, one > should be able to get ssh not being fooled easily with malicious > content in the authorized_keys file. > > I'm not sure the best way to secure a system is to control strictly > content of what is, in the end, a user file (it is in ~/, not > /etc/passwd). I'm not saying that's dumb but I think that a file which > is by design under user control should not be where control is being > made. Sure we can add extra control everywhere; but when we do that, > we have to think about the problem it involves. And having sv_users > not running out of the box with a specific ssh server would be a > problem, don't you think?
Ok. I'll ask Jim why this test was important, and depending on his reply, we'll reconsider the issue, including the need for $sys_authorized_keys_prefix. Meanwhile, we need it. I'm also reactivating and debugging the change in GetUserSSHKeyReal - else all keys will be rewritten, since it would include the prefix. -- Sylvain _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
