This is a quick post to remind me in the future… and is based on this official help page.
execute restore vmlicense tftp yourlicense.lic 192.0.2.1
This works around what you can do if you accidentally apply a license you’ve already applied somewhere else :)
CCHits was recently asked to move it’s media to another host, and while we were doing that we noticed that many of the Monthly shows were broken in one way or another…
Cue a massive rebuild attempt!
We already have a “ShowRunner” script, which we use with a simple Vagrant machine, and I knew you can use other hypervisor “providers”, and I used to use AWS to build the shows, so why not wrap the two parts together?
Firstly, I installed the vagrant-aws plugin:
vagrant plugin install vagrant-aws
Next I amended my Vagrantfile with the vagrant-aws values mentioned in the plugin readme:
Vagrant.configure(2) do |config|
config.vm.provider :aws do |aws, override|
config.vm.box = "ShowMaker"
aws.tags = { 'Name' => 'ShowMaker' }
config.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box"
# AWS Credentials:
aws.access_key_id = "DECAFBADDECAFBADDECAF"
aws.secret_access_key = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
aws.keypair_name = "TheNameOfYourSSHKeyInTheEC2ManagementPortal"
# AWS Location:
aws.region = "us-east-1"
aws.region_config "us-east-1", :ami => "ami-c29e1cb8" # If you pick another region, use the relevant AMI for that region
aws.instance_type = "t2.micro" # Scale accordingly
aws.security_groups = [ "sg-1234567" ] # Note this *MUST* be an SG ID not the name
aws.subnet_id = "subnet-decafbad" # Pick one subnet from https://console.aws.amazon.com/vpc/home
# AWS Storage:
aws.block_device_mapping = [{
'DeviceName' => "/dev/sda1",
'Ebs.VolumeSize' => 8, # Size in GB
'Ebs.DeleteOnTermination' => true,
'Ebs.VolumeType' => "GP2", # General performance - you might want something faster
}]
# SSH:
override.ssh.username = "ubuntu"
override.ssh.private_key_path = "/home/youruser/.ssh/id_rsa" # or the SSH key you've generated
# /vagrant directory - thanks to https://github.com/hashicorp/vagrant/issues/5401
override.nfs.functional = false # It tries to use NFS - use RSYNC instead
end
config.vm.box = "ubuntu/trusty64"
config.vm.provision "shell", path: "./run_setup.sh"
config.vm.provision "shell", run: "always", path: "./run_showmaker.sh"
end
Of course, if you try to put this into your Github repo, it’s going to get pillaged and you’ll be spending lots of money on monero mining very quickly… so instead, I spotted this which you can do to separate out your credentials:
At the top of the Vagrantfile, add these two lines:
require_relative 'settings_aws.rb'
include SettingsAws
Then, replace the lines where you specify a “secret”, like this:
aws.access_key_id = AWS_ACCESS_KEY
aws.secret_access_key = AWS_SECRET_KEY
Lastly, create a file “settings_aws.rb” in the same path as your Vagrantfile, that looks like this:
module SettingsAws
AWS_ACCESS_KEY = "DECAFBADDECAFBADDECAF"
AWS_SECRET_KEY = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
end
This file then can be omitted from your git repository using a .gitignore file.
A few months ago I was a guest on The Ubuntu Podcast, where I mentioned that I use Streisand to terminate my VPN connections. I waffled and blathered a bit about how I set it up, but in the end it comes down to this:
streisand.vm.network "public_network", bridge: "eth0", ip: "192.0.2.1", :use_dhcp_assigned_default_route => false
streisand.vm.provision "shell", run: "always", inline: "ip route add 0.0.0.0/1 via 192.0.2.254 ; ip route add 128.0.0.0/1 via 192.0.2.254"
Hello! Congratulations, you’ve been hacked! Oh, OK, that’s probably not how it feels, right?
You’ve probably just had a message from someone to say that your account has been messaging loads of people, or that there is stuff on your timeline that … well, you didn’t put there.
It’s OK. It happens to a LOT of people, because Facebook is a very clear target. Many many people spend large quantities of their life scrolling through the content on there, so it’s bound to be a target, and for some reason, they found your account.
So, first of all, let’s address how this probably happened.
It’s easier to do this from the Facebook website, but you can probably still do all this lot from a mobile device.
Let’s solve the first two. Go into the Facebook Security Settings page, where you should change your password and boot off any sessions that aren’t YOU right now (don’t worry if there’s LOADS there – if you’ve used your phone somewhere that’s not where you are now, Facebook stores it as a new session). You can always log back into those other sessions later if you need to.
The third one can be a bit time consuming: kicking off apps you don’t use (mine was like walking into a museum!). Head into the Facebook Apps Settings page, and start clicking the X buttons to remove the apps you don’t use. Every now and then you might get a message saying that there was an error removing one of those apps. It’s fine, just give it a second and then try again. If someone has got into your account because of one of the first two, it’s probably worth checking this part anyway just in case they did something else to your account than just sending spam…
You might also want to check out your timeline, and remove the messages you sent (if they were posted to your timeline) or contact people who have been messaged to let them know you lost control of your account.
If someone got into your email and started resetting passwords then you’ve got a much worse problem, and I can’t really go into it here, but, it’s probably best to say that if they were just after your Facebook account, you were REALLY lucky. Your email account typically has the ultimate reset code for *EVERY* account password, so it’s probably best to make sure that what I’m saying about Facebook is also true for your email provider!
If you’ve done the above, but you’ve picked a password you’ve used somewhere else before, then you’re kinda setting yourself up for this to happen to you again in the future.
You see, the way that most of these attacks happen is by someone getting hold of a password you’ve used on a less secure site, and then tried logging into your Facebook account with that password they’ve snaffled. Want to see how likely this is? Visit Have I Been Pwned and see if your details are in there (the chances are very very very high!) and you’ll see websites who have been breached in the past and had your details taken from there… and this is just “the ones we know about” – who knows how many other websites have been breached and we don’t know about!
You can prevent this by not using the same password everywhere. I know. It’s hard to think of a new password every time you come to a new website, and how will you remember that password the next time you get there? Well, fortunately, there’s a solution to this one – a password manager. It’s an application for your laptops, desktops and mobile devices that stores your password for you, and tells you about them when you go to login to a website.
What’s more, that password manager can create passwords for you, not like “BobIsMyBestFriend1988” but more like “za{UHCtqi3<6mC_j6TblSk3hwS” (which, unless you’re some kind of savant, you’ll never remember that)…. and then tell you about that in the future. So now, you only need to remember one password to get into the password manager, and it will tell you about everything else! So, that helps!
There are two ways to do this – run an add-on in your web browser and on your mobile devices which synchronises everything to the cloud for you, or run a separate app and synchronise those passwords yourself. Personally, as I’m a bit geeky, I’m happy doing the second, but most people reading this are probably going to want someone else to sort out the synchronising.
What if you accidentally gave your password to someone? Or if you went to a website that wasn’t actually the right page and put your password in there by mistake? Falling prey to this when it’s done on purpose is known as social engineering or phishing, and means that someone else has your password to get into your account.
To reduce the impact of something like this, we can force someone logging in to use a “second factor” – something you have, rather than something you know, sometimes referred to as “Two Factor” or “2FA”. You might already use something like this at work – either a card with a chip on it (called a “Smartcard”), a device you plug into the USB port on your computer, or a keyring style device with numbers on. Or… you might have an app on your phone.
If you want to set this up on Facebook, you’ll need to enable it. Take a look at their help page about this!
(And if you want to know about securing your email account, check out the “Docs” column on this site for instructions about many email providers)
This post has been revised since it was initially published on 31st March due to errors found in the resulting build. It was also missing details on the shared data drive between the two machines, so has been amended to include that.
** WARNING ** This works for me – it might not for you!
The outcome of this build will leave you with the following:
Boot up, go through the VeraCrypt bootloader, enter a password for Windows, or press escape to load the Grub bootloader where you will boot (K|L|X|)Ubuntu(| Mate| Gnome).
The Windows environment will be encrypted with VeraCrypt, an open source Full Disk Encryption technology, while the Linux environment will be encrypted using Luks. The shared volume (between Windows and Linux) will be encrypted with VeraCrypt.
PLEASE BE AWARE THAT ANY WINDOWS 10 UPGRADES WILL FAIL TO APPLY AS IT WILL NOT RECOGNISE THE VERACRYPT FILE SYSTEM! To resolve this, decrypt the Windows volume, perform the upgrade, re-encrypt it, then transfer the new recovery ISO image to the boot volume, following the method below. Yes, this will take some time. No, you don’t need to decrypt the data volume. Yes, you can use that data volume to shunt the ISO image around.
LATE EDIT 2020-01-06: I’ve just spotted a link to this post over on Level1Techs. In that post, someone asked if the broken upgrades is still a thing. Turns out that since I wrote this in 2017, it’s not been fixed. Now, I should stress, I’ve stopped using this layout as I went all-Linux on that machine, but… it might work for you now?! Also, shout out to 92aceshigh for referencing this post, and glad something I wrote helped you! ☺
My partition table, for a 320GB Disk looks (roughly) like this:
Partition 1: 20GB – Linux /Boot (ext2, plus space for ISO files for random booting)
Partition 2: 60GB – Windows C:\ (NTFS VeraCrypt)
Partition 3: 72GB – Linux Physical Volume (LVM PV, Luks Encrypted)
– logical volume 1: 16Gb Swap (Linux Swap)
– logical volume 2: 60Gb Linux (ext4)
Partition 4: 156GB – Shared Volume (NTFS, VeraCrypt)
I performed this using GParted in the Gnome Live image using the GParted. Some rational here:
The following steps need to be run as root.
sudo -i
cryptsetup luksFormat -y -v /dev/sda3
cryptsetup luksOpen /dev/sda3 lvm-pv
vgcreate vg00 /dev/mapper/lvm-pv
lvcreate -n lv00_swap -L 16G vg00 # Define 16GB Swap Space
lvcreate -n lv01_root -l +100%FREE vg00 # Define the rest of vg00 as /
LEAVE YOUR TERMINAL OPEN
Note that when you perform your install, when you get to the partitioning screen, select “Manual”, and then pick out the following volumes:
/dev/mapper/vg00-lv01_root = ext4 formatted, mount point: /
/dev/mapper/vg00-lv00_swap = swap
/dev/sda1 = ext2, format, mount point: /boot
Select the boot volume of /dev/sda. But wait, I hear you say, Windows has a well know history of nuking Grub partitions… Well, we’ll sort that in a bit…
DON’T EXIT THE LIVE SESSION ONCE THE INSTALL HAS FINISHED (select “Continue Testing”).
Go back to your terminal session. It should still be logged in as root. We need to re-mount all the partitions…
mount /dev/mapper/vg00-lv01_root /target
mount /dev/sda1 /target/boot
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /target$i; done
chroot /target
echo "LinuxRoot UUID=`blkid | grep sda3 | cut -d\\\" -f2` none luks" > /etc/crypttab
update-initramfs -u
grub-install --force /dev/sda1
chattr +i /boot/grub/i386-pc/core.img
update-grub
The first part installs grub to the boot position, even though it doesn’t like it, and the second forces the core file to be unchangeable… I’m not exactly sure of the impact of this, but it’s the only way to do the next part of this process. The last bit makes sure that you’ve got the latest grub config files installed.
Just check to make sure the machine boots OK!
You should have a booting Ubuntu derivative with an encrypted file system. Awesome.
Now let’s install Windows!
You should boot from your install media, when you get to the partition selector, there should only be a single NTFS partition for it to use. Use it.
Install the latest version of Veracrypt from https://veracrypt.codeplex.com/
Once it’s installed, go to System, Encrypt System Partition/Drive, “Normal” system encryption, Windows System Partition, Multi-Boot (accept the warning), Boot Drive “Yes”, Single Disk, “Non-Windows Boot Loader” – No, and then… let it go through all the rest of the steps. There will be one stage where it asks you to create a rescue disk. Just save it for later. Once the encryption settings are collected, it will do a test (which is basically just rebooting to the boot loader, having you put in your password and going back into Windows), and then let it start performing the encryption.
Once the encryption finishes, reboot the computer, enter the decryption password and test it boots to Windows OK. Then reboot it again and press escape instead of putting in the password. It will boot to your Ubuntu system.
So, there you have it. One Dual-Boot system with encrypted disks everywhere!
After you’ve got the Ubuntu and Windows volumes sorted out, next we need the shared data volume to be organised. You’ll need Veracrypt for Ubuntu. Use the following to install the Veracrypt package for Ubuntu:
sudo add-apt-repository ppa:unit193/encryption sudo apt-get update sudo apt-get install veracrypt
Once that’s installed, boot back into Windows and create a new volume – perhaps V: for Veracrypt, or E: for Encrypted – your choice, but make sure you create it using the same password that you used for the Windows partition.
Format this new volume with either NTFS or FAT32 so that you can mount it under either operating system. I chose NTFS.
Now, you need to go into Veracrypt’s Settings menu, and select “System Encryption Settings”. Tick “Cache pre-boot authentication password in driver memory” (be aware, this means that if your machine is compromised when powered up, the password could be recovered), then OK. This may prompt you to accept the UAC at this point.
Next, with the mounted volume selected, go to the “Favorites” menu, and choose “Add to System Favorites”. In the screen which comes up, select the box under “Global Settings” which says “Mount system favorite volumes when Windows starts (in the initial phase of the startup procedure)”. There will be a warning about passwords that appears. Click OK.
You may, at this point, want to move certain aspects of your Windows desktop (e.g. the “My Documents” location) to the new mounted drive.
On the Linux OS, become root, with sudo, and then add the following lines to your crontab:
@reboot mkdir -p /shared_storage @reboot veracrypt --text --non-interactive --fs-options=uid=1000,gid=1000,umask=0077 --password="YOURSUPERSECUREPASSWORD" /dev/sda4 /shared_storage
These assume that your login user’s ID is 1000 (you can check that by running the command “id” as your logged in user), that you want to use “/shared_storage” as the mount point (it stops Ubuntu treating it as a “Mountable Volume” if it’s not in your home directory and not in /mnt or /media). These options also mean that only that user (and root) can access any of the files in that partition (although, it is only you on this laptop… right?), which means you can safely use it for any files which check user permissions before allowing you to access them (e.g. SSH keys). I then set up a symbolic link to /home/MYUSERACCOUNT/Documents into the /shared_storage/Documents directory, and /home/MYUSERACCOUNT/.ssh into the /shared_storage/SSH_Keys directory.
The following list of resources helped me out when I was struggling with what to do next! They may not be canonical sources, but they helped.
I may or may not have reinstalled Windows and Kubuntu about 20 times during this process, cursing myself for starting the whole damn process off in the first place!!!
Because of technical limitations on a pair of platforms I’m using at work, I am unable to set-up key-based SFTP or SCP to transfer files between the pair of them, so I knocked together this short script using the TCL based Expect language.
| #!/usr/bin/expect | |
| set arg1 [lindex $argv 0] | |
| set arg2 [lindex $argv 1] | |
| set arg3 [lindex $argv 2] | |
| set timeout 1000 | |
| spawn sftp "$arg2" | |
| expect { | |
| yes { | |
| send "yes\r" | |
| exp_continue | |
| } | |
| ass { | |
| send "$arg3\r" | |
| exp_continue | |
| } | |
| sftp { | |
| send "put $arg1\r" | |
| expect { | |
| 100% { | |
| send "quit\r" | |
| exp_continue | |
| } | |
| } | |
| } | |
| } |
There’s no error checking here, which isn’t great, but as a quick-and-dirty script to SFTP files to a box which needs the password each run… it works! :)
Shesh! What a lot of keywords in the title!
For those who don’t know what some of those key words were, I’ll break down the title
So, now that we know what I’m talking about, let’s look at what components we will be using today.
So, you’ve got all your goodies, and you’re ready to go. Let’s do this!
sudo su -
# blacklist rt2800usb blacklist rt2870sta
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto wlan0
iface wlan0 inet manual
pre-up service hostapd start
post-up brctl addif br0 wlan0
auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0
pre-up iptables-restore -c < /etc/iptables.rules
post-down iptables-save -c > /etc/iptables.rules
If you want to use a static IP address instead of a DHCP one, then change the last block (auto br0; iface br0 inet dhcp) to the following (this assumes your network is a 192.168.0/24 with .1 as your router to the outside world):
auto br0 iface br0 inet static bridge_ports eth0 wlan0 address 192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0 gateway 192.168.0.1
# net.ipv4.ip_forward = 1
*filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1:81] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m state --state INVALID -j DROP -A FORWARD -i wlan0 -o eth0 -j ACCEPT -A FORWARD -i eth0 -o wlan0 -j ACCEPT COMMIT
# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- any any anywhere anywhere state INVALID
0 0 ACCEPT all -- wlan0 eth0 anywhere anywhere
0 0 ACCEPT all -- eth0 wlan0 anywhere anywhere
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
FROM: # driver = hostapd TO: driver = nl80211 FROM: #country_code = US TO: country_code = GB FROM: hw_mode = a TO: hw_mode = g FROM: channel = 60 TO: channel = 12 FROM: #ieee80211n = 1 TO: ieee80211n = 1 FROM: #wpa = 1 TO: wpa = 2 FROM: #wpa_passphrase=secret passphrase TO: wpa_passphrase=MySecretPassword FROM: #wpa_pairwise = TKIP CCMP TO: wpa_pairwise = TKIP CCMP
Reboot, and your access point should come to life! Huzzah!! Initially it’ll have the SSID of “test” (it’s in /etc/hostapd/hostapd.conf as the config line “ssid = test”) but you should probably change it to the same SSID as your main router. If you do that, ensure your WPA passphrase is the same as your main router too, otherwise your network will get very confused!
So, now you’ve got an Access extender, running Ubuntu… what else could you do with it? Well, I run one of two things on all of mine – sqeezeplay or vlc monitoring a webcam. All very useful stuff, and stuff I was doing with it before it was an access extender!
If you don’t know what hashing is in relation to coding, the long version is here: Cryptographic Hash Function but the short version is that it performs a mathermatical formula to components of the file, string or data, and returns a much shorter number with a slim chance of “collisions”.
I don’t know whether it’s immediately clear to anyone else, but I used to think this was a good idea.
<?php $password = sha1($_POST['password']);
Then I went to a PHPNW session, and asked someone to take a look at my code, and got a thorough drubbing for not adding a cryptographic salt (wikipedia).
For those who don’t know, a salt is a set of characters you add before or after the password (or both!) to make it so that a simple “rainbow table analysis” doesn’t work (essentially a brute-force attack against the authentication data by hashing lots and lots of strings looking for another hash which matches the stored hash). In order to make it possible to actually authenticate with that string again in the future, the string should be easily repeatable, and a way to do that is to use other data that’s already in the user record.
For example, this is a simple salt:
<?php
$password = sha1('salt' . $_POST['password']);
I read in the April 2012 edition of 2600 magazine something that I should have been doing with my hashes all along. How’s this for more secure code?
<?php
$site_salt = 'pepper';
$SQL = "SELECT intUserID FROM users WHERE strUsername = ?";
$DB = new PDO($dsn);
$query = $DB->prepare($SQL);
$query->execute(array(strtolower($_POST['username'])));
$userid = $query->fetch();
if ($userid == false) {
return false;
}
$prefix = '';
$suffix = '';
if ($userid % 2 == 0) {
$prefix = $site_salt;
} else {
$suffix = $site_salt;
}
if ($userid % 3 == 0) {
$prefix .= strtolower($_POST['username']);
} else {
$suffix .= strtolower($_POST['username']);
}
if ($userid % 4 == 0) {
$prefix = strrev($prefix);
}
if ($userid % 5 == 0) {
$suffix = strrev($suffix);
}
$hashedPassword = sha1($prefix . $_POST['password'] . $suffix);
So, this gives you an easily repeatable string, that’s relatively hard to calculate without easy access to the source code :)
Please note, I am having issues with localhost authentication. See below
MOTP-AS is a simple installable two-factor authentication system using the mOTP algorythm for generating one-time passwords. MOTP-AS integrates with FreeRadius to provide the same authentication to log in to managed servers in a consistent manner.
I’ve recently installed this on my Ubuntu 11.10 laptop and on my Ubuntu 12.04 Beta server, and the installation instructions worked on both, so I thought I’d share them with you.
sudo apt-get install libpam-radius-auth freeradius mysql-server phpmyadmin
Alternatively, use tasksel to install the LAMP server task, then
sudo apt-get install libpam-radius-auth freeradius
Download the latest version of motp-as from http://motp-as.network-cube.de/index.php/download/current-version
Unpack it.
tar xfz ~/Downloads/motp-as*
Go into the Setup/MySQL directory of the MOTP-AS directory. Edit motp_schema.sql at the line “CREATE USER”. Change the password from motp to something more secure.
mysql -u root -p < motp_schema.sql
Now update Setup/config.php with the new password you just created.
Copy the HTML directory to /var/www/motp (or somewhere else in your web root). You may need to do this either as root, or as a user with permissions to write to /var/www
cp -Rf ~/MOTP-AS_*/HTML /var/www/motp
Note this must be done after you’ve made your changes to Setup/config.php
Stop the FreeRadius service
sudo /etc/init.d/freeradius stop
Backup the users file
sudo mv /etc/freeradius/users /etc/freeradius/users.dist
Edit the users file you’re about to copy in
nano ~/MOTP-AS_*/Setup/Freeradius/users
Find the part where it says “/var/www/htdocs/radius-auth.php” and change that to “/var/www/motp/radius-auth.php”
Copy in the new users file
sudo cp ~/MOTP-AS_*/Setup/Freeradius/users /etc/freeradius/users
Backup the dynamic-clients file
sudo mv /etc/freeradius/sites-available/dynamic-clients /etc/freeradius/sites-available/dynamic-clients.dist
Edit the new dynamic-clients file
nano ~/MOTP-AS_*/Setup/Freeradius/dynamic-clients
Find the three lines saying “/var/www/htdocs” and replace that string with “/var/www/motp” (I use Ctrl+W, Ctrl+R in nano to do a replace-all.)
Copy in the new dynamic-clients file
sudo cp ~/MOTP-AS_*/Setup/Freeradius/dynamic-clients /etc/freeradius/sites-available/dynamic-clients
Then make that function available
sudo ln -s /etc/freeradius/sites-available/dynamic-clients /etc/freeradius/sites-enabled/dynamic-clients
Amend the default script to enable accounting
sudo cp /etc/freeradius/sites-available/default /etc/freeradius/sites-available/default.dist
Then edit it to use the MOTP accounting functions
sudo nano /etc/freeradius/sites-available/default
Search for the line “accounting {” then comment that whole block out with the hash/pound sign “#“. Fortunately in the distribution supplied default file, this only means commenting out a few lines, which are “detail“, “unix“, “radutmp“, “exec“, “attr_filter.accounting_response“, and then the closing “}” for that block.
If you’re using nano, press the insert key (or Ctrl+R if you can’t find that easily) and enter /home/MyUserName/MOTP-AS_v0.7.2/Setup/Freeradius/accounting (amend the path as appropriate). Replace the section “/var/www/htdocs” with “/var/www/motp“.
Save and exit
sudo /etc/init.d/freeradius start
Personally, I have an Android device, and I chose to install the Mobile-OTP app from the Android Marketplace. I also, through work, have a Nokia 6303i Classic, on which I installed the MOTP application from the MOTP site.
I’ve heard good things about iOTP for iPhone, although I personally don’t have one.
Go to http://localhost/motp (or https://yourdomain.com/motp)
Login with the username admin and password of motp.
Click on the red text in “First time configuration”
Click on “Change password of User ‘admin’”
Enter a new password. Do not set the time or uses section of this page. Click “Set“. Ignore the warning.
Click on “Home”
Click on “Quick Add” (under “Wizards”)
Enter a username. It should be the username for your Ubuntu 11.10 device.
On the client, create a profile for the device. Most of them create a profile by asking for a seed, rather than a secret, so those will likely be more than 16 characters long – maybe even 20 (Mobile-OTP for Android) or 25 (MOTP Java app).
Once you’ve got your secret (on Mobile-OTP, by pushing-and-holding on the profile name and selecting “Show Secret“, on MOTP Java app, once you’ve put 0000 as the PIN for the first time to initialize it, you get a string “Init-Secret:“), put that into the “Secret” field, and then ask the user to set their pin here – I suggest 1234 initially, as the user can change it to something they want after.
Click OK, then click “Logout” and test authentication. If it all goes OK, they should be presented with “Welcome to the Mobile OTP Authentication Server“.
Under “Settings” they can change their own PIN.
Run the radius testing program, like this, as a user:
radtest username passcode localhost 0 testing123
(This assumes the default localhost password hasn’t changed)
If you get anything like “rad_recv: Access-Reject packet from host“, then you’ve failed to configure something properly, or you’ve entered the PIN or code wrong.
Restart FreeRadius in debugging mode by doing the following:
/etc/init.d/freeradius stop
/usr/sbin/freeradius -X
This will produce a large quantity of logs on-screen, so I’d suggest running the test itself from a separate window. Run the radtest command (listed above) again. Look for your error messages. In my case, I forgot to update the line in users, so I saw this error message: Could not open input file: /var/www/htdocs/radius-auth.php
To find where this fault was, I did (as root, in /etc/freeradius)
find -R 'htdocs' /etc/freeradius
And got back:Â users: Exec-Program-Wait = “/usr/bin/php /var/www/htdocs/radius-auth.php %{User-Name} %{User-Password} %{Client-Shortname}”
That told me the fault was in the users file.
Fix the issue, check it again, and when you get this message “rad_recv: Access-Accept packet from host” press Ctrl+C to cancel the test mode of FreeRadius, and then run:
sudo /etc/init.d/freeradius start
Edit /etc/pam_radius_auth.conf
sudo nano /etc/pam_radius_auth.conf
Find the line which says “127.0.0.1” and replace the shared secret with something you want your server to use. You will also need to amend /etc/freeradius/clients.conf and replace the “secret” in the localhost client there (by default, it’s “testing123” in freeradius).
If you want to use your OTP for all authentication credentials, edit /etc/pam.d/common-auth, or if you just want to use it with specific access protocols, edit the relevant file in /etc/pam.d for the authentication systems you want to use OTP for.
You need to add the following line – either on the line before “@include common-auth” (for non common-auth files) or after the primary comment block for common-auth.
auth sufficient pam_radius_auth.so
Open a separate terminal session to your box (especially! if you’re remote) and ensure you can still login with your regular credentials.
Then try a connection with your radius credentials. It should just work! If not, stop the freeradius server and re-run it using /usr/sbin/freeradius -X and see whether you’re getting a different error message.
I have noticed that I’m getting locked out when using my non-radius credentials. This is probably due to the placement of the line in the /etc/pam.d/common-auth – it should probably come after the pam_unix.so line, but I’ve not tested that yet. I’m also going to try to suggest that there be an optional time-out period on locked accounts to the developers of MOTP-AS.
The second issue I’m struggling with is that I’m getting errors when using the LightDM. I’m getting the following error message in /var/log/auth.log:
pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "spriggsj"
I don’t know if this is because I’m using ecryptfs as well, or because there’s something wonky going on with the common-auth structure I’m using.
A colleague today asked for some guidance around setting up an SFTP and SCP only account on a RedHat based Linux machine.
I sent him a collection of links, including one to the CopSSH project, and he implemented the code on that link, but then struggled when it didn’t work.
Aside from the fact the shell wasn’t copied into /etc/shells (which wasn’t disastrous, but did mean we couldn’t reuse it again later), it was still returning an error on each load.
Doing some digging into it, and running some debugging, I noticed that pscp (the PuTTY SCP) tool uses the SFTP subsystem rather than the SCP command to upload files, so we need to also check that the SFTP server hasn’t been called, instead of the SCP command, and also the SCP command needs to be corrected.
Here follows a script, complete with comments. Personally, I’d save this in /bin/sftponly, created and owned by root, and set to permissions 755 (rwxr-xr-x). Then, set the shell to this for each user which needs to do SFTP or SCP only.
#!/bin/bash
# Based on code from http://www.itefix.no/i2/node/12366
# Amended by Jon Spriggs (jon@sprig.gs)
# Last update at 2011-09-16
# Push the whole received command into a variable
tests=`echo $*`
# Set up a state handler as false
isvalid=0
# Test for the SFTP handler.
# The 0:36 values are the start character and length of the handler string.
if [ "${tests:0:36}" == "-c /usr/libexec/openssh/sftp-server" ]; then
# Set the state handler to true
isvalid=1
# Configure the handling service
use=/usr/libexec/openssh/sftp-server
fi
# Test for the SCP handler.
if [ "${tests:0:6}" == "-c scp" ]; then
# Set the state handler to true
isvalid=1
# Configure the handling service
use=/usr/bin/scp
fi
# If the state handler is set to false (0), exit with an error message.
if [ "$isvalid" == "0" ]; then
echo "SCP only!"
exit 1
fi
# Run the handler
exec $use $*