First, I feel very silly.
For fun/slight profit, I rent a vps which hosts an email and web server and which I use largely as a study aid. Recently, I was in the middle of working on something, and managed to lose connection to the box directly after having accidentally changed the ownership of my home folder to an arbitrary non-root, incorrect user. As ssh denies root, and anything but pubkey authentication, I'm in a bad way. Though the machine is up, I can't access it!
Assuming this is the only issue, a single chown should fix the problem, but I haven't been able to convince my provider's support team to do this.
So my question is this: have I officially goofed, or is there some novel way I can fix my setup?
I have all the passwords and reasonable knowledge of how all the following public facing services are configured:
Roundcube mail
Dovecot and postfix running imaps, smtps and smtp
Apache (but my websites are all located in that same home folder, and
so aren't accessible - At least I now get why this was a very bad idea...)
Baikal calendar setup in a very basic fashion
phpMyAdmin but with MySql's file creation locked to a folder which apache isn't serving
I've investigated some very simple ways to 'abuse' some of the other services in a way that might allow me either shell access, or some kind of chown primitive, but this isn't really my area.
Thanks!!
None of these will help you, at least of the services you listed none have the ability to restore the permissions.
All the VPS providers I've used give "console" access through the web interface. This is equivalent to sitting down at the machine, including the ability to login or reboot in recovery mode. Your hosting provider probably offers some similar functionality (for situations just like this, or for installing the operating system, etc), and it is going to be your easiest and most effective means of recovery. Log in there as root and restore your user's permissions.
One thing struck me as odd,
I haven't been able to convince my provider's support team to do this.
Is that because they don't want to do anything on your server which you aren't paying them to manage, or because they don't understand what you're asking? The latter would be quite odd to me, but the former scenario would be very typical of an unmanaged VPS setup (you have root, console access, and anything more than that is your problem).
Related
I read this recommendation in the installation guidelines from Symfony:
1. Use the same user for the CLI and the web server
In development environments, it is a common practice to use the same UNIX user for the CLI and the web server because it avoids any of these permissions issues when setting up new projects. This can be done by editing your web server configuration (e.g. commonly httpd.conf or apache2.conf for Apache) and setting its user to be the same as your CLI user (e.g. for Apache, update the User and Group values).
This is only good practice for local development environments or should I do this on my public test & prod server as well? To me this doesn't seem as a very secure configuration?
Questions Can I safely follow this recommendation on a prod server? What are the risks, if there are any?
This recommendation give an easy alternative to avoid the common permissions problem.
I would prefer setup the web server permissions correctly once and keep the default webserver group/user.
The documentation has a good guide to achieve this.
EDIT
You shouldn't make your CLI user as your webserver user, especially in production because it opens you up to all kinds of potential abuse.
The whole point of the www-data user is that it is an unprivileged user, by default not able to write to any file .
Your CLI user is most often root, also keep the www-data user as the web server owner protect you from bad manipulations that can involves a lot of problems and potential security issues.
Plus, if your webserver is under an attack, other services which depends on the same user can be also compromised.
Server daemons accessible from the outside network (such as the web server) typically run as an unprivileged user so that in the event that they are hacked due to a vulnerability, the possible things the attacker can do is minimal.
So I'm setting up a dedicated server using Debian 5 Lenny. I will be using some Atlassian Tools (JIRA, Confluence, Bamboo, and Fisheye). I want to use a local LDAP server to store information for the users that will be accessing these software titles, so that they can use one set of credentials to log in.
I also want webmail users to be configured using LDAP.
However, this is a small operation. Three people. That's why all of the software, including the ldap server, will all be on the same machine.
That said, is it safe to use LDAP to store user credentials (including passwords) in LDAP without using Kerberos? I'm confused as to when Kerberos should be used.
Hypothetically, let's say I had two servers on a subnet. Server A received requests from the outside world, for atlassian tools. Server a communicates to ldap server (internally) on server b. In that case, would I use kerberos?
When do I use Kerberos? When do I not?
I am not setting anything like "Active Directory" up. No Samba either. Users do not need to login to a domain (with access to files on the domain), they just need to login to webapps. But if I was doing LDAP on it's own dedicated machine, then I might want Kerberos?
:confuzzled: :(
-Sam
The simplest possible answer is yes, it is possible to store user names, user ids, and passwords without using Kerberos, and in fact directory services accessed via LDAP are an excellent tool for storing this sort of authentication and authorization information.
Update:
In my opinion, if you do choose an open source server, you will find OpenDS to be superior to OpenLDAP or Apache.
Basically, if you have Kerberos, you do not need any directory server. If you aren't in a corporate environment and are looking for an identity management store, you should definitively go for a directory server like OpenLDAP or Apache Directory. Kerberos require running a correctly set up DNS and NTP server. This might be way to much. Even if you do, those lazy morons from Atlassian still did not implement Kerberos support into their products. You can't even go with that.
I just noticed that there are only three of you, maybe a simple database setup with MySQL would suffice instead of running a full-blown directory server?
Please correct me if I am wrong about my understanding of mod_dav_svn, which is that it basically serves 2 purposes:
Expose the SVN repository (on the filesystem) to clients, which can be either:
repository browsers (e.g. web)
the 'svn' command itself, which is a client command line program
Act as a repository browser to make the repository viewable in a convenient way
Now for point 1, are my following assumptions correct?
Anytime a repository is exposed using mod_dav_svn, the http:// or https:// form of accessing the repository is used
If using svnserve, the svn:// form of accessing the repository is used
In this case, mod_dav_svn would serve no additional use
For point 2, if using Trac's repository browsing functionality, there is no additional use for the repository browsing functionality offered by mod_dav_svn?
Does mod_dav_svn serve any other purpose I haven't outlined here? Asked another way, is there any disadvantage to going with svnserve and Trac?
I ask because I get the impression that mod_dav_svn is very commonly used, so I wonder what I'm missing.
Forget Point #2: HTTP Browsing. That's just a slight bonus. It doesn't replace your need for something like Fisheye, ViewVC, or (my favorite) Sventon.
There are some disadvantages of using Apache's http for your Subversion server:
It's slower
It's harder to setup
Then, there are advantages:
It uses a standard port (80) that's not normally blocked by firewalls.
It can be integrated with LDAP and Active Directory
You can use HTTPS which will encrypt updates and checkouts (including user passwords).
You can have multiple repositories use the same Apache httpd instance. With svnserve, you can only do a single repository per instance and if you have multiple repositories on one system, you'll have to run each svnserve process on a non-standard port.
My personal take: If you are doing a corporate environment, the advantages of using the HTTP or HTTPS protocol way outweigh the disadvantages. If you are talking about a small repository and you and your friends, I run svnserve simply because of the lower overhead and easier setup. However, in those circumstances, I just use Github and not worry about it.
I run Subversion as my personal source control system on my machine, and I use svnserve in that instance.
Thanks, some follow up questions. 1) When I access a URL on my svn server as svn://server/repo, isn't that using port 80 as well? 2) If LDAP integration can't be done for svnserve, is the only way users can authenticate is if they're in the file referred to by password-db in svnserve.conf for svn:// or have a shell account for svn+ssh://? 3) Can't the same protection offered by https:// be offered by svn+ssh://, or is there a difference? (Sorry I can't put paragraphs here it submits every time I hit enter am I doing it right.) –
It's using port 3690 by default. This can be changed when you run svnserve, but then your svn URL has to reflect that too.
Pretty much true. Most places that use svnserve use the passwd file. However, since version 1.5, you can use SASL. However, I have never seen anyone use it.
Yes, ssh+svn:// does offer encrypted packets. However, SSH can be tricky to implement. Basically, the svnserve process has to be spawned and run for that particular user. That means each user needs direct read/write access to the repository. You need to setup umask for each user and create a Subversion Unix group everyone belongs to. Then, since these users have direct access to the repository files, keep them from logging onto the repository server. The Online Manual has complete details. But, in the end, it only works on Unix servers and Unix clients. Windows clients don't have SSH on them, and would have to install that. I've tried it a few times, but https:// is much easier.
The simplicity of svnserve makes it a no brainer for quick and dirty installs, especially if you are deploying on Windows.
However, the moment that you need to memorize a lot of passwords, and would wish that the Subversion repository use the same SSO mechanism that is used in the organization, using Apache's authentication mechanisms coupled with mod_dav_svn helps a lot.
Prior to Subversion 1.7, mod_dav_svn's performance was said to be atrocious and known to be slower than svnserve. Subversion 1.7 supposedly offers a faster and simpler HTTP protocol which should make mod_dav_svn use more palatable.
i have following scenario and can't seem to find anything on the net, or maybe i am looking for the wrong thing:
i am working on a webbased data storage system. there are different users and different places and only certain users are allowed to access certain parts of the system. now, we do not want them to connect to these parts from at home or with a different computer than they are using at their work-place (there are different reasons for that).
now my question is: if there is a way to have the work-place-pc identify itself to the server in some way over the browser, how can i do that?
oh and yes, it is supposed to be webbased.
i hope i explained it so everyone understands.
thnx for your replies in advance.
... dg
I agree with Lenni... IP address is a possible solution if they are static or the DHCP server consistently assigns the same IP address to the same machine.
Alternatively, you might also consider authentication via "personal certificates" ... that's what they are referred to in Firefox, don't know it that's the standard name or not. (Obviously I haven't worked with these before.)
Basically they are SSL or PKI certificates that are installed on the client (user's) machine that identify that machine as being the machine it says it is -- that is, if the user tries to connect from a machine that doesn't have a certificate or doesn't have a certificate that you allow, you would deny them.
I don't know the issues around this ... it might be relatively easy for the same user to take the certificate off one computer and install it on another one with the correct password (i.e. it authenticates the user), or it might be keyed specifically to that machine somehow (i.e. it authenticates the machine). And a quick google search didn't turn up any obvious "how to" instructions on how it all works, but it might be worth looking into.
---Lawrence
Since you're going web based you can:
Examine the remote host's IP Address (compare it against known internal subnets, etc)
During the authentication process, you can ping the remote IP and take a look at the TTL on the returned packets, if it's too low, then the computer can't be from the local network. (of course this can be broken, but it's just 1 more thing)
If you're doing it over IIS, then you can integrate into SSO (probably the best if you can do it)
If it's supposed to be web-based (and by that I mean that the web server should be able to uniquely identify the user's machine), then you choices are limited: per se, there's nothing you can obtain from the browser's headers or request body that allows you to identify the machine. I suppose this is by design, due to the obvious privacy implications.
There are choices though, none of which pain-free: you could use an ActiveX control, which however only runs on Windows (and not on all browsers I think) and requires elevated privileges. You could think of a Firefox plug-in (obviously Firefox only). At any rate, a plain-vanilla browser will otherwise escape identification.
There are only a few of REAL solutions to this. Here are a couple:
Use domain authentication, and disallow users who are connecting over a VPN.
Use known IP ranges to allow or disallow access.
IP address. Not bombproof security but a start.
How can I work with Novell eDirectory services in J2SE? Will JNDI work with eDirectory? What are some resources I can use to learn about whatever library or libraries you suggest?
I just want to play around with retrieving information via LDAP for right now, and if I get things working the way I want, I will probably need to be able to modify objects later on.
Thanks!
JNDI should work with eDirectory.....
try; http://developer.novell.com/wiki/index.php/Jldap and http://developer.novell.com/wiki/index.php/Novell_LDAP_Extended_Library
Used it successfully with OpenLDAP and should suffice for eDirectory as well.
Any LDAP interface you want to use should work fine against eDirectory.
Be aware that the configuration of the LDAP server may not allow clear text passwords, thus a bind to port 636 via SSL (Where you have the certificate imported into the keystore already) or via TLS (retrieve the tree CA's public key on the fly).
If you have administrative access to the eDirectory server, you can easily change that, but still best to confirm that you can get it to work over SSL/TLS (aka LDAPS).
If you really need it, you can ask the admins for a server with only a replica of some test partition (and thus no real user data in its view) and test via cleartext against that.
It is very easy in eDirectory to add a new replica of a partition, carve off or merge a partition, and all can be done live.
It is similarly very easy to host replicas of many partitions on one server. (The official limit is, no limit on the number or partitions in a tree, or replicas on a server, but it used to be 256 in older versions (before 8.x) )
If you are allowed access to the eDirectory server, you want to to ask for access to Dstrace (several versions of this, see Many Faces of Dstrace). There is a web interface (server:8008 on Netware, 8010 on Windows, 8028 on Unix/Linux usually) or other interfaces. If you enable the LDAP trace option (and turn off all the others) you can fairly completely debug what is going on at the server side. See the errors, the communication, or lack thereof and so on.