Hello, I'm trying to set up an sftp (sshfs) service accessible to users with a normal account on a server, but which would be restricted to a subset of the directory hierarchy normally accessible to the users in question, in practice a single directory. The idea would be to allow file access to this directory with a passwordless public key, but keep rest of the users file accessible only with another, supposedly more secure key. I found a way to do this by running a separate sshd on a different port with 'ChrootDirectory /some-dir' and 'ForceCommand internal-sftp' configuration variables, but running two sshds is rather inelegent. Is there a way to force this kind of configuration to only some keys? If not, could the Match keyword be extended to match only certain keys, or even better, could a 'chrootdir' option be added to the Authorized keys format? Teemu
Teemu Ikonen wrote:> Is there a way to force this kind of configuration to only some > keys?No.> If not, could the Match keyword be extended to match only certain > keys,Yes.> or even better, could a 'chrootdir' option be added to the > Authorized keys format?Yes. I think this will be the easiest to implement. Give it a shot. Infrastructure is in place also for passing a value from options in authorized_keys. //Peter
fedora8/server
eth0:
ip: 192.168.1.2
netmask:255.255.255.0
gateway:192.168.1.1
eth1:
ip: 192.168.2.2
netmask:255.255.255.0
gateway:192.168.2.1
fedroa8/pc
eth0:
ip: 192.168.1.9
netmask:255.255.255.0
gateway:192.168.1.9
I login the server,then "ssh 192.168.1.9",is very slowly.why?
If i change eth1 to "192.168.1.x,gateway 192.168.1.1",will be very
good.
I also find execute "route",
the last line("default 192.168.2.1 0.0.0.0 UG 0
0 0 eth1" ) appears after 17 seconds;very slowly too.
kk wrote:> I login the server,then "ssh 192.168.1.9",is very slowly.why? > > I also find execute "route", > the last line ( > "default 192.168.2.1 0.0.0.0 UG 0 0 0 eth1" > ) appears after 17 seconds;very slowly too.Your system is probably trying to look up host names in DNS. Investigate the UseDNS setting in sshd_config on the server to control this in sshd. For route, try route -n Also it does not make sense to have default router set to the local IP address. If a system should not have a default route, it is best to not set one. //Peter
I have set UseDNS to no. Before set UseDNS to no,my pc connnecting to the the server is slowly too. Another server is configured as same as this server,and both are IBM x3250.But that one runs very well. I can login this server with ssh,but if login any other sshd from this server,include the server self,will be very slow,or "Connection closed by UNKNOWN". Is someting wrong with the "ssh", ?2008-10-24?"Peter Stuge" <peter at stuge.se> ?>kk wrote: >> I login the server,then "ssh 192.168.1.9",is very slowly.why? >> >> I also find execute "route", >> the last line ( >> "default 192.168.2.1 0.0.0.0 UG 0 0 0 eth1" >> ) appears after 17 seconds;very slowly too. > >Your system is probably trying to look up host names in DNS. >Investigate the UseDNS setting in sshd_config on the server to >control this in sshd. > >For route, try route -n > >Also it does not make sense to have default router set to the local >IP address. If a system should not have a default route, it is best >to not set one. > > >//Peter
Damien Miller wrote: > No, letting users chroot to arbitrary directories introduces > serious security problems. Think about hard-linking /bin/su into > a chroot on the same filesystem where an attacker has filled in > a friendly /etc/passwd. OK, so adding chrootdir option to authorized keys is a bad idea. Another way to achieve my objective, which is additional sftp file access restrictions to connections authorized with certain keys, would be to modify sftp-server to accept a directory parameter. The authorized_keys could then have 'command="sftp-server -d /home/user/stuff"' option to restrict access to /home/user/stuff. Could this be made secure so that if an attacker has a copy of the (passwordless) private key, he would not be able to access files outside the given directory? Teemu
Teemu Ikonen wrote:> > No, letting users chroot to arbitrary directories introduces > > serious security problems. > > OK, so adding chrootdir option to authorized keys is a bad idea.I think it could be made ok. Non-root filesystem, maybe even mounted noexec, not letting the user change authorized_keys. //Peter