Sylvain Beucler <[EMAIL PROTECTED]> tapota : > 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.
But make sure it does not alter the content of others keys (in some cases, it was remove the first character of the key). -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+ _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
