ssh

Easy SSH Automation

Adam McPartlan — Fri, 15 Jun 2018 13:30:00 +0000

A script a day will allow you some freedom to play and build other useful and more complicated scripts. Every day, I attempt to make my life easier—by this I mean, trying to stop doing the repetitive tasks. If a process is repeatable; it can be scripted and automated. The idea to automate everything is not new, but try automating a command on a remote host.

SSH is very flexible, and it comes with many options. My absolute favorite is its ability to let you run a command on a remote server by passing the -t flag. An example:


ssh -t adam@webserver1.test.com 'cat /etc/hosts'

This will ssh to webserver1.test.com, then run cat /etc/hosts in your shell and return the output.

For efficiency, you could create an SSH key pair. It's a simple process to create a passwordless public and a private key pair. To set this up, use ssh-keygen, and accept the defaults ensuring you leave the password blank:


ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/adam/.ssh/id_rsa): y
Enter passphrase (empty for no passphrase): LEAVE BLANK
Enter same passphrase again:
Your identification has been saved in /home/nynet/.ssh/id_rsa.
Your public key has been saved in /home/nynet/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jUxrQRObADE8ardXMT9UaoAcOcQPBEKGU622646P8ho
 ↪adam@webserver1.test.com
The key's randomart image is:
+---[RSA 2048]----+
|B*++*Bo.=o       |
|.+.              |
|=*=              |
+----[SHA256]-----+

Once completed, copy the public key to the target server. To do this, use ssh-copy-id:


ssh-copy-id adam@webserver1.test.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/adam/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
 ↪to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if
 ↪you are prompted now it is to install the new keys
adam@webserver1.test.com's password: ********
Number of key(s) added:        1

You will be asked for the password of the target server.

If you have set this up correctly, you won't be asked for your password next time you ssh to your target.

Execute the original example. It should be quicker now that you don't need to enter your password.

If you have a handful of servers and want to report the running kernel versions, you can run uname -r from the command line, but to do this on multiple devices, you'll need a script.

Start with a file with a list of your servers, called server.txt, and then run your script to iterate over each server and return the required information:

Go to Full Article

Two Factors Are Better Than One

Kyle Rankin — Thu, 09 Mar 2017 13:12:03 +0000

by Kyle Rankin

Although I've always been interested in security, there are just some security measures I've never liked. SSH brute-force attacks end up being a major way that attackers compromise Linux systems, but when it comes to securing SSH, I've never been a fan of changing your SSH port to something obscure, nor have I liked scripts like fail2ban that attempt to detect brute-force attacks and block attackers with firewall rules. To me, those measures sidestep the real issue: brute-force attacks require password authentication. If you disable password authentication (set PasswordAuthentication to no in your sshd_config) and use only SSH keys, you can relax about all those brute-force attacks knocking on your door.

In a past article ("Secret Agent Man", December 2013), I wrote about why you should set a passphrase on your SSH keys and how to use SSH Agent to make password-protected keys a bit less annoying. In one respect, you can think of password-protected SSH keys as a form of two-factor authentication. The key is something you have, and the password is something you know. The problem, however, is that if you host a system with multiple users, you can't enforce password-protected SSH keys from the server side. So in this article, I discuss how to add two-factor authentication to an SSH server that accepts only keys.

These days, more services on-line offer two-factor authentication (2FA) as an extra layer of security on top of a user name and password. After you perform your normal authentication, you provide your 2FA token (usually a string of digits) that authenticates you. Although in the past, 2FA required you to carry around a special hardware dongle, these days, a number of software approaches can use your cell phone instead. Some approaches use TOTP (Time-based One-Time Password), so your phone just needs accurate time but no network to function. Other approaches use push notifications, SMS or even a phone call to share the 2FA token, and some implementations can use all of the above.

Some 2FA SSH implementations work via the ForceCommand directive placed in the SSH configuration for a particular user and let you enable 2FA on a per-user basis. Others offer a PAM module you can add system-wide (and use for sudo authentication as well as SSH). Although a number of excellent 2FA SSH implementations exist for Linux, I've chosen Google Authenticator for a few reasons:

It's free, and the source is available.
It's been available and tested for a number of years.
Packages are available for a number of distributions.
Clients are available for a number of phone operating systems.
It uses a custom PAM module, so it's easy to add 2FA system-wide.
It provides a backup in the form of backup codes in case users lose or wipe their phones.

Go to Full Article

Secret Agent Man

Kyle Rankin — Tue, 28 Feb 2017 13:50:44 +0000

by Kyle Rankin

It used to be that only the paranoid among us focused on strict security practices, yet these days, it seems like people are stepping up their games with respect to encryption, password policy and how they approach their computers in general. Although I always have considered myself more inside that paranoid camp than outside of it, I even have found myself stepping up my game lately. Security is often at odds with convenience, yet whenever I need a good example of better security practices that are more convenient than the alternative, I turn to SSH keys.

With SSH keys, you generate a private and public key pair with the ssh-keygen command and distribute the public key to servers to which you want to connect. SSH keys use your private key to authenticate yourself instead of a password on the remote server, so if you are one of those people who are worried about SSH brute-forcing, if you use SSH keys, you can disable password SSH authentication altogether and not care about those SSH brute-force attempts you see in your logs. When I used to set up SSH key pairs, I wouldn't provide a passphrase to unlock the key. Without a passphrase, I could just ssh in to a machine without typing any sort of password—a case where you can increase security against brute-force SSH attacks while also increasing your convenience.

Of course, the problem with skipping the passphrase when you generate SSH keys is that all of your security relies on keeping your private key (usually found at ~/.ssh/id_rsa or ~/.ssh/id_dsa) secret. If others were able to get a copy of that file, they could log in to any machine to which you distributed the public key. Lately I decided I didn't like that kind of risk, so when I generate SSH keys, I now use a passphrase. This means if others got my private key, they couldn't immediately use it, but it also means I now have to type in a passphrase to use my SSH key. This is less convenient, but I've found that by using SSH agent, I can get back to a similar level of convenience but with a few added bonuses that I discuss in this column.

SSH Agent

On most systems that use sudo, after you type in your sudo password, it is cached for some period of time, so if you run a few sudo commands in a row, you don't have to keep typing in your password. SSH agent works in a similar way for SSH passphrases, caching your unlocked key in memory for a defined period of time. This is particularly useful if, like me, you use Git on a routine basis with SSH—it would be a pain to have to type in your passphrase every time you do a git push or git pull. So for instance, if I wanted to cache my passphrase for 15 minutes, I could type:


$ ssh-add -t 15m

Then after I provide my password a single time, it would be cached for the remainder of SSH commands I run within that 15 minutes, after which it would expire.

Go to Full Article

One Port to Rule Them All!

Shawn Powers — Mon, 06 Jul 2015 16:22:38 +0000

by Shawn Powers

I was chatting with Fred Richards on IRC the other day (flrichar on freenode) about sneaking around hotel firewalls. Occasionally, hotels will block things like the SSH port, hoping people don't abuse their network. Although I can respect their rationale, blocking an SSH port for a Linux user is like taking a mouse away from a Windows user! I mentioned that I used to have a remote server running SSH on port 443 so I still could get to my servers. (Port 443 is the HTTPS port, which is rarely blocked.)

I also mentioned that it was inconvenient to use port 443 for SSH, because it meant I couldn't host secure Web sites on that server. Fred graciously pointed me to sslh, which is an awesome little program that multiplexes (or maybe de-multiplexes?) network traffic based on the type of traffic it sees. In simple terms, it means that sslh will listen for incoming connections on a port like 443, and if it's a request for a Web page, it will send the request to Apache. If it's an SSH request, it sends it to the SSH dæmon. It also has support for OpenVPN traffic, XMPP traffic and tinc.

Conceptually the program is simple, but I never considered it would be something a simple open-source application could manage! I assumed it would require a hardware appliance and lots of horsepower. I'm happy to say I was very, very wrong. In fact, it's such an impressive piece of software, it gets this month's Editors' Choice award! If you'd like to reach your SSH server over port 443 while still hosting secure Web pages, check out sslh at https://www.rutschle.net/tech/sslh.shtml.

Go to Full Article

AutoSSH, for All Your

Shawn Powers — Mon, 05 May 2014 16:34:35 +0000

by Shawn Powers

I love SSH. I mean, I really, really love SSH. It's by far the most versatile, useful, amazingly powerful tool in my system administration quiver. One of the problems with SSH, however, is that when it dies, it doesn't automatically recover. Don't get me wrong. It's easy to recover with SSH, especially if you've set up public/private keypairs for authentication (I show you how to do that over here). But if the SSH connection dies, it's difficult to reestablish.

In the past, I've done something like enclosing the SSH command in an endless WHILE loop so that if it disconnects, it simply starts over. (I talk about WHILE loops in this month's Open-Source Classroom.) With AutoSSH, however, even if an SSH session is still active, but not actually connected, it will disconnect the zombie session and reconnect a fresh one, without any interaction.

Image Credit: AllenMcC, Wikipedia User

I personally use AutoSSH to keep reverse tunnels active inside a remote data center that is behind a double NAT. Getting into the data center remotely is very difficult, but if I can establish a tunnel from inside the double-NAT'd private network to my local server, getting in and out is a breeze. If that SSH tunnel dies, however, I'm locked out. In my particular case, the data center is an entire continent away, so driving over isn't an option. With AutoSSH, if something goes wrong, it will keep attempting to reestablish a connection until it succeeds. The program has saved my bacon more than once, and because it's so incredibly useful, AutoSSH takes this month's Editors' Choice award. It's most likely already in your distribution's repositories, but you can check out the Web site at https://www.harding.motd.ca/autossh.

Go to Full Article

More Secure SSH Connections

Federico Kereki — Mon, 31 Mar 2014 19:45:15 +0000

by Federico Kereki

If you need remote access to a machine, you'll probably use SSH, and for a good reason. The secure shell protocol uses modern cryptography methods to provide privacy and confidentiality, even over an unsecured, unsafe network, such as the Internet. However, its very availability also makes it an appealing target for attackers, so you should consider hardening its standard setup to provide more resilient, difficult-to-break-into connections. In this article, I cover several methods to provide such extra protections, starting with simple configuration changes, then limiting access with PAM and finishing with restricted, public key certificates for passwordless restricted logins.

Knock for SSH

Trying to attack your machine will be harder if the would-be invader cannot even find a possible SSH door. The methods shown in this article are compatible with the port-knocking technique I wrote about in a previous article ("Implement Port-Knocking Security with knockd", January 2010), so I won't go into knockd configuration here. By using all techniques together, attackers will have an even harder time getting to your machine (where all the other measures shown in this article will be waiting), because they won't even be able to start trying to attack your box.

Where Is SSH?

As defined in the standard, SSH uses port 22 by default. This implies that with the standard SSH configuration, your machine already has a nice target to attack. The first method to consider is quite simple—just change the port to an unused, nonstandard port, such as 22022. (Numbers above 1024 are usually free and safe, but check the Resources at the end of this article just to avoid possible clashes.) This change won't affect your remote users much. They will just need to add an extra parameter to their connection, as in ssh -p 22022 the.url.for.your.server. And yes, this kind of change lies fully in what's called "security through obscurity"—doing things obscurely, hoping that no one will get wise to your methods—which usually is just asking for problems. However, it will help at least against script kiddies, whose scripts just try to get in via port 22 instead of being thorough enough to try to scan your machine for all open ports.

In order to implement this change, you need to change the /etc/ssh/sshd_config file. Working as root, open it with an editor, look for a line that reads "Port 22", and change the 22 to whatever number you chose. If the line starts with a hash sign (#), then remove it, because otherwise the line will be considered a comment. Save the file, and then restart SSH with /etc/init.d/sshd restart. With some distributions, that could be /etc/rc.d/init.d/sshd restart instead. Finally, also remember to close port 22 in your firewall and to open the chosen port so remote users will be able to access your server.

Go to Full Article

There's Browser in My SSH

Shawn Powers — Wed, 17 Jul 2013 21:44:27 +0000

by Shawn Powers

No, there's SSH in my browser! Although it may not be as logical of a combination as chocolate and peanut butter, for Chromebook users, an HTML5 SSH client is pretty amazing. Granted, Google's "crosh" shell has SSH abilities, but it's a very limited implementation. With the Chrome extension "Secure Shell", it's easy to SSH in to remote servers and interact like a traditional terminal window—mostly.

Secure Shell is getting better all the time, and at the time of this writing, it supports port forwarding, logging in with keys, socks proxying and even many keyboard shortcuts for programs like Irssi. The keyboard shortcut support isn't perfect, but for me at least, it's manageable.

Figure 1. It's simple. It's texty. It's awesome.

If you're a Chromebook user and want a real SSH client, give the "Secure Shell" extension a try. Heck, regardless of the OS you're using (I'm looking at you, Windows), it's a fast way to get a secure connection. It's being developed by Google, and it's free via the Play Store.

Go to Full Article

Fabric: a System Administrator's Best Friend

Adrian Hannah — Tue, 09 Apr 2013 19:09:40 +0000

by Adrian Hannah

Do you routinely make changes to more than a dozen machines at a time? Read this article to find out about a tool to make that task much easier.

I'll be honest. Even though this library is fully five years old, I hadn't heard of Fabric until about six months ago. Now I can't imagine not having it in my digital tool belt. Fabric is a Python library/tool that is designed to use SSH to execute system administration and deployment tasks on one or more remote machines. No more running the same task, machine by machine, to make one change across the board. It is a simple fire-and-forget tool that will make your life so much simpler. Not only can you run simple tasks via SSH on multiple machines, but since you're using Python code to execute items, you can combine it with any arbitrary Python code to make robust, complex, elegant applications for deployment or administration tasks.

Installation

Fabric requires Python 2.5 or later, the setuptools packaging/installation library, the ssh Python library, and SSH and its dependencies. For the most part, you won't have to worry about any of this, because Fabric can be installed easily through various package managers. The easiest, and most prolific way to install Fabric is using pip (or easy_install). On most systems, you can use your systems package manager (apt-get, install, and so on) to install it (the package either will be fabric or python-fabric). If you're feeling froggy, you can check out the git repository and hack away at the source code.

Once installed, you will have access to the fab script from the command line.

Operations

The Fabric library is composed of nine separate operations that can be used in conjunction to achieve your desired effect. Simply insert these functions into your fabfile and off you go:

get(remote_path, local_path=None) — get allows you to pull files from the remote machine to your local machine. This is like using rsync or scp to copy a file or files from many machines. This is super effective for systematically collecting log files or backups in a central location. The remote path is the path of the file on the remote machine that you are grabbing, and the local path is the path to which you want to save the file on the local machine. If the local path is omitted, Fabric assumes you are saving the file to the working directory.
local(command, capture=False) — the local function allows you to take action on the local host in a similar fashion to the Python subprocess module (in fact, local is a simplistic wrapper that sits on top of the subprocess module). Simply supply the command to run and, if needed, whether you want to capture the output. If you specify capture=True, the output will be returned as a string from local, otherwise it will be output to STDOUT.

Go to Full Article

Safer Access without Passwords

Johan Thelin — Wed, 06 Jul 2011 13:00:00 +0000

by Johan Thelin

How do you make sure that your passwords are safe? You can make them longer, complicate them by adding odd characters, making sure to use different passwords for each user account that you have. Or, you can simply skip them all together.

The secure shell, ssh, is a key tool in any Linux user's toolbox. As soon as you have more than one machine to interact with, ssh is the obvious choice.

When logging into a remote machine through ssh, you are usually prompted with the remote user's password. An alternative to this is to use an asymmetric key pair.

An asymmetric key pair consists of a private and public key. These are generated from an algorithm - either RSA or DSA. RSA has been around for a long time and is widely supported, even by old legacy implementations. DSA is safer, but requires v2 of the ssh protocol. This is not much of an issue in an open source world - keeping the ssh daemon implementation up to date is not a problem, but rather a requirement. Thus, DSA is the recommended choice, unless you have any specific reason to pick RSA.

The generated keys are larger than a common user password. RSA keys are at least 768 bits, default 2048 bits. DSA keys are 1024, as the standard specifies this.

To generate a DSA key, use the following command:

$ ssh-keygen -t dsa

This generates the files ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. You can specify a passphrase in the key generation process. This means that they key only can be used in combination with a passphrase, adding to the security.

The generated file ending with pub is the public half of the pair. This can be shared with remote hosts that you want to ssh to. The other file, id_dsa, is the private half of the pair. This must be protected just as you password. I.e. do not mail this, do not store it on untrusted machines, etc.

Having a 1024 bits long key can be thought of as having a 128 characters long password. This means that the key pair method is safer than most passwords that you can remember. Keys are also completely random, so they cannot be cracked using dictionary attacks. This means that you can increase the safety of your remote host by disabling logins using passwords, thus forcing all users to use key pairs.

Having generated your key pair, all that is left is copying the public half of the key to the remote machine. You do that using the ssh-copy-id command.

$ ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote

This adds your key to the remote machine's list of authorized keys. Just to be on the safe side, it is also good to ensure that the ~/.ssh and ~/.ssh/authorized_keys aren't writable by any other user than you. You might have to fix this using chmod.

Having added the key to the remote machine, you should now be able to ssh to it without using a password.

Go to Full Article