Tag Archives: sysadmin

SSH Tips – How to Login Securely Without a Password

old fashioned keys SSH is a wonderful tool and will let do do all kinds of amazing things – not to mention that it does them securely. However sometimes when you’re trying to automate steps, or are performing the same steps repeatedly on a trusted machine, the frequent retyping of your username can be a pain. Worse still, if you’re writing a script, you certainly don’t want to hardcode passwords into it for others to grab. In this case, what you can do is use ssh keys to secure your connection.

How to do this differs depending on the operating system of the source machine, IE the machine you are SSHing from. Suppose you have two machines, the local one (your laptop) and the remote one (some server, eg my.server.com) To ssh from the laptop to the server without needing a password, perform these steps:


On the local machine:
% ssh-keygen -t rsa
Either put in a passphrase or just hit return twice to skip. Note that using a passphrase makes it more secure, but makes automation tricky.

This produces a file called id_rsa.pub in a subfolder called .ssh underneath your some directory. Now you need to transfer that file to the remote server. Note that you’ll need your password to perform this step, and to avoid troubles we’ll rename the file during transfer.

% scp ~/.ssh/id_rsa.pub USERNAME@my.server.com:id_rsa.pub.mylaptop

Now we need to add the id_rsa.pub keys to the proper file on the remote machine (my.server.com). Note that if you don’t already have a .ssh folder on the server, you can just create it, or better yet, run the ssh-keygen command there, as above.

% ssh USERNAME@my.server.com
% cd .ssh
% cat ~/id_rsa.pub.mylaptop >>; ~/.ssh/authorized_keys
% rm ~/id_rsa.pub.mylaptop

Make sure .ssh dir and all it’s files don’t have any open group or other permissions, or this won’t work.

% cd ~/.
% chmod -R go-rwx .ssh

Here’s an example of what the authorized key file will look like. Note that there will be one line (word-wrapped) per each user/machine that has exchanged keys in this manner.

%cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAyJnwH/k4/FdY88p2utHHDc5VSJqL97n/nsK1PkW9q9KWddMIu8u+Golyg4RW10nIGs3A4EYYPn9Gu7dJy+vhO2xRJM4A+EEF/9nYYy/ZLXBlh4V3zMRYLom6TZx9OSTA6L0z9HKdopgJ/HnQ+yEFzS29TBjCs/9Dy4+iS0uVhWs= root@krysia.afraid.org


Use your favorite ssh tool and check it’s documentation. For now I’ve used puttygen, it should be where you installed putty, probably something like c:\bin. It is a graphical program for managing keys on windows with putty.

Select “SSH2 (RSA)” as the type of key (at the bottom of the screen)

Select “generate” and follow the instructions. It wants you to move your mouse around in a block for awhile to generate randomness. Then it makes a key.

Select “save private key” and either give it a passphrase, or ignore it when it tells you to think about using a passphrase. you can save your private key to disk somewhere. Note that using a passphrase makes it more secure, but makes automation tricky.

Select “save public key” and save it to disk somewhere.

In the normal putty window select load to pull in the profile you want to add the key to. Go to Connection and put the ID in the “auto-login username” box. IE your unix login name.

In the SSH Auth section select the browse button to go to where you stored the private key file, and select it. THen go to the “session” category and select save.

Now you need to take the public key stuff and add it to your ~/.ssh/authorized_keys file on the ssh server machine. If you’re using putty you have pscp that you can use. It’s in the same dir where you put your putty executable.

c:\> cd dir_with_public_key_file
c:\> pscp putty_public_key_file USERNAME@my.server.com:id_rsa.pub.mylaptop

Now connect to the remote system using ssh so you can add your public key to their authorized keys file, IE use ssh or putty. After you’re connected, edit the file you put there, id_rsa.pub or whatever you called it.

Remove the first line of the file that says “BEGIN SSH2 PUBLIC KEY”

Remove the last line of the file that says “END SSH2 PUBLIC KEY”

Remove the line that says “Comment: ”

At the beginning of the first line insert “ssh-rsa ”

At the end of the last line after the =, put something that says what the key is for future reference. IE your user/machine name, like this, instead of “=” put “= user@machine.company.com”

Now there are probably 4 lines in this file, and they all need to be joined into one line. Plus if joining creates spaces they will need to be removed.

Now you can append this to the ~/.ssh/authorized_keys file:

% cat ~/id_rsa.pub.mylaptop >> ~/.ssh/authorized_keys
% rm ~/id_rsa.pub.mylaptop

As an extra bonus, if you’re trying to use the pscp command line in windows (it’s the windows equivalent for scp in unix) then here’s how to do it.

Make sure you’ve done the public key transfer, as above. Then when you call pscp, just pass the “-load” option with the name of the “profile” that you’re using.

Hopefully this helps – I find it very useful. If there are other operating systems, or other tips you’d like to know, just ask.

Virtual Machine Networking Options

3Q12 10:01 Derby RTC - Carlisle Wapping Sidings

I am frequently asked to help people setup virtual machines. One of the most common questions is about how to setup networking properly, so I thought I’d share that information here.

Virtual machines have a variety of networking setups available. In addition there are also many options for the underlying OS, such as Windows, OSX, or Linux. Before you can make real use of a virtual machine, it will be necessary to make sure that you have a proper IP address. Enterprise deployments should be on a dedicated hypervisor, such as
vSphere / ESXi from VMware, VirtualBox, Hyper-V, etc. For them you setup networking as you would any other machine.

The VM can use either a static IP address or DHCP. By default virtual machines are often preset for DHCP or dynamic setup. If you want to use a static address you will need to set it to an appropriate value. For more details on linux networking, check the Ubuntu Network Configuration guide.

Desktop VM Network Configuration
VMware provides three types of networking configurations: Nat, Bridged, and Private or host-only. I expect most desktop hypervisors to have similar options.

NAT addressing
NAT means that the VM is running on a private network confined to the host machine. It can see external machines, but is generally unavailable to other machines on the network – they cannot see it. The IP address for the VM is supplied from the VM server itself, using DHCP. This setup is well suited to normal, personal use or a demo, but is usually inappropriate for an actual deployment.

Bridged addressing
Bridged lets your virtual machine share the network adapter from the host machine. In
this setup, your machine gets a “normal” IP address on your network. Typically this
is something like DHCP, and may require you to give the MAC address of the VM to your system administrator. This is a good setup if you need others to be able to access the VM. You can find your MAC address by following the instructions above under “Getting the MAC address”. If you know the correct range of IP addresses, you can also assign a fixed address this way, but you’ll need to have all the necessary information for a static network configuration.

Host-only addressing
Host-only mode lets your VM ONLY see your host machine. The VM has no access to
the network or the world at large. This is ok for certain demos, but not useful for general purpose use. It is very secure.

Your Address
You can find your network address and mac address either by using the ifconfig command from a prompt for linux, (described above under “Getting the MAC address”), or from the user menu when logged in you can select “System – Preferences – Network Connections”. For windows you can using the ipconfig command or right-click your networking icon.

Getting the MAC address
If you want to use DHCP for the address, you will probably need to give the MAC address for the VM to your system administrator. Some networks may require the MAC address for any access at all. From the VM terminal (see “logging in” for details) you can run the command: “ifconfig”. You will see two or more entries. One is “lo” which is for the loopback and can be ignored. The other should be eth followed by some number, such as eth1 or eth2. Take note of this value as you will use it later on in the configuration. On the same line as the ethx you should see a label that says “HWaddr” – the value following that label is your mac address for that network interface.

If there are others tricks you know, please share them. If there are other topics you’d like me to cover, let me know.

Subversion – SVN Server Models

Subversion - SVN

Subversion aka SVN is a very popular source control system. A lot of people have asked about using SVN+SSH as an “easy” way to setup an svn server. I feel that using https is a much better choice for several reasons.

In a nutshell, SVN+SSH has security issues. While it secures the communication, it leaves the repository itself vulnerable to every user, who can accidentally damage any or all of the repository. SVN+SSH also has potential file-locking issues. It is more of an SSH over the file:// protocol than it is SSH over SVNSERVE. See below for more detail.

In addition, SVN+SSH has NO LOGGING of activity. If the server starts to have problems, you don’t get any useful information, because SVN+SSH isn’t actually using a server, it’s really just filesystem access. SVN+SSH has higher TCO because you have to maintain SSH accounts for each user.

Apache setup is slightly more difficult, but still usually under an hour for a complete install from scratch, or you can do it easier by downloading a stack from VM ready to go from places like Bitnami. Ongoing apache is much easier to maintain, is more secure, more flexible, provides more options, has logging, and many other features outlined in the attached docs.

Let’s take a look at the variety of ways in which you can access an SVN repository. Each has advantages and disadvantages, but the apache method is the most common among enterprise users because of it’s flexibility, security, and rich feature set.
It’s a bit more complex than some of the others initially, but still a whole lot easier than some other systems out there like ClearCase. A novice following any of the many tutorials should be up in less than an hour. Ongoing administration is actually easier than some of the others, providing a lower TCO.

“The most common problem administrators run into is repository ownership and permissions.” SVN Book: Supporting Multiple Repository Access Methods

A list of the models and a brief summary for each follows.
• apache aka webdav
svn+ssh SVN over ssh
• svnserve daemon
• svnserve via xinetd or as a windows service
• file:// access the repository directly without any server

Using SVN with the webdav apache plugin is one of the most common ways to setup an SVN server. The advantage is that it’s almost as easy to setup as the other modes, but provides much better security and actually less ongoing administration. Using https makes it slightly more difficult – mostly because you need to setup a certificate if you don’t already have one. Adding a self-signed certificate to my own SVN setup took me about 15 minutes.

This method has additional capabilities around access control, and can even use existing directory services such as LDAP. svn+ssh only allows access control to the whole repository. It’s also the only server model that has logging to keep track of errors and usage. (SVN book chapter 6 – server configuration Table 6.1 – comparison of server options)

Additionally there are some neat things about having a web server with your SVN, like getting a repository browser for “free” (IE no extra effort) which is really helpful when people want to discuss items in source control without necessarily checking them out.

Bottom line, webdav is the best bet, since it uses a multithreaded server that can handle concurrency without corrupting your database. Apache also supports authentication with client certificates, if you’re concerned about security. (see also Using svn over ssh and the SVN book chapter 5, section 4)

svn+ssh can be thought of as a remote-enabled version of the file:// protocol, rather than a secure version of svnserve since it really isn’t using svnserve.

“It’s essentially the same as a local user accessing the repository via file:// URLs.” from the SVN book chapter 6 – svnserve over a tunnel

It adds security to an SVN implementation, but at the cost of system performance (which is the one real advantage of the non-apache models). It also has ongoing administration issues, as well as some potential problems with concurrency. Generally only recommended for installations that already have an existing ssh account infrastructure, and even then recommended with the following caveat from the SVN book chapter 6: no logging, not even errors. All users have to be in the same system group or used a shared SSH key, and if used improperly can lead to file permission problems. Requires real system accounts on the server host, leading to higher TCO.

Another potential security issue is that with actual SSH accounts, the users can login to the SVN server and delete the entire repository, because of how file permissions have to be setup for this model.

The SVN book recommendation section essentially reads that if you already have an infrastructure it makes sense, but we (the SVN people) don’t widely recommend this option. Further

“… we warn against accessing repositories via svn+ssh:// URLs_from a security standpoint, it’s effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn’t careful.”

svnserve operates directly on the repository files (using file:/// urls), which means if you ever have two svnserve processes running at the same time (NOTE: this is standard for svn+ssh), you can get contention, which usually results in a locked repository that has to be taken offline, repaired, and reenabled.

svnserve is relatively simple to setup and fast. But isn’t not secure at all. There are potential permissions issues, leading to ongoing administration headaches. It’s only recommended for small teams just getting started. From the SVN book chapter 6: no logging, no web browsing, no encryption, clear-text passwords. If that doesn’t make you nervous, then go ahead.

xinetd or a windows service
Essentially the same as svnserve by itself (see previous paragraph), except that the daemon is fired “on-demand” which could potentially save some small amount of system resources. On windows you can do the same thing running svnserve as a windows service.

Using the direct access method is not multi-user and not secure. Super fast easy setup, because there is none. Not supported by some clients and third-party tools. It’s not even listed under the section for server setup in the SVN book.

Essentially this is an easy way to learn how to deal with subversion or perhaps setup a single person SVN installation. However if there are any long-term plans, going the few extra steps to setup an actual server are highly recommended. It’s best to think of this as a testing method rather than a deployment model.

If you have further questions, let me know and I’ll try to help. If you’d like to hear about other source controls systems, send me your suggestions.

The Ins and Outs of Opting and Privacy

There has been another rash of security and privacy issues by major internet companies. Actually it’s more of an ongoing issue than it is a recent outbreak. And much of the ongoing trouble is related to a poor understanding of “opt in” vs “opt out” methodologies, and some pretty poor business choices in that area.

Keep Out © by Aaron Jacobs

Google (GOOG) just announced that wireless network owners can no “opt out” from its Wi-Fi geolocation map database. Many have greeted this as good news and responsible behavior on Google’s behalf. Others, myself included, view this as a classic case of a business doing essentially nothing to change it’s behavior, and then promoting the non-effort as a valuable security benefit to their customers and the world at large. Google believes that once you’re using any of their services, you’ve essentially opted in to anything they want to do. More on that in a minute.

Another consumer favorite, Facebook appears to be tracking 90 days of everything it’s users (and some suggest even former users) browse on the web. This is beyond just tracking what you’re doing inside Facebook itself. And there are also allegations over whether or not they actually are storing profile information about people who have not even joined Facebook. This is another company that believes in a policy of opting you in to anything they want and then letting you opt back out. They know that a lot of people aren’t savvy enough to understand, others too lazy, and others will never even be aware of the issues.

Verizon (VZ) tracks everything you do with your phone, so do pretty much all the cell phone companies. Recently Verizon started allowing people to opt out. Josh Constine at TechCrunch mentions that at least they don’t call it “Greater Choice” like Google does. But his take is everyone is saying “Why can’t we be evil too?”

Strangely enough, AT&T (ATT) takes the opposite move of letting people opt in. Pretty ironic for a company who’s logo resemble the Death Star, but commendable.

The problem with “opt out” is that it works well outside of privacy areas. It also works in areas where you have an explicit relationship. For example, if I create a Google account it will keep track of what I search, unless I opt out. Most companies that have web accounts work in this way, for example with their email lists. This is a very reasonable method – you contacted me, so you don’t mind if I contact you. You see this normally as little “send me your junk email” boxes. You can judge the company based on whether the boxes are clicked or empty by default on their sign-up forms.

The stakes for things like this are low – the worst case is that some web site sends me a bunch of junk email, and if they’re a responsible company, they’ll respond to my “stop that” request.

The difference with privacy issues is that the stakes are much higher, and the awareness is much lower. If someone decides that by using their website I agree to let them track my every move on the web, it’s unlikely that I’ll ever figure it out. And they may end up being privy to something I didn’t want to share with them. Opting people in by default to such things is unethical behavior at best. What’s the rational connection between me using your website and me giving you permission to spy on all my web activities? There is none of course.

In the case of the Google Wi-Fi mapping they’re collecting your data whether or not you have a relationship with them. This is one step worse than the Facebook issue. In this case they’re literally driving the streets of the world looking for Wi-Fi (we used to call this warchalking) and then adding you to a database. You may not even be aware they’re collecting your data. In fact, the odds that homeowners ARE aware are extremely small. And yet they’re using on opt out methodology, just to cover their butts. Which essentially means that they’re opting you in to something, without your permission, without your awareness. And they justify that because their company motto is “Do No Evil”.

The truth is that it’s a very questionable practice to collect someone’s information without their knowledge. If they want to build a database, then can simply switch to an opt in method. Instead of my changing my SSID if I happen to know that they might drive by someday, (which is inconvenient because I have to reset all the devices using my network, including frequent guests devices) they can go to a method where they only collect data from those who indicate willingness by changing the name. Instead of changing my SSID from “mynetwork” to “mynetwork_nomap” to opt out, I should be able to change to “mynetwork_map” to opt in. Anyone who doesn’t want it doesn’t have to do anything. Anyone who is unaware will not be unintentionally opted in. Anything less is not only unfriendly to consumers, it’s just plain evil.