Editing SshTips - CaffeinatedWiki

When saving, enter the following:

 ######    ####   ##   ##   ######  ######   
 #        ##  ##  ##   ##    ##  ## ##   ##  
 #       ##       ##   ##    ##  ## ##   ##  
 ####    ##       #######    #####  ######   
 #       ##       ##   ##    ## ##  #####    
 #        ##  ##  ##   ##    ##  ## ##  ##   
 ######    ####   ##   ##   #### ## ##   ##

Visit Preferences to set your user name

== X11 forwarding ==
The {{ssh}} tool has a lot of cool stuff that a lot of people don't know about it when they use it for the first time. For example, did you know that it can do ''automatic'' X11 forwarding? What that means is that you can log into another computer, and run an X11 program on that other computer, and have it appear locally. This is in part due to X11's network transparency, and in part due to 'ssh' doing some magic.

This might already be enabled for you; try it. If it isn't working, then you need to edit {{/etc/ssh/ssh_config}} and change the line
<code>
#  !ForwardX11 no
</code>
to 
<code>
   !ForwardX11 yes
</code>
on your machine. And on the remote machine, you need to edit {{/etc/sshd/sshd_config}} and change the line
<code>
#X11Forwarding no
</code>
to
<code>
X11Forwarding yes
</code>

Then restart the {{ssh}} daemon on the remote machine. On most distributions, you can do this by running
<code>
/etc/init.d/ssh restart
</code>
or maybe
<code>
/etc/init.d/sshd restart
</code>
Then you should be good to go. This is really nice if you have a couple computers around your house; you can just log in and run programs from one computer as if you were actually sitting at the other.

== Authentication ==
Another really useful feature that {{ssh}} has is the ability to password-less authentication. This may sound insecure, and of course it is less secure than requiring a password every time, but the way it's done with {{ssh}} doesn't make it ''too'' bad, and it is very convenient.

Setting up password-less logins with {{ssh}} is explained in many places on the 'net. However, the first time I did it, I found that many of these explanations were lacking, so I'll try to do better. To set up a password-less login with {{ssh}} you're going to need to do the following:

# Generate a private/public key pair.
# Copy the public key to the remote machine.
# Add the public key to a list of "authorised" keys.

So, 3 simple steps. Shouldn't be too bad.
=== 1. Generate the keys ===
To generate the keys, run
<code>
ssh-keygen -t rsa
</code>
as your normal user. This should ask for a passphrase. You don't need to enter one, but it's a good idea. If you set things up properly, you will have to type your passphrase very rarely, so it's a good idea to make it quite long.
=== 2. Copy the public key ===
The previous step should have generated a file called {{id_rsa.pub}} in your {{~/.ssh}} directory (assuming you accepted the default choice). We now copy this file (and ''not'' id_rsa -- that one's private) to the remote host:
<code>
scp ~/.ssh/id_rsa.pub user@remote.machine.com:~/
</code>
=== 3. Add key to authorised list ===
Now, you need to login to the remote host, and add that public key to a list of authorised keys:
<code>
ssh user@remote.machine.com
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
rm ~/id_rsa.pub
</code>
This is the crucial step, so make sure to get it right. In particular, I know I've screwed up by trying to use {{authorized_hosts}} instead of {{authorized_keys}} at least once :)
=== Hopefully finished ===
Now, log out of your remote connection, and try it again:
<code>
ssh user@remote.machine.com
</code>
You should a message like:
<code>
Enter passphrase for key '/home/username/.ssh/id_rsa':
</code>
Or maybe it just logged in without asking you anything, if you didn't enter a passphrase. If you did enter a passphrase, however, enter it now, and you should be logged in.
=== Using the agent ===
But wait, you say! What good is this? I had to enter a password before, and now I have enter a different one, and you even told me to make it longer! This is stupid!

And you're right, it ''would'' be stupid, if it weren't for {{ssh-agent}}. Using {{ssh-agent}} properly used to be kind of complicated, and involved hacking around with {{xinitrc}} files and so on. Now, however, most distributions have {{ssh-agent}} set up out of the box, so that it's automatically used when running X11. So, on your local machine, try this (from a terminal within your X11 session):
<code>
ssh-add
</code>
It should ask for your passphrase. Enter it. Now try to {{ssh}} to your remote host again. You should be logged straight in. What this means is that you only have to enter your passphrase ''once'', when you first log in to your local machine. Then you can {{ssh}} to the remote host all you want and never enter a password.

Side note: if you use Mac OS X, everything I've talked about applies up until now. The ssh-agent stuff is somewhat different, however: by default there is no agent in OS X. However, you should really check out http://www.phil.uu.nl/~xges/ssh -- it's a graphical ssh-agent front-end and is dead easy to use. If you've done as I said above, then all you need to do is run it when you log in, enter your passphrase, and close the window (but don't "Quit" the application).
=== If it goes wrong... ===
Now, if you're like me, you get to this point in the procedure, and you've done everything precisely as I've said above, and it still doesn't work. This happens to me almost every time I setup ssh keys, and it's almost always due to permissions of the public/private keys or perhaps the {{authorized_keys}} file. So check these permissions (with {{ls -l}}):

On the local machine:
* {{~/.ssh/id_rsa}} should be {{```-rw-------```}}
* {{~/.ssh/id_rsa.pub}} should be {{-rw-r--r--}}

On the remote machiine:
* {{~/.ssh/authorized_keys}} should be {{-rw-r--r--}}

Unfortunately, if you've checked all that, and done everything precisely as I said above, and it ''still'' doesn't work, I don't have too many suggestions, other than to check the {{/etc/ssh/ssh_config}} file locally and {{/etc/ssh/sshd_config}} file on the remote host and look for anything disabling key-based authentication.

== Fun with authentication ==
Having password-less logins lets you do some fun things. For example, if you want to run a command on the remote machine, you can just type
<code>
ssh remote.host.com command
</code>
and it'll just run right away.

Another neat trick is to set up shortcuts that open terminal windows already logged in on another machine. To do this in GNOME, right-click on your desktop (or panel, if that's where you want it) and choose "Create Launcher". Type in a name like "Terminal on hostname" and for the command, type {{ssh remote.host.com}}. Then check the box that says "Run in terminal." You should be good to go; click on the link and see if it works.

== Stored hostnames/usernames ==
One thing that can be a pain is if you use a different username on your home box than your username on the remote box. For example, let's say you're the ever-popular Jane Doe, so your username at work is {{jdoe}}, but (despite your name) you've got quite a stinging personality, so your username at home is {{medusa}}. This means that every time you ssh to work, you have either type {{ssh -l jdoe work.com}} or {{ssh jdoe@work.com}}. Wouldn't it be nice to have ssh remember the username associated with work.com? Or what if your company lost out on the whole cybersquatting thing, so your work has a really annoying domain, like {{thisistheincrediblylongannoyingdomainfromhell.com}}? Wouldn't it be nice to alias that to something nice, without resorting to annoying {{/etc/hosts}} hacks?
=== Well don't fear, you can! ===
This can be done using either {{/etc/ssh/ssh_config}} or {{~/.ssh/config}}. It's better to use {{~/.ssh/config}} for this kind of thing (the kinds of situations I described above) because they are likely to be highly user-specific.

If you don't have a {{~/.ssh/config}}, never fear. Just create one. The syntax for doing host aliasing is like this:
<code>
Host work
HostName thisistheincrediblylongannoyingdomainfromhell.com
User jdoe
</code>
Now Jane can just do {{ssh work}} and have all the right information automagically filled in by {{ssh}}. And of course this also works with {{scp}}, so Jane could also do {{scp work:~/boring_file .}} and get the same automagic goodness. Now if ''that'' doesn't give you a warm fuzzy feeling inside I don't know what will!

Happy ssh-ing!

Summary of change:
Add document to category: