CVS, SSH, secure, chroot etc

jonathan soong jon.soong at imvs.sa.gov.au
Fri May 23 12:14:20 CST 2003


thanks for the suggestion Andrew, i did have a look there.

In the end i've done it another way.

SECURE CVS without multiple unix accounts

1. make user 'cvsd'  who has r/w access to the CVS repository
2. set 'cvsd's shell to /bin/bash (or some proper shell) in /etc/passwd
3. set 'cvsd's password to * in /etc/shadow
4. have all developers who are using the CVS generate an ssh key 
('ssh-keygen -t dsa') and send you the public key
5. put an entry in 'cvsd's /home/cvsd/.ssh/authorized_keys2 file that 
looks like:
    command="/usr/bin/sleep 3h" ssh-dss ASDFASDFAKdjkjidf8+... == 
jon at here.com
    // this forces the 'command' to be executed as soon as the person 
logs in

Now only those developers who have sent you keys will be able to login 
(passwordless) to the CVS machine and will be automatically be dumped to 
sleep for 3 hours - this will keep the ssh port forward open.

Now i can securely use CVS's pserver user management, without multiple 
unix users.

Anyone have any thoughts on the security implications of forcing the 
users to execute 'sleep 3h'
e.g. can this be broken by sending weird signals?

Cheers,

Jon


Andrew Reid wrote:

>On Thu, 2003-05-22 at 12:54, jonathan soong wrote:
>
>  
>
>> >>The Problem:
>>CVS on a public server, that we want external developers to be able to 
>>access - securely.
>>    
>>
>
>You know about SourceForge, right? They run one of the biggest public
>CVS servers going around, and they give secure access to developers
>through SSH.
>
>  
>
>> >>Conditions:
>>_Cannot_ have multiple shell accounts on the machine.
>>    
>>
>
>Is this a security thing? You can tie the account down such that it can
>only execute CVS and SSH.
>
>  
>
>>Must have read/write access on the machine
>>
>> >>Current Thinking:
>>1. Chroot CVS. - (done)
>>2. Use pserver, but somehow secure it - (working on..)
>>    I have setup pserver, and will use pserver's user management to 
>>avoid lots of shell accounts.
>>    I want to use an ssh tunnel to protect pserver's passwords.
>>    
>>
>
>But there's the thing -- you'll need local accounts (or something PAM
>compatible) for users to be able to SSH in.
>
>I'd be having a look at the way SourceForge have done it and seeing if
>you can apply similar principles to your setup.
>
>  
>
>>    Hence, i want users to be able to create an ssh tunnel into my 
>>machine with a public password.
>>    (i.e. a generic account, which can't do anything - once on the 
>>machine, i want the users to be
>>    forced to login via pserver's authentication and be restricted to 
>>cvs commands).
>>    
>>
>
>See, this is where I don't see why you'd bother. All this achieves is
>secure transmission of the CVS data. Why not just take the extra step
>and use SSH alone for doing CVS? It's not that hard to setup -- I'd
>argue that it's easier to setup than pserver.
>
>You're already going to be going to some lengths to secure the account
>and limit it to SSH/CVS. It'd be just as easy (if not easier) to
>continue along that line.
>
>[ ... ]
>
>  
>
>>    Anyone have any  thoughts about this? Am i missing something glaring 
>>obvious.
>>    
>>
>
>I feel you're making the situation harder than it needs to be. Have a
>look at the way SourceForge provide developer access and see if that's
>got any merit for your situation.
>
>   - andrew
>
>  
>

-- 
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.freenode.net
To unsubscribe from the LinuxSA list:
  mail linuxsa-request at linuxsa.org.au with "unsubscribe" as the subject



More information about the linuxsa mailing list