Posts tagged with “shell”
After my previous post, I realized I've wanted a simple way of uploading & authorizing my public key on new servers. After some searching I found a script that I tweaked a bit and put it on gist.
This gist has 2 versions, one is a shell function, the other a shell script. For some people it'll probably be easier just grabbing the script and putting it in their path like at /usr/local/bin/sshput. Some might like putting it in their zshrc, profile, etc. as a shell function which is what I did.
First file is function, second is the script:
After it's installed, you can easily upload & authorize your public key on a new server:
It'll ask for your password for the server, then transfer the key and append it to ~/.ssh/authorized_keys on the server. By default the script uploads your rsa or dsa key but you can specify a specific key:
sshput ~/.ssh/github_key.pub myserver.local
Hope that helps out with making ssh key authentication easier, I definitely like having a 1 step setup for authorizing a key now.05:33 PM | Tags: ssh, sysadmin, servers, shell, scripts
UPDATE: Added basics section to try to give a nicer overview, feel free to email me any feedback on this post
A friend asked about remembering an ssh password in OS X keychain which led me to mentioning ssh keys, I believe OS X only stores those passwords. Decided to try writing a post about them that hopefully is helpful in getting started with using ssh key authentication.
First, a little about key based authentication. SSH has a few ways of handling authentication, a lot of people I think use just the password based authentication, this is what will probably be used when you first setup SSH too. There's a few other options, including ability to tell the server only to accept certain ones. One of the choices is public key authentication which can be more secure and allow for some conveniences on the client side.
With public key authentication, you have both a private and public key on your client machine, and the server has to be told if your public key is authorized. When connecting, your public key will be sent to the server and it will check if it's authorized and if your ssh client can prove it has the private key. (Not sure if it's used in the actual encryption)
Setting public key authentication up takes a bit but can be much nicer than just using password authentication. We have a few steps to follow, you'll have to repeat per client machine you use, at least that'd be more secure than copying a key to each:
- Create a new key pair on your client machine (ssh-keygen command)
- Copy the public key to the server (~/.ssh/id_rsa.pub)
- Add the public key contents to your user's ~/.ssh/authorized_keys file, creating it if it doesn't exist
I'm hoping to write some useful shell scripts to streamline the last 2 steps into a simple command, I'll share that if I finish it or find a similar existing method.
Below I go into more detail about setting it all up.
Creating a key pair
First you need to make a key pair if you haven't already, you can just type the simple keygen command wi th no gas, default will be to do rsa keys, changeable via -t flag. I believe rsa is the better choice anyway.
You'll be asked where to store the files but just hit enter to accept default. You'll then be asked for a passphrase which you can leave blank. You might want to have one, it'll be safer if someone did manage to get your private key. You can always store the passphrase in things like OS X keychain to have passwordless ssh login. OS X 10.6 has support for this and there's probably some similar utilities for other OSes. This involves an ssh-agent which I'll probably go into later.
Now you'll have 2 files:
The .pub file is your public key which you use to identify and allow your machine access to servers or services like github. The other file is your private key which you want to keep safe. When connecting to an ssh server, your private key will be used to encrypt communication if the server has your public key in an authorized keys file.
Making a key authorized
Every server you want to access using this key you have to copy the id_rsa.pub file to and put the contents in a specific file for your user. This is the users authorized keys file: ~/.ssh/authorized_keys
This file can contain one public key per line, typically you might have a key per computer you use.
Easiest way to get this to a server is to scp it, then we have to append it to our authorized keys file:
scp ~/.ssh/id_rsa.pub server:mykey
Then ssh to server and append it to authorized keys, creating ~/.ssh directory of it doesn't exist:
ssh server mkdir -p ~/.ssh cat mykey >> ~/.ssh/authorized_keys
Now if you logout and back in, it should either ask you for your key's password or no password at all if you left it blank. On OS X 10.6 this will be via a GUI panel, or similar on other OSes with a GUI ssh-agent setup.
This isn't necessary to know about but might be helpful for some. An ssh-agent is actually what's running on OS X to allow the password panel that pops up and keychain support. It also doesn't ask you for the key's password repeatedly for a duration if you do multiple connections. It's job is to hold onto private keys for a time period so you don't have to continually enter your password.
There may be cases where you might want to use the ssh-agent command. I use this on a remote server so I only have to enter my key password once. I'll be doing a follow up post more on this I think as I need to review some pieces.03:23 PM | Tags: shell, ssh, sysadmin, servers
So I recently switched to zsh after encouragement from a friend and wanted to share some of the possible benefits. With some help I was able to bring over some history improvements I had in bash to zsh too.
I was pointed to this blog entry that pretty much sums up some of the pros of using zsh over bash. I'm a big fan of the tab completion options available along with the auto-correction. I can do "cd public" in my home folder and it'll fix it to "cd Public".
The tab-completion is able to do a fancy menu selection too which I kind of like:
You can move the selection around the arrows or control-C to cancel out. In this case I didn't type any characters yet, "GarageBand/" is the possible selection. Hitting enter will confirm. It behaves a bit different but I'm liking it.
One thing I did like which I didn't have setup at first was the prefix history search. The idea is you type in something like "ssh" and then can cycle through your history for anything starting with that. This makes it easy to find a previous ssh connection in this example. You can bind this behavior to a key, which I would bind to the typical history cycling of up & down. The bash history blog I linked to above mentioned this in the comments and required putting it in .inputrc. With zshrc it turns out I just needed to use it's format within zshrc itself:
bindkey "\e[B" history-beginning-search-forward
bindkey "\e[A" history-beginning-search-backward
This differed from bash's commands by the -beginning- piece being added here, otherwise it uses the previous word you typed only I believe.
There's a ton of stuff to learn about zsh of course, and I don't understand half of what's in my zshrc either. But I like the benefits and hopefully will slowly learn more. What I did to start is just tweak an existing one so I'll provide mine here:
Things it has: * A list of your servers * shortcuts to push it to the listed servers * some shortcuts to setup git for a project, including the remote copy * shortcut for cloning from my GITSERVER * tons of other useful shell functions * Sets up ls to colorize listings on linux & OS X
The zshrc is based on what Nicholas Penree gave me and thanks to him for helping improve my terminal using experience! Be sure to check the top of the file for the areas to customize.
There's some things I have yet to figure out too. Some things I'd like to figure out:
- Detect OS X GUI access to set $EDITOR properly (mate -w only if we can open a GUI app)
- Track changes to zshrc through git instead of just get/pushing it randomly
- On my MBP control-A and E don't do beginning/end line like they normally do, weird!
- Actually organize things a lot better, bindkeys are everywhere, so are various functions