Posts Tagged SSH

YubiKey GPG key for SSH authentication

In this post I’m going to go over the steps to configure your YubiKey for SSH authentication using a GPG key stored on the YubiKey itself.

This guide goes through the steps for setting this up on a Mac running OS X. Although the concepts of doing this under Linux and Windows are the same, the exact steps will be different.

Ensure your YubiKey has CCID mode enabled

Per Yubico’s site, this is usually enabled by default:

“Note that all YubiKey NEOs shipped after November 2015 come preconfigured with all modes enabled.” —

If you’re using an older YubiKey and need to enable it, you’ll want to download the YubiKey NEO Manager from Yubico’s website and run it to ensure that your YubiKey has CCID mode enabled. The link to this tool and instructions to run it are here.

Once you’re certain that CCID mode is enabled, you can move ahead with the next section.

Install GPG

The remainder of the steps in this guide use the command line interface for GPG tools. If you don’t have either GPG Tools or GnuPG installed, install one of them. If you already have one installed, you can skip on to the next section.

GPG Tools provides a nice set of GUI tools and is recommend for most users, but if you’re not afraid of the command line and have Homebrew installed on your Mac, you can install GnuPG2 using Homebrew with the following command:

brew install gnupg2

Decide if you want to require touch

YubiKey will prompt for your PIN during SSH authentication. Starting with YubiKey version 4, YubiKey can also require a touch on the sensor during authentication. Enabling this will require a touch confirmation on the touch sensor for each and every SSH connection.

If you want to enable this, it is highly recommend that you install and use the Yubikey Manager CLI using the instructions from this page. Once installed, you can enable touch using the following command:

ykman openpgp touch aut <'on'|'off'|'fixed'>

If you want more information on these specific policies, please see this page under the heading “Yubikey 4 touch”. IMPORTANT NOTE: A link to a bash script to enable touch is found on that page. Because the behavior of that script requires providing your admin key on the command line, it should be considered insecure. I highly recommend using the ykman tool instead whenever possible.

Unless you set ‘fixed’, (ON_FIXED), you can always come back and change this setting later. If you set fixed, you can’t change it until you put a new secret key onto the YubiKey.

Change the YubiKey PINs

Before continuing, it’s you should change the YubiKey PINs from their defaults if you have not already. The default PIN is 123456 and the default admin pin is 12345678.

To do this, start by running: gpg --card-edit

Once you have the card editor open, allow admin commands by running admin

Then, open the PIN change dialog with passwd

From here, set your PIN, Admin PIN, and reset code. Store these in a safe place.

Once you’ve set your PINs, you can further personalize the data on the card. Here’s the full list of commands available after running admin:

gpg/card> help
quit       quit this menu
admin      show admin commands
help       show this help
list       list all available data
name       change card holder's name
url        change URL to retrieve key
fetch      fetch the key specified in the card URL
login      change the login name
lang       change the language preferences
sex        change card holder's sex
cafpr      change a CA fingerprint
forcesig   toggle the signature force PIN flag
generate   generate new keys
passwd     menu to change or unblock the PIN
verify     verify the PIN and list all data
unblock    unblock the PIN using a Reset Code

Generate and move a GPG key to the YubiKey

If you already have a set of GPG tools installed and your own key generated and available within those tools, good on you! Run the following commands to be sure:

gpg --list-keys
gpg --list-secret-keys

If your public and secret keys do show up as expected, there’s no need to generate another key. You simply need to move your existing key to the YubiKey.

IMPORTANT NOTE: If you want to make use of the ability to revoke your key in the future, then you must generate the revocation certificate before moving the key to your YubiKey. Once you move a key to your YubiKey, it is not possible to generate a revocation certificate unless you have a full backup of the secret key somewhere and are able to re-import it to your GPG keyring.

To move your secret key from your GPG keyring to your YubiKey, go to this page and start where it says “To import the key on your YubiKey”

If you need to generate a GPG key for SSH authentication, take a look at this guide and follow one of the two methods provided.

Once your key is generated and moved to the card, you’re all set to move on to the next section.

Making it all work locally

This part requires editing just a few files to make gpg-agent work as expected.

Add the following to ~/.bash_profile:

[ -f ~/.gpg-agent-info ] && source ~/.gpg-agent-info
if [ -S "${GPG_AGENT_INFO%%:*}" ]; then
    export GPG_AGENT_INFO
    export SSH_AUTH_SOCK
    export SSH_AGENT_PID
    eval $( gpg-agent --daemon --write-env-file ~/.gpg-agent-info )

Add the following to ~/.gnupg/gpg-agent.conf:

write-env-file ~/.gpg-agent-info
pinentry-program /usr/local/MacGPG2/libexec/

Restart gpg-agent:

sudo killall gpg-agent
source ~/.bash_profile
source ~/.gpg-agent-info

Get your SSH public key

Use the following command to get the SSH public key that corresponds to the key installed on your YubiKey:

ssh-add -L | grep cardno

This can be installed on any server that you want to use your YubiKey-stored key to access.


, ,

Leave a comment

How to move the SymformContribution directory from one volume to another on a Synology NAS

So you’ve got Symform all set up and running on your Synology NAS, and you’ve been contributing space, but now the volume that has your contribution folder is getting full, adn you’d like to move it without disrupting the data that other Symform users like yourself have trusted you with. How to do it? Easily.

In this example, I’ll show you how to move it from volume1 to volume2.

First, stop the Symform service from Package Center.


Next, SSH into your Synology box and move the target directory to it’s new location, in this case, /volume2/SymformContribution

mv /volume1/SymformContribution/ /volume2

Next, edit the /volume1/@symform/lib/node.config file using vi and update the location by finding the line similiar to the following…

<contribution enabled="True" fragmentStorePath="/volume1/SymformContribution" port="53432" />

… and changing volume1 to volume2.

(Note, this is the same file that’s used to update the incoming port, see this post for more information.)

Save the file, and restart the Symform service.


That’s it!

Questions or comments are welcome in the comments section below. Thank you for reading!

, , , , , ,

Leave a comment

Disable and remove .DS_Store files stored on network locations

So today I was going through my Synology NAS and noticed .DS_Store files all over the place.

These are actually files containing extended attributes created by Finder in Mac OS X. But, since they get written out to network locations, they can cause backup and versionining issues.

To disable them from being created on network locations, open a Terminal and run the following

defaults write DSDontWriteNetworkStores true

(Note: This only affects the currently-logged-in user)

Now in my case, I had these files all over my Synology NAS, so I was able to easily get rid of them by SSHing into the box and running the following:

find / -name .DS_Store -delete

And… done.

, , , , ,

Leave a comment

Disable indexing and generation of @eaDir directories on Synology NAS

Various forums throughout the Internet have users stating that even though they’ve disabled media indexing the @eaDir folders are still being generated, and even outside the indexed folders.

In order to completely stop the generation of @eaDir folders, it’s necessary to disable the services that are generating them.

Note that after a DSM update, these services may be re-enabled.

To disable these services, log in to your Synology NAS via SSH, then do the following:

cd /usr/syno/etc.defaults/rc.d/
chmod 000

After disabling the services, you may want to delete all the created @eaDir directories.

Any feedback on the above is welcome, please leave it in the comments section below. Thank you!

, , , ,

Leave a comment

Getting rid of the @eaDir folders on Synology NAS DSM

The @eaDir directories contain extended attributes and thumbnails that take up quite a bit of space, not unlike Windows Thumbs.db files.

Here’s how to get rid of them easily from the command line.

First, SSH into your Synology NAS box and log in as root, then type this to locate the @eaDir folders:

find . -name "@eaDir" -type d | more

If you’re happy you’re not going to accidentally delete something important, then make it happen:

find . -name "@eaDir" -type d -print0 | xargs -0 rm -rf

Note that after deleting the directories, you may also want to disable the services that created them.

Do you have any feedback on the above? Please leave it in the comments section below. Thank you!

, , , ,

Leave a comment

Controlling the front LEDs of a Synology NAS via ttyS1

You can control the front LEDs (as well as triggering other hardware events) on a Synology NAS by sending certain values to /dev/ttyS1, either from a script of from the CLI via Telnet or SSH.

These commands “force” the LED state, and therefore the LEDs can’t be used as status indicators after being forced. You can, however, simply reboot the NAS to restore normal operation; the settings do not survive a reboot.

Below are a list of commands that can be run from the command line (if you are logged in as root) or incorportated into a script. Note that the # character and everything after it are comments, and some characters require escaping.

These are only the commands I could get to work on my NAS.

echo 1>/dev/ttyS1 # Immediate power off (not graceful)
echo 4>/dev/ttyS1 # Power LED on solid
echo 5>/dev/ttyS1 # Power LED flash
echo 6>/dev/ttyS1 # Power LED off
echo 7>/dev/ttyS1 # Status LED off
echo 8>/dev/ttyS1 # Status LED on solid green
echo A>/dev/ttyS1 # USBCopy LED flash
echo @>/dev/ttyS1 # USBCopy LED on solid
echo B>/dev/ttyS1 # USBCopy LED off
echo C>/dev/ttyS1 # Immediate reset (not graceful)
echo :>/dev/ttyS1 # Status LED on solid amber
echo ;>/dev/ttyS1 # Status LED flashing amber

If you know if any other values to send to ttyS1, or anything else you’d like to share regarding this, please feel free to do so in the comments below. Thank you!

, , ,

Leave a comment

How to manually change the Symform contribution port on a Synology NAS

Symform is a cloud-based backup solution which allows you to have 10 GB of backup space free, and get additional free space, as well as support, by contributing space.

In order to contribute, you need to have a port forwarded to your Synology device. However, in my experience, I wasn’t able to choose the port (as it’s chosen randomly during installation). If the port number that the Symform service chooses is already taken, or you prefer to assign another port number, here’s how to do it.

To do this, you will already need to know how to set up port forwarding on your router, and install and set up the Symform service on your Synology NAS, as well as be familiar with how to SSH into your Synology NAS. This only shows you how to manually edit the contribution port number chosen by the Symform service.

Make sure the Symform service is stopped

Do this by logging into your Synology on the admin port (usually 5000 or 5001) and going to Package Center. Under Installed, you can stop the Symform service by clicking the stop button. Once the service is stopped (as shown below), you can continue.


SSH into your Synology NAS

If you haven’t already, turn on the SSH (or telnet) service by going to Control Panel > Terminal, and enabling the desired service. Next, SSH (or telnet) into your Synology NAS box. Once logged in, go to the Symform configuration directory by typing:

cd /volume1/@symform/lib

Next, open node.config with the vi editor:

vi node.config

Locate a line starting with <contribution enabled="True" fragmentStorePath= and scroll to the right of that line, and you will see port="43100" (or another port number). If you’re not familiar with the vi editor, carefully follow the following commands to edit the file in-place:

  • Press the a key to enter append (editor) mode
  • Cursor to the value and use the keyboard to edit it
  • Press the ESC key to exit editing mode
  • Type :w followed by enter to save the file
  • Type :q followed by enter to quit the editor

Now go back to Package Center and start the Symform service.

You will be able to see the updated port number in your Symform control panel.

If you have any questions, comments, or thoughts to share, please do so in the comments below. Thank you!

, , , , ,

Leave a comment

Basic Ubuntu VPS server backup via FTP or SSH SFTP

In my quest for the perfect “in my dreams” backup solution for my Ubuntu VPS, I created this very simple script which can be run as a cron job and can be easily modified to backup any amount of data to any remote FTP or SFTP server.

You could very easily include a database backup by running mysqldump beforehand, but I’m not including it in this script.

This required yafc to be installed, but Ubuntu installations can easily install it by running

sudo apt-get install yafc

And now, for the script:

# format of the open command is proto://username:password@HOSTorIP/
# proto is either ftp or ssh
# special characters in the username or password are not well tolerated
# anything in the EOF tags are direct commands to yafc. Test if unsure
DIR=`date +%F`
yafc <<EOF
cd backup-dir
mkdir $DIR
cd $DIR
put -p -r *

Enjoy! Questions, comments, and feedback are welcome and appreciated. Thank you!

, , , , , , , , ,

Leave a comment

Synology DiskStation and Samba mount permissions

So today I was using smbmount to mount a network share from my Synology DiskStation to my Linux PC when I noticed a rather annoying file permissions issue that I couldn’t seem to fix. Why am I using smbmount and not Gnome’s GUI to mount? Because I need root to have access to the file system as well so that CrashPlan can back up to it.

Here’s what happened:

First, I mounted the share (as root):

smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike

(For more information on the smbmount or the mount.cifs credentials file, see the Ubuntu manpage for mount.cifs)

That worked great, except for when I do this (as root)…

ls -ld /mnt/mynas

… I get the following output:

drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas

I sure didn’t want the directory world-writable. So I tried specifying file_mode and dir_mode as both 0755 using the following (as root):

smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0755,dir_mode=0755

Then I checked it:

ls -ld /mnt/mynas

… and got:

drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas

That didn’t do anything at all to help. Why? Because as it turns out the DiskStation is using a Samba server with CIFS extensions and is passing the permissions to smbmount (mount.cifs). The file_mode and dir_mode options are ignored if the remote server is using CIFS extensions.


If the server does not support the CIFS Unix extensions this overrides the default file mode.


If the server does not support the CIFS Unix extensions this overrides the default mode for directories.

Source: Ubuntu manpages.

So there’s a couple of options here. First, I could set it to mount somewhere inside /home/mike, which would generally protect it. But I’d really like to know what’s up with the file permissions. So I did a little more Google-fu.

As it turns out, the CIFS extensions on the DiskStation can be disabled, all it takes is to edit a file. Lepoulpe posted on the Synology forums the following edit:

you can disable “unix extensions” in the ds106’s samba server. To achieve this, you need to add the folowing line in the [global] section of /usr/syno/etc/smb.conf :

unix extensions=no

So, I SSH’d into my DiskStation as root (should be the same password as ‘admin’ if you’re having trouble) and used the vi editor to make the edit. Afterwards, I restarted samba on the DiskStation by doing this:

/usr/syno/etc/rc.d/ restart

Then I remounted the Samba share as root…

smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0750,dir_mode=0750

… and checked the permissions:

ls -ld /mnt/mynas

… and got the following output:

drwxr-x--- 17 mike mike 0 2011-05-20 09:25 mynas

Exactly right.

So now I have /mnt/mynas mounted to my share on the DiskStation. If I wanted it to mount on boot, I could add something like the following to /etc/fstab:

//diskstation/mike /mnt/mynas smbfs auto,credentials=/home/mike/mike.cred,uid=mike,gid=mike,dir_mode=0750,file_mode=0750,user 0 0

Questions about my method? Have any feedback or alternate methods to share? Please feel free to do so in the comments below. Thank you!

, , , , , , ,

Leave a comment

PGP/GPG Keys in Ubuntu Gnome the easy way

For the security-minded, or anyone who simply wants to be able to exchange secure, encrypted email quickly and easily, GNOME offers a really user-friendly way to generate and manage PGP/GPG keys. This program is located at System > Preferences > Passwords and Encryption Keys. [Natty/Unity: System Settings > Passwords and Encryption Keys]

You can make a new key by going to File > New… > PGP Key. This guide explains some of the basic key management functions in this application.

Fill in the name, email, and an optional comment. PGP is considered a network of trust, so etiquette states you should use your common legal name (shortened versions are ok) and your primary email address (unless you have a reason to do otherwise). If you frequently go by a nickname, enter that in the comment field.

If you’re interested in the advanced options, you can change them by dropping down “Advanced Key Options.” I’m not going to go too much in to what the various options are, but here’s a quick run-down:

Encryption Type: RSA is generally considered stronger and overall a better choice than DSA. Choose “sign only” if you’re using this as a signing key, and not an encryption key. Only select that option if you know what you’re doing.

Key Strength (bits): The higher the number, the stronger the encryption, but the longer it takes.

Expiration Date: Set this if you want your key to expire at a predefined date/time, or set to never expire. Expiration keys can still decrypt messages, but no new messages can be encrypted to them.

After choosing your options, you’ll be prompted to enter your key pass phrase. DO NOT FORGET IT! Your key will be completely unusable (and you will be unable to revoke it) if you forget the pass phrase. On the same token, avoid making it too easy or guessable.

Next, the key will be generated. This could take a while depending on the key size and the speed of your computer.

Once your key is generated, your public keyring and private keyring will be stored in ~/.gnupgNEVER distribute your private keyring (secring.pgp). This is the decryption segment of your keyring.

Next, some more exploration through the Passwords and Encryption Keys application.

Right-clicking on a key gives you the following options, which I’ll explain briefly.

Properties: Here is where you can change your passphrase, add a photo, view your key’s fingerprint, and edit the expiration date and trust level.

Export: This is where you can export your public key for distribution to others (this is the portion of the key that you DO share). By selecting export, you will export an “ASCII-armored” file that can be pasted in email, etc.

Copy: Similiar to export, Copy copies your “ASCII-armored” public key to the clipboard. Makes it easier to post in email, web page, etc.

Delete: This deletes the key. Make sure this is what you want to do!

Sign Key: This is a core part of the key-sharing portion of PGP/GPG. This “signs” the key, using your key. This applies your signature to the key, explicitly stating that you trust the key to some degree. Once you’ve signed the key, you should export the key and send it back to the originator so they can begin distributing it with your signature attached.

So how do you sign a friend’s key?

First, have them export it and send it to you. Next, drag-and-drop the file into the Passwords and Encryption Keys window. It will appear under the Other Keys tab. Once the key has appeared, just right-click on it and click ‘Sign…’ Follow the prompts. Don’t forget to export the key and return it to the sender after you’ve signed it! Work this process in reverse for getting a friend to sign your key. Drag/drop the updated keys back into your key manager to add the new signatures. To verify signatures are present, double-click on the key and look at the Names and Signatures tab.

That’s a quick run-down of the key management functions.

Questions, comments, and feedback about key management are welcome and appreciated. Note that key management may be different in the Unity interface, which is shipped with Ubuntu Natty.

, , , ,

Leave a comment