blu.org wiki
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
GPG-Agent
by Jerry Feldman-2
::
Rate this Message:
I'm running gpg 2-2.0.4-49 with gpgme-1.1.5-31 used by claws-mail.
I'm having difficulty with gpg-agent caching my pass phrase causing me to enter it nearly every time. Before my vacation, when sending email locally, generally, I would not have to enter a pass phrase more than once a day, but at the same time, when I run through an ssh-tunnel, I would have to enter the pass phrase all the time. My gpg-agent.conf is: pinentry-program /usr/bin/pinentry-qt default-cache-ttl 86400 default-cache-ttl-ssh 86400 max-cache-ttl 86400 max-cache-ttl-ssh 86400 disable-scdaemon allow-mark-trusted -- -- Jerry Feldman <gaf@...> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
ssh - chrooting
by Mark Richards-3
::
Rate this Message:
This is probably basic, but I have done my RTFM work for the day and
cannot seem to get past this one. We use dropbear client on some remote machines (running very automated stuff). We run ssh on our server and do NOT allow telnet logins (port 23) nor do we support password authentication per se. This closes, in our view, some commonly exploited security worries. Each remote site has a unique RSA certificate and a home directory. Each remote site uses dbclient as the transport where dbclient is used by scp for getting and putting files in specific subdirectories off the home directory on the server. By sheer accident (testing by initiating a shell using dbclient) I discovered that I could cd /... cd /var/.. etc. In some cases I could even read and write files!!! Not what we had intended. Now we have n number of sites out there, all having nice keys into the production server where some hack can do who knows what. Scary part is we don't know what the impacts may be, yet. My (stupid?) assumption was that a given user logging in via ssh would be limited to their /home directory. Not so. Apparently any user coming in via an ssh certificate assigned to a specific user can still grope around, and if files/(directories) have world access, they can play. We tried a little trick: rc in the user's home/.ssh directory, containing: /usr/sbin/chroot . However it appears chroot cannot be executed by other than.. root! So, long-winded, but how might we accomplish the following: 1. Limit users to their home directory only 2. Allow users enough access so they can perform scp operations in their home directory and subdirectories off of it, and 3. Allow users to delete a file (after an scp get). This last one seems like it's suited for a shell operation but since the remotes are automated, it might be impossible. Any unix/linux file system folks out there care to chime in? Public whipping will be tolerated in order that we learn :) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Kristian Erik Hermansen
::
Rate this Message:
Other than going through a chroot ssh howto with you, how about
restricting what the remote users can do by using AppArmor? You can whitelist everything you want the binary to do... On 4/30/08, Mark Richards <mark.richards@...> wrote: > This is probably basic, but I have done my RTFM work for the day and > cannot seem to get past this one. > > We use dropbear client on some remote machines (running very automated > stuff). We run ssh on our server and do NOT allow telnet logins (port > 23) nor do we support password authentication per se. This closes, in > our view, some commonly exploited security worries. > > Each remote site has a unique RSA certificate and a home directory. > Each remote site uses dbclient as the transport where dbclient is used > by scp for getting and putting files in specific subdirectories off the > home directory on the server. > > By sheer accident (testing by initiating a shell using dbclient) I > discovered that I could cd /... cd /var/.. etc. In some cases I could > even read and write files!!! > > Not what we had intended. Now we have n number of sites out there, all > having nice keys into the production server where some hack can do who > knows what. Scary part is we don't know what the impacts may be, yet. > > My (stupid?) assumption was that a given user logging in via ssh would > be limited to their /home directory. Not so. Apparently any user > coming in via an ssh certificate assigned to a specific user can still > grope around, and if files/(directories) have world access, they can play. > > We tried a little trick: rc in the user's home/.ssh directory, containing: > > /usr/sbin/chroot . > > However it appears chroot cannot be executed by other than.. root! > > So, long-winded, but how might we accomplish the following: > > 1. Limit users to their home directory only > 2. Allow users enough access so they can perform scp operations in their > home directory and subdirectories off of it, and > 3. Allow users to delete a file (after an scp get). This last one seems > like it's suited for a shell operation but since the remotes are > automated, it might be impossible. > > Any unix/linux file system folks out there care to chime in? Public > whipping will be tolerated in order that we learn :) > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Discuss mailing list > Discuss@... > http://lists.blu.org/mailman/listinfo/discuss > -- Sent from Gmail for mobile | mobile.google.com Kristian Erik Hermansen -- "Clever ones don't want the future told. They make it." -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Mark Richards-3
::
Rate this Message:
http://howtoforge.com/chrooted_ssh_howto_debian http://ubuntuforums.org/showthread.php?t=128206&page=7 Probably same principles regardless distribution (we're on RHEL5) Well, egg removing from face. I didn't search on the obvious. Thanks Erik. Also will have a look at AppArmor. /m Kristian Erik Hermansen wrote: > Other than going through a chroot ssh howto with you, how about > restricting what the remote users can do by using AppArmor? You can > whitelist everything you want the binary to do... > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Jarod Wilson
::
Rate this Message:
On Wed, 2008-04-30 at 18:48 -0400, Mark Richards wrote:
> http://howtoforge.com/chrooted_ssh_howto_debian > http://ubuntuforums.org/showthread.php?t=128206&page=7 > > Probably same principles regardless distribution (we're on RHEL5) Yep. Been there, done that. FWIW, upstream openssh just added some native chroot support. > Also will have a look at AppArmor. Given that you're running RHEL, you might consider looking at what you can do with SELinux as well, since that's more readily available and supported on RHEL. -- Jarod Wilson jarod@... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Ben Holland
::
Rate this Message:
I believe that ssh also has an option where the user can never go up above
their login folder which is by default their home directory. I am not sure though, it's been a VERY long time since i've had to set up an ssh server/client. Can anyone varify either way? Thanks ~Ben On Wed, Apr 30, 2008 at 8:49 PM, Jarod Wilson <jarod@...> wrote: > On Wed, 2008-04-30 at 18:48 -0400, Mark Richards wrote: > > http://howtoforge.com/chrooted_ssh_howto_debian > > http://ubuntuforums.org/showthread.php?t=128206&page=7 > > > > Probably same principles regardless distribution (we're on RHEL5) > > Yep. Been there, done that. > > FWIW, upstream openssh just added some native chroot support. > > > Also will have a look at AppArmor. > > Given that you're running RHEL, you might consider looking at what you > can do with SELinux as well, since that's more readily available and > supported on RHEL. > > > > > -- > Jarod Wilson > jarod@... > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Discuss mailing list > Discuss@... > http://lists.blu.org/mailman/listinfo/discuss > This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
[JOB] open ssh upgrade with chroot
by Mark Richards-3
::
Rate this Message:
After receiving some very helpful ideas here, I've determined that the
work involved in updating sshd to provide chrooting of certain users/groups would be a project best left to a professional sysadmin. Therefore we're seeking someone to help us on a contract basis to: - review with us the security requirements and current setup - propose a solution (chroot, most likely) - provide scripting/instructions to do so which we will try on a server on our lan - refine the scripting/instructions and then apply it to our stage and then if this works our production servers. Anyone interested, please reply directly. And thank you. /mark -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Jarod Wilson
::
Rate this Message:
On Thu, 2008-05-01 at 09:39 -0400, Ben Holland wrote:
> I believe that ssh also has an option where the user can never go up > above their login folder which is by default their home directory. I > am not sure though, it's been a VERY long time since i've had to set > up an ssh server/client. Can anyone varify either way? Uhm, I believe what you just described is per-user chrooting in their home directories, which is exactly what we were already talking about... -- Jarod Wilson jarod@... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
|
|
Re: ssh - chrooting
by Dan Ritter-2
::
Rate this Message:
On Thu, May 01, 2008 at 09:39:01AM -0400, Ben Holland wrote:
> I believe that ssh also has an option where the user can never go up above > their login folder which is by default their home directory. I am not sure > though, it's been a VERY long time since i've had to set up an ssh > server/client. Can anyone varify either way? Thanks ~Ben Not in OpenSSH, which is the standard SSH server. Sounds like you are describing a chroot'ed environment. -dsr- -- http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference. "Someone is wrong on the Internet." - Randall Munroe -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list Discuss@... http://lists.blu.org/mailman/listinfo/discuss |
| Free Forum Powered by Nabble | Forum Help |
