A friend and I are thinking of collaborating on some web development projects in our spare time. I already have an Ubuntu LAMP server running in a VM for my own work, and I'm thinking of setting up a VPN so he can access it remotely. Does this sound like a good way to go about it? Basically, all we need is APACHE, SQL & PHP on a server that we can share but is not accessible to the outside world.
A VPN would allow access to the server 'front end'. If you also want to be able to upload a new test web page or change MySQL settings, look into SSH. That way you might even be able to mitigate the VPN all together and have it open to the internet, but with the config access only available through a secured connection. Otherwise, a VPN should do the trick.
HI Rob, thanks for the reply. If i go down the SSH route, how difficult would it make it for him to test the site on ios devices? Do you think it would be worth just buying some hosting, instead of faffing with VPN?
If it is just for a few people and the connection is good enough, then self hosting is always better than paid hosting. For what you want (a test server for you and your friend) then the SSH option would be the best. No VPN or anything, so the server would be visible to the internet, but then SSH access for you and your friend so that you two can go in and change config settings or the web pages. This would also have the benefit of standard internet access over mobile devices, so no fancy VPN settings needed. If you need any help setting it up, just send over a PM or post here.
Yes please I know that SSH is fairly easy to implement on ubuntu and then use something like putty on windows, but I've never set it up over the internet. Am I right in thinking that I would need either a static IP address or something like dynDNS? Also, would iOS need dedicated SSH apps, or is it able to just access it through safari?
DYNDNS would be fine for getting inbound connections. Then you'll need to port forward 80 and 22 to your server. Anything with a web browser just needs to visit your DYNDNS url, so that includes iPhones. You could have a couple of different ones and use host-headers in apache to serve up different websites for each to allow you to develop a couple at the same time. The only things that will need SSH to connect are you and your mate when you want to change settings on the box. Grab WINSCP to upload files and you don't even need to install FTP which is a bonus. I might suggest you rebind SSH to run on a different port - say something over 10,000 - which will stop 99.9% of random login attempts from all over the internet being anywhere near fruitful.
This. DynDNS is useful for connections that don't have a static IP - eg. I have to use it, and it works like a charm. SSH can be used to send commands to the server, and to transfer files using SCP (Secure Copy Protocol). SCP will be the main advantage for you. I personally don't bother changing the port it runs on as the authentication deals with any fraudulent login attempts. Remember that the Linux user permissions system is one of the most powerful security systems on computers. Set Apache or whatever web server you are using to a www user (should be set automatically), then create a user for both you and your friend. Remember to set both accounts to Administrator accounts - ie. able to sudo commands. You can do this by either going through the graphical dialog if you have the desktop version installed, or by typing 'sudo adduser [name] admin'. This adds the newly created user to the group admin and allows that user to sudo on the system. Next is setting up SSH keys. This is very important as passwords can be easily cracked. The system is based on a public/private key pair. The public half is stored on the server and is unique for each user. The private half is carried around with you so that you can access the server anytime. Create a key by issuing the command (while logged in as the user that you want to create the key for): 'mkdir ~/.ssh', followed by 'chmod 700 ~/.ssh', and finally 'ssh-keygen -t rsa'. Those commands create the ssh directory, then set it to the correct permissions (all permissions for owner, none for others), and then creates the key itself. I would also recommend changing the key size to 4096 bits instead of the 2048 bit default. This can be done by altering the final command to: 'ssh-keygen -t rsa -b 4096'. 2048 bit keys *should* be fine up to 2030, so a security company says, but why settle for less security? The final stage in key generation is to copy the private key to a portable location. The file you need is ~/.ssh/id_rsa and the ~ stands for your home directory. In terminal typing ~ automatically returns to home directory, so you can type 'cp ~/.ssh/id_rsa [location of memory stick]'. So you have created the keys. Next you need to correctly configure the server to decline plain password attempts and only accept the keys. Do this by editing the /etc/ssh/sshd_config file. Regardless of graphical interface or not, you need to run the text editor under sudo. Using the graphical interface you can use 'sudo gedit /etc/ssh/sshd_config'. Ubuntu Server needs a command line text editor, like vim or nano. Both have very complex interfaces, so be sure to know what you are doing before you start editing system files. You need to edit the 'PasswordAuthentication' line inside /etc/ssh/sshd_config. By default it is commented out with a hash, and is set to 'yes'. You need to change both of those, so the final line looks like 'PasswordAuthentication no'. All is done! Set up port forwarding, then connect to your new ssh server using whatever tool you want! I don't know how to do it using PuTTY or other Windows based tools, but on Linux you can do 'ssh [user]@[server]'. Then it should ask you for the passphrase to your private key which needs to be put in ~/.ssh. If you are running the private key off a memory stick, then you can run 'ssh [user]@[server] -i [location of key file]. Hope this helps! I used this page for information.
Just looking into no-ip (I'd prefer to do it for free if I can), and I'm wondering how I would stop other people on the web from seeing our work-in-progress sites? Also, do you think i might be better off buying some hosting and using a subdomain for testing?
Both No-IP and DynDNS are free. You get a limited number of free subdomains for free, before you have to start paying with DynDNS. I would assume it is the same for No-IP... I just use DynDNS because the router supports it natively. If you really don't want the internets seeing your developing website, then you could try setting up Apache with password access. See here. Again, with the paid hosting - only if your hardware cannot handle it or your connection is bad. By the fact that web serving takes very little processing power, and you are looking into internet serving in the first place, then I assume your connection is good and your hardware is newer than 1995. So with that in mind, there is no point in choosing paid hosting over self hosting. With paid hosting a) it costs more, b) not as configurable, and c) there will be some term or condition out there that will limit you. With self hosting you have a server which you know is reliable and a web site that you know is secure (with the SSH keys).
Rather than mess around with local vm's you could pick up an extremely cheap vps, sometimes for as little as £12 per year. Or if you want something physical you can get an atom server in france for £16 p/m. Have a look at some of the offers on http://www.lowendbox.com/, in this day and age you shouldn't really have to mess around with vm's and dynamic dns servers Edit: http://www.howtoforge.com/ssh_key_based_logins_putty this is great tutorial for first time users looking into keyless ssh logins
I'd just like to point out that there's some great advice in here since my earlier post, but it is getting a bit complicated so here's a couple of simple suggestions. - You don't NEED to use SSH keyfile authentication, you can authenticate via username and password, and rely on SSH to encrypt it. It also means you don't have to somehow carry around the keyfile with you on a USB stick. I might just be lucky but by putting SSH on a high port and not allowing root login I've never had a break-in attempt even, and I've been running my own dedicated server for years. - If you want to control access to your websites, this very simple tutorial gives you the easiest way to do it; you use .htaccess and .htpasswd to make a user/pass prompt http://www.panix.com/web/faq/htaccess.html If you feel your work is of significant commercial value, you can try using SSH tunneling instead of opening port 80. This will make it harder for you to use host headers or subdomains however.
Security by Obscurity? That's kind of like hiding your SSID on a wireless network but leaving the encryption as WEP - it may give you a nice fuzzy feeling but is not secure in any way at all - see here.
Yeah, I'd definitely want to take as much of a belt-and-bracers approach as is feasible, since we may decide to pursue some of the projects commercially. What do you think of 1&1's business tier for this kind of application? I like the fact that it has unlimited storage, bandwidth, databases and subdomains, so we could use it for multiple projects and have testing, production and staging subdomains for each project. Oh, and it would save my friend from having to get Dreamweaver
Totally different things. I'm not stupid enough to use something that can be cracked in 50 seconds - hidden or not. If you leave your root logins allowed and make your password "fred" then you're asking for trouble. If you run ssh on a non-default port and practice good password policy, then unless someone knows to look at that exact spot, you're limiting your surface area for attack, and increasing the amount of effort it takes to get in by a lot. Your every-day hackers are just sweeping the default ports for exposed services and go for them by rote, but if you're expecting targeted attacks then exposing it to the internet in any way is asking for trouble, and so a VPN is probably the way to go. The question to the OP really is: how secure is secure enough for you?
