SFTP only chroot users with OpenSSH in Debian

Posted by on Dec 28, 2010 in Hosting, Nerdy, Security | Comments Off

From OpenSSH version 4.9 and up it is now possible to create chrooted SFTP-only users with OpenSSH without the need for any add-ons.

In my example i want all users within the “sftp” group to hit /srv/sftponly.  This can be done on userlevel or on group level. I will be using groups.

At first, use your favorite editor to ecit /etc/ssh/sshd_config and find the line starting with “Subsystem sftp” (usually at the bottom) – change it so it looks like this:

Subsystem sftp internal-sftp

Next, we need to add the rule to match users. Add this to your sshd_config at the bottom:

Match Group sftp
PasswordAuthentication yes
ChrootDirectory /srv/sftponly
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

Now add the sftp group:

groupadd sftp

Add our first user:

useradd -d /srv/sftponly -g sftp -s /bin/false <username>
passwd <username>

Now, restart openssh:

/etc/init.d/ssh restart

And you should be all set. Use your favorite SFTP editor to test. Also try logging on via SSH to make sure that the user does not have access to do that.

Troubleshooting

Along your way some problems might occur. I will try to address the most common ones here. At first what you want to do is enable debugging in openssh so you can see in the logs what happens. Edit /etc/ssh/sshd_server – find “LogLevel” and change the setting to “DEBUG” – and restart ssh. The problems below are shown either in these logs or in the output of the “sftp” command from the client. When using the sftp client be sure to add the “-v” flag for verbose output.

Problem: fatal: bad ownership or modes for chroot directory component “/”
Fix: chmod 755 /

Problem: fatal: bad ownership or modes for chroot directory “/srv/sftponly”
Fix: Folders in the path along the way must be owned by root:root and must not be writable by anyone but root. This is because the directory we are going to use will be the root of the new users.  In my example the fix would be: chown root:root /srv ; chown root:root /srv/sftponly ; chmod 755 /srv ; chmod 755 /srv/sftponly”

Problem: Everything seems to be OK.. The users just don’t get access.
Fix: Make sure that you don’t have any whitespaces in your sshd_config after the configuration lines. In my case this caused a real pain.

Hit me a comment if you experience anything strange.

Setting UMASK for SFTP users

Add this line to /etc/pam.d/sshd:

session    optional     pam_umask.so umask=0002

This particular line will make new files/folders user and group writable.

Do you make backup? – If you do, is your backup strategy safe?

Posted by on Dec 11, 2010 in Hosting, Security | Comments Off

I think server backups here.

As a server administrator, there are a lot of concerns and one of the bigger ones is security. I know a whole lot of server administrators, and when I did a Q&A to know about their backups I was astonished to find out that more than 30% of them did not even take backup. I got a lot of responses and there are many ways of handling your backup, but a lot of them are very very wrong and will not do you any good in case of an emergency.

Do you even back up?

If you do not back up your data, what will you do in case of a hardware failure? Sure, you might be running a RAID, but a RAID is no guarantee, a RAID can break and then you will loose the game.

If you do not take backup, what will you do in the event of a fire breaking loose and destroying everything where ever your server is placed? Is your data valuable to you?

How do you back up?

Making backup is good. But how do you save your backup on the remote host? A few common ways of making backup is via FTP/SFTP/rsync. So, now you’re safe, right? If a fire breaks out, water disaster, disks die and so on, you will have your backup. And that’s good.

If your backup is automated, then your client somehow authorized to the backup server. In most of the above mentioned cased that authentication gives you full access to the backup data! Why is that bad?  It is because an attacker that has success gaining access to your server, will be able to emulate the authentication of the automated backup and therefore be able to delete both production data AND backup data.

How much is your backup worth now?

Howto: APC UPS and Debian

Posted by on Nov 25, 2010 in Hosting, Nerdy | Comments Off

So, I have a couple of NAS boxes and a laptop as server running at home. It’s all good until thunder appears. There are multiple risks with this. If the lightning strikes it can cause large surges of electricity that will destroy your equipment, if a power loss occurs it can cause the two RAID5 setups to die and it will cause major data loss.

A couple of days ago I bought a UPS and set it up and now I figured I should also set it up. So I did some reading and this is my result served to make it easier for you.

In this guide, this setup is used:
- Computer with GNU/Linux Debian Lenny
-  APC Back-UPS 800

The software I use is apcupsd which is in the Debian repository. Start by installing it:

apt-get update && apt-get install -y apcupsd

The next thing is to configure it. I did a whole lot of reading the manual for apcupsd to make sure I did things right. When your UPS is set up, hook the USB cable into your server.

Go to /etc/apcupsd and edit the file apcupsd.conf

My UPS and most of the newer UPS’es form APC uses USB to interface with the server, and that makes it easier for us to talk to it. These are the parameters I have set:

UPSCABLE usb

Define that we use a USB connection to the UPS.

UPSTYPE usb
DEVICE

Set the type to usb and leave the DEVICE property empty. By that it will find out where it is located by itself, and since we use USB it can do that.
ONBATTERYDELAY 5
BATTERYLEVEL 10
MINUTES 10
These three you should set to fit your needs. How generous you can be really depends on the amount of power you have versus the amount of power you use. My setup uses up around 85 watts, and since I have 800 VA I can keep it running for quite a while. On the product page for your UPS (if it is a APC) you will find a graph that tells you how long you can have it running depending on how much power you use. If you do not have any idea whatsoever about your power usage, you should get an energy meter and measure it first. If you have an idea, buy an appropriate UPS and set the levels as above. Later I will test the communication to the UPS and that will tell you how long it can keep you running – which also means you will know how to set your thresholds.
Now, these were all the customizations I did to the config file. Edit the file /etc/default/apcupsd:
ISCONFIGURED=yes
If you do not do this, it will refuse to start. Next, start it:
/etc/init.d/apcupsd start
Now, you can issue the command “apcaccess” and it will talk to the UPS and show you some information. You should see something similar to this (and more)
# apcaccess
APC      : 001,044,1076
DATE     : Thu Nov 25 10:20:32 CET 2010
HOSTNAME : natalie
RELEASE  : 3.14.4
VERSION  : 3.14.4 (18 May 2008) debian
UPSNAME  : natalie
CABLE    : USB Cable
MODEL    : Back-UPS BR  800
UPSMODE  : Stand Alone
STARTTIME: Wed Nov 24 20:30:05 CET 2010
STATUS   : ONLINE
LINEV    : 230.0 Volts
LOADPCT  :  13.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  53.0 Minutes
I made three of then bold, as they will tell you something you need to know. Check that it got the MODEL right. Next, check that STATUS is ONLINE.  Check that LOADPCT is less than 90 (it’s good to have a buffer). Now, on the TIMELEFT it will tell you how long it is able to run on the batteries. If you need now, edit the conf file again and adjust the parameters to fit this, so that you have time to shut down the systems nicely.
Now your UPS setup is working. I know it can be hard, but try pulling the plug for 10 seconds and the connect it again.  You should see a couple of broadcasts on your server. Also, if you view the file /var/log/apcupsd.events you will see all the events that the UPS system logs.
This is a sample of my log (I also tested the shutdown process by making it shut down machines quickly after a power loss.)
Wed Nov 24 20:22:50 CET 2010  Power failure.
Wed Nov 24 20:22:56 CET 2010  Running on UPS batteries.
Wed Nov 24 20:23:57 CET 2010  Reached run time limit on batteries.
Wed Nov 24 20:23:57 CET 2010  Initiating system shutdown!
Wed Nov 24 20:23:57 CET 2010  User logins prohibited
Wed Nov 24 20:24:16 CET 2010  apcupsd exiting, signal 15
Wed Nov 24 20:24:16 CET 2010  apcupsd shutdown succeeded

Make NAS’es shutdown too!

In my case I have 2 NAS’es and I want them to shutdown too. It’s pretty easy to do that (when you figure it out).
This is what I did:
1) ssh-keygen -t rsa
2) mkdir /etc/apcupsd/keys
3) mv ~/.ssh/id_rsa /etc/apcupsd/keys
4) chmod 600 /etc/apcupsd/keys/id_rsa
5) cat ~/.ssh/id_rsa.pub
Mark and copy the public key.
Log on to your NAS as root/admin account and do “ls -la” – if a .ssh folder is already there, go to it. if not, create it. Check if there is a file called “authorized_keys” – if not, then create it and put the key from your clipholder in it. Now go back to your server and issue this command:
ssh -i /etc/apcupsd/keys/id_rsa -l <username_for_nas> <ip_for_nas> ‘ps’
When you run that, it should show you a process list without any trouble. this process list is from the NAS – this means you can run commands on the NAS via SSH remotely now. In my case the NAS runs busybox, so to shut it down I need to run “/sbin/poweroff” so this will be the full command for me to use:
ssh -i /etc/apcupsd/keys/id_rsa -l admin <ip> ‘/sbin/poweroff’
Test it by running this command and see if your NAS shuts down.
Next thing you need to do is to make apcupsd do this when it shuts down. Do this by editing the file “/etc/apcupsd/apccontrol”
Find the “doshutdown” option and simply add your command BEFORE the ${SHUTDOWN} line. This is mine:
echo “UPS ${2} initiated Shutdown Sequence” | ${WALL}
echo “Will now shutdown NAS systems before killing server” | ${WALL}
/usr/bin/ssh -l admin -i /etc/apcupsd/keys/id_rsa <NAS1_IP> ‘/sbin/poweroff’
/usr/bin/ssh -l admin -i /etc/apcupsd/keys/id_rsa <NAS2_IP> ‘/sbin/poweroff’
${SHUTDOWN} -h now “UPS ${2} initiated shutdown”
And voila! If a power outage occurs your NAS and server will now shut down safely.

Useriøs hosting!

Posted by on Mar 22, 2010 in Hosting, Nerdy, Rant'n'rave | 2 comments

Som du måske har bemærket (hvis du har læst mine tidligere indlæg..) så er en af mine interesser hosting. Sjovt nok, lever jeg af hosting og ud over at leve af det, så snuser jeg også rundt og ser hvad andre har at byde på.

Jeg møder mange ting rundt omkring, som jeg synes er super fede – men jeg møder også ting, som jeg virkelig synes er til grin. Der er dog én ting, som jeg synes går igen og igen. Udbyderne mangler SSL kryptering på deres kontrolpaneler og deres webmail.

Nogle vil kalde mig sikkerhedsparanoid, men det kan jeg ikke tage mig af. Hvis man først er i gang med at sniffe trafik, så er en af de letteste ting i verden at sniffe trafik der sendes i clear text.

Først, hvis du ikke helt er klar over, hvad jeg ævler om, så se min screencast der omhandler emnet:

Screencast

Hvis du ikke allerede vidste det, så ved du en lille smule mere om sikkerhed nu. Så langt så godt.

Problemet i det hele er at mange hostingvirksomheder ikke sørger for at SSL kryptere forbindelsen til f.eks. deres kontrolpanel eller deres webmail.

Set med mine øjne, så er dette meget kritisk da man jonglerer rundt med folks private data. Nogle vil så argumentere med at SMTP jo alligevel ikke er krypteret, eller at de fleste kunder alligevel uploader data via en ukrypteret FTP forbindelse.

Det er bare ikke et holdbart argument, for der er ingen grund til at gøre tingene værre end de er. Dernæst, så er risikoen for at data opsnappes på en webmail væsentligt større end den er på f.eks. FTP.  Mange mennesker kigger på deres Webmail alle mulige steder men de logger ikke på FTP og uploader ting og sager fra f.eks. en hurtig netcafe i luftnavnen.

Jeg har kigget på lidt forskellige hostingselskaber, og vil derfor her komme med en kort forklaring på hver af dem, om de benytter SSL eller ej. Bemærk! At dette kendetegner hvordan tingene ser ud d. 22/03-2010.

Inforce A/S: Hos Inforce A/S eller Webhotel.net er der ingen kryptering på kontrolpanel og webmail. Deres OWA er der kryptering på.

UnoEuro.com: Hos UnoEuro er der SSL på kontrolpanelet, men som standard på Webmail er der ingen kryptering. Man kan vælge “sikker forbindelse” – men så bruges et self-signed certifikat. Læs lidt om forskellen på self-signed og signed.

Web10: Web10 har ingen SSL kryptering på hverken webmail eller kontrolpanel.

One.com, SurfTown.dk og Gigahost.dk benytter alle 3 SSL kryptering på både webmail og kontrolpanel.