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?
Regards,
--
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
