ServerStack » WordPress https://www.serverstack.com/blog Scalability Blog Sun, 03 Mar 2013 23:58:43 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.2 Implementing TOTP Authentication Into Your Infrastructure https://www.serverstack.com/blog/2013/02/21/implementing-totp-authentication-into-your-infrastructure/ https://www.serverstack.com/blog/2013/02/21/implementing-totp-authentication-into-your-infrastructure/#comments Thu, 21 Feb 2013 17:13:06 +0000 https://www.serverstack.com/blog/?p=417 We have previously covered how to add Time-based One-time Password Algorithm (TOTP) on your mobile device.  Now we can implement SSH access with TOTP. It is more secure to use public key authentication, and disable any password and challenge-based authentication for SSH. However, there are times when you have to have access to your server but you don’t have your public keys with you. In this case, we’ll need to allow root ... ]]>

We have previously covered how to add Time-based One-time Password Algorithm (TOTP) on your mobile device.  Now we can implement SSH access with TOTP. It is more secure to use public key authentication, and disable any password and challenge-based authentication for SSH. However, there are times when you have to have access to your server but you don’t have your public keys with you. In this case, we’ll need to allow root level login and secure it with a time-based passcode.

Make sure to sync your server’s clock and start ntpd :

# killall -9 ntpd && ntpdate -b -v 0.pool.ntp.org && service ntpd start

Now we’ll need to install git, pam-devel, and fetch the libpam code:

# yum –y install git pam-devel
# git clone https://code.google.com/p/google-authenticator/ /root/ga

Cloning into '/root/ga'...
remote: Counting objects: 1048, done.
remote: Finding sources: 100% (1048/1048), done.
remote: Total 1048 (delta 504)
Receiving objects: 100% (1048/1048), 2.27 MiB | 1.09 MiB/s, done.
Resolving deltas: 100% (504/504), done.

# cd /root/ga/libpam && make && make install

After all is done, you’ll have two files installed: /lib64/security/pam_google_authenticator.so and /usr/local/bin/google-authenticator

Modify /etc/pam.d/sshd and add the following line as the first entry:

auth required pam_google_authenticator.so

pam-google
Add the necessary modifications to SSH config and restart the daemon:

PermitRootLogin yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes

Now run google-authenticator and generate your securitykey:

run-google-security-key

You can add the QR code to your mobile device from link above:

qr-code

As you can see the secretkey that was generated is “4V5OYJGQ5PIZXINF”. To get a real-time passcode you can use the following Python code:

import hmac, base64, struct, hashlib, time

def get_hotp_token(secret, intervals_no):
    key = base64.b32decode(secret, True)
    msg = struct.pack(">Q", intervals_no)
    h = hmac.new(key, msg, hashlib.sha1).digest()
    o = ord(h[19]) & 15
    h = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000
    return h

def get_totp_token(secret):
return get_hotp_token(secret, intervals_no=int(time.time())//30)

my_secret = ‘4V5OYJGQ5PIZXINF’
my_token = get_totp_token(my_secret)

print my_token

 

You can either use your mobile phone (Android, iOS, Blackberry), or a standalone application to generate the passcodes:

generate-passcodes

If you entered an incorrect TOTP passcode but still got the correct password, the system would not let you logon, and generate an error in /var/log/secure :

sshd(pam_google_authenticator)[23225]: Invalid verification code
It is worth mentioning that you could migrate the /root/.google_authenticator file to all of your servers and use the same passcode.  The file contains the secretkey and emergency scratch off codes that should be written down somewhere safely:

# cat /root/.google_authenticator
4V5OYJGQ5PIZXINF
" RATE_LIMIT 3 30 1356890982 1356891010
" WINDOW_SIZE 17
" DISALLOW_REUSE 45229700
" TOTP_AUTH
17744140
47270588
95085783
61291563
70584902

 

If you ended up using one of the scratch off keys, the file will be automatically updated on the server where you used it.  For example, if you used “17744140” to login, the PAM module would delete that key and it would not be re-usable:

# cat /root/.google_authenticator
4V5OYJGQ5PIZXINF
" RATE_LIMIT 3 30 1356891395
" WINDOW_SIZE 17
" DISALLOW_REUSE 45229700
" TOTP_AUTH
47270588
95085783
61291563
70584902

You can also add your own scratch off key to the list, but keeping the list short is a good security practice.

Now that you have enabled challenge response authentication, you would need to modify your SFTP settings to “interactive” if you are using an SFTP client like FileZilla.

You will be prompted for the verification code upon connection:

prompted-verification-code

After entering verification code and password, the system will let you login:

system-login

WordPress with TOTP Authentication

Now that you have secure access to your files and command shell, we can also secure access to your WordPress administrative area.

Make sure to sync the clock on the webserver and your device where you’ll be generating the TOTP code.

# killall -9 ntpd && ntpdate -b -v 0.pool.ntp.org && service ntpd start
The plugin can be downloaded from http://downloads.wordpress.org/plugin/google-authenticator.0.43.zip or installed directly from WP Plugins menu:

Simply search for ‘google authenticator’ and install it directly:

wordpress-google

Activate the plugin and navigate to Users -> Your Profile:

activate-google-authenticator-wordpress

Make sure to generate your QR code and add it on your phone or desktop device :
generate-qr-code

Check “Active” box, and if your server does not have a reliable time syncing, check ‘Relaxed mode’.

To finalize changes, click “Update Profile” on the bottom, and you are done.

Now your WordPress Admin area is more secure :

wordpress-admin

]]>
https://www.serverstack.com/blog/2013/02/21/implementing-totp-authentication-into-your-infrastructure/feed/ 0
Automatic WordPress Updates Using FTP/FTPS or SSH https://www.serverstack.com/blog/2013/02/11/automatic-wordpress-updates-using-ftpftps-or-ssh/ https://www.serverstack.com/blog/2013/02/11/automatic-wordpress-updates-using-ftpftps-or-ssh/#comments Mon, 11 Feb 2013 06:43:37 +0000 https://www.serverstack.com/blog/?p=382 Introduction When working with WordPress in a more secure environment where websites are not entirely world-writable, you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments. Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic. It should be noted here that you can also make upgrades ... ]]>

Introduction

When working with WordPress in a more secure environment where websites are not entirely world-writable, you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments. Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.

It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE!

While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:

FTP:

1. Creating a separate user and restricting its access to only allow connections from localhost
2. Ensuring your FTP daemon is “chrooting” the user to their own directory only
3. Configuring your FTP daemon to listen only on localhost, thus preventing external connections
4. Using something more secure than FTP, such as SSH — Yes, we realize this one does not actually improve FTP security :)

SSH:

1. Creating a separate user (usually an alias with the same UID, different GID) and restricting access to only localhost for this specific user in sshd_config with the AllowHosts option
2. Creating some advanced SSH configuration such as chrooted SFTP-only users
3. Using public key authentication, which can be further secured by specifying a “from” address in the user’s authorized_keys file

There are several other ways one can make their FTP/FTPS or SSH setup more secure, but they are far beyond the scope of this post and can vary greatly in their application due to the hosting environment and several other factors. We are going to assume you’re already working with a secure setup for the purposes of this guide.

WordPress Upgrade Constants

From the WordPress Codex, the following constants are available to define FTP and SSH credentials in wp-config.php:

FS_METHOD This setting forces the filesystem (or connection) method, and you probably won’t need to adjust or define it. It can be one of: “direct”, “ssh2″, “ftpext”, or “ftpsockets”. WordPress will automatically determine the proper method using the following preferential order:
(Primary Preference) “direct” causes the use of direct file I/O requests from within PHP, but this requires the webserver to have write access to your WordPress installation, which is NOT recommended. This setting will be chosen automatically when the permissions allow.
(Secondary Preference) “ssh2″ allows forcing usage of the SSH2 PHP extension if installed (via PECL).
(3rd Preference) “ftpext” allows forcing the usage of the FTP PHP extension (this is usually the default when you connect via FTP/FTPS).
(4th Preference) “ftpsockets” utilizes the PHP sockets class for FTP access (far less common, but can resolve FTP connection issues in rare cases).

FTP_BASE is the full path to the “base” (absolute path) folder of your WordPress installation.

FTP_CONTENT_DIR is the full path to the wp-content folder of your WordPress installation.

FTP_PLUGIN_DIR is the full path to the plugins folder of your WordPress installation.

FTP_PUBKEY is the full path to your SSH public key.

FTP_PRIKEY is the full path to your SSH private key.

FTP_USER is either your FTP or SSH username, depending on which method you use.

FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication, this can be left blank.

FTP_HOST is the hostname[:port] combination for your SSH/FTP server. The default FTP port is 21 and the default SSH port is 22. You only need to specify the port if using a non-standard one.

FTP_SSL is only for FTPS connections, and should not be defined unless you have already configured your FTP daemon to support TLS. Note – SFTP is NOT the same thing, so make sure you do not confuse the two.

Here’s an example of the most common configuration options with sample values so you can see the proper method of defining them within wp-config.php:

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/path/to/wordpress/');
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org');
define('FTP_SSL', false);

To configure FTP/FTPS, you simply define the necessary constants from the list above in wp-config.php. A minimal configuration requires at least FTP_BASE, FTP_USER, FTP_PASS and FTP_HOST (usually 127.0.0.1). Enter these required constants, also adding FTP_SSL (true) if using FTPS, then your next upgrades should be automatic, and you should no longer be prompted to enter these details.

Enabling SSH support in WordPress Using the PECL SSH2 extension

Most users are not aware of this, but WordPress already supports SSH connections in addition to FTP/FTPS by simply enabling the SSH2 extension in PHP. Let’s begin by installing the SSH2 extension via PECL.

On RHEL/CentOS, you will need the php-devel, php-pear and libssh2/libssh2-devel packages and a working compiler/development libraries if you installed PHP via Yum (RPM-based installation):

# yum install php-devel php-pear gcc gcc-c++ make automake autoconf pcre-devel re2c libssh2 libssh2-devel

With the necessary prerequisites installed, you can now use the CLI tool ‘pecl’ to automagically install the extension for you:

# pecl install ssh2-0.12

The reason we need to define the version here is to avoid an error message about the extension being in “beta,” since there was never a release of this particular extension that was labeled as “stable.” Once the installation completes successfully, you’ll be presented with a success message that instructs you to enable the extension in php.ini. When using CentOS, each extension’s INI file is stored separately from the main php.ini for cleanliness and easy addition/removal of extensions. To update /etc/php.d/ssh2.ini, we will use the following command:

# echo "extension=ssh2.so" > /etc/php.d/ssh2.ini

Now, running ‘php -m’ should show the SSH2 extension in the list of extensions. If you see it there, you must now restart your PHP processor (we’ll assume it’s Apache):

# /etc/init.d/httpd restart

You now have the SSH2 extension installed and enabled. If you have not already entered any constants in wp-config.php, you can attempt an upgrade or plugin installation/deletion and you will now see a new radio button that says SSH, in addition to the FTP and FTPS choices you’ve always had. To complete this configuration, you can now just enter the same minimal options used above, possibly including the FS_METHOD constant (ssh2) to ensure only SSH connections are attempted. However, we assume you would rather use the most secure method you can, so let’s configure SSH with public key authentication.

We’ll start by generating a public/private keypair, which we will later define in wp-config.php:

# ssh-keygen -t rsa -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /home/user1/wp_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/wp_rsa.
Your public key has been saved in /home/user1/wp_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@server1.example.com

The location of the keys should be somewhere outside of your webroot, so the user’s home directory is usually a safe choice. You should NOT enter a password here, as there have been many issues getting passworded SSH keys to work properly with WordPress. After creating the keypair, we need to make it readable by the webserver (we’ll assume your webserver runs under the “apache” user for simplicity):

# chown user1:apache /home/user1/wp_rsa
# chown user1:apache /home/user1/wp_rsa.pub
# chmod 0640 /home/user1/wp_rsa
# chmod 0640 /home/user1/wp_rsa.pub

Next, you just need to edit wp_rsa.pub to specify the ‘from=’ option and add the contents to the authorized_keys file in /home/user1/.ssh/authorized_keys:

# vim /home/user1/wp_rsa.pub

You can use whichever editor you please (vi, nano, emacs, etc), so there’s no need to cry. Once you’ve opened the file, add the following ‘from=’ restriction at the beginning of the line (there should only be one very long line) right before ssh-rsa and the key data:

from="127.0.0.1" ssh-rsa ...

Now, we can actually place the public key’s contents in the user’s authorized_keys file:

# mkdir /home/user1/.ssh
# chown user1:user1 /home/user1/.ssh/
# chmod 0700 /home/user1/.ssh/
# cat /home/user1/wp_rsa.pub >> /home/user1/.ssh/authorized_keys
# chown user1:user1 /home/user1/.ssh/authorized_keys
# chmod 0644 /home/user1/.ssh/authorized_keys

As long as PubkeyAuthentication is enabled in sshd_config (default), you should now be ready to configure wp-config.php for automatic SSH upgrades:

define('FTP_PUBKEY','/home/user1/wp_rsa.pub');
define('FTP_PRIKEY','/home/user1/wp_rsa');
define('FTP_USER','user1');
define('FTP_PASS','');
define('FTP_HOST','127.0.0.1:22');

From now on, installing/removing/upgrading WordPress and its plugins should no longer prompt you for credentials. Happy blogging!

]]>
https://www.serverstack.com/blog/2013/02/11/automatic-wordpress-updates-using-ftpftps-or-ssh/feed/ 0