SSH
From Liki
Secure SHell (SSH) is a program/protocol that lets you securely log into other machines. For example, SSH allows you to manipulate your account on the department file server (Newton) or run code on one of the department clusters. Of course, you'll need a shell account on the target machine in order to log in.
Basic usage:
$ ssh user@hostname
See "man ssh" for more details.
Contents |
Quicker copying
For copying multiple files and/or whole directories, while preserving timestamps, permissions and other file system information, SCP is the preferred tool. It allows recursive copying (-r), preservation of timestamps and permissions (-p) and it provides a hand progress meter to show how far along the process is.
On the (very rare) occasion that this doesn't work, piping tar through ssh and back will work, although you have to be careful to use the absolute paths to the files. This second method is really only necessary if you are going from a machine with OpenSSH to one with an older version of the commercial SSH (as found on Solaris 8) that doesn't support all the scp encryption methods. The old example follows:
tar zcvf - /home/newton6/dubya | ssh dubya@federal.prison.gov "cat > dubya.tar"
Or perhaps even directly:
tar zcvf - /home/newton6/dubya | ssh dubya@federal.prison.gov "tar zpxvf -"
This is especially useful if you want to copy over entire directory structures, which would be painful otherwise. But, be careful! You could mess up with this if you ain't careful.
Embedding in terminal
You might find it easy to put something in your bash source file to make ssh easier if you need to ssh often. For example, one user who ssh's into newton often can modify his ~/.bashrc file as
[sysadmin@bach ~user]$ more .bashrc PS1="\[\033[1;31m\]\u:\w>>\[\033[0m\]" alias rm='rm -i' alias ls='ls --color' PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/home/user/bin:. export PATH export CVS_RSH=ssh PGPLOT_DIR="/usr/local/pgplot/" export PGPLOT_DIR PGPLOT_DEV=/XWIN export PGPLOT_DEV alias n='ssh newton'
That last line makes it so that now all he need do is type n at a command prompt. Of course, first you must type reset to refresh the terminal, and of course this works for bash. For tcsh shells, you would have FINISH HERE
Even easier is the use of keys, as follows.
Keys
If you ssh to another machine quite often, you can make things easier by using keys so that you don't need to keep entering your password. To generate a key you would type at a command line,
ssh-keygen -t rsa
You'll get:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa):
Typically this is the perfect place to put it, so accept it (hit enter). Next you'll be asked for your passphrase. Hit enter twice, as a passphrase would defeat the purpose of making things simpler. We do ask that you only do this for department machines or with a machine you can trust. After taking a pass on the passphrase you will get a key:
Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 13:65:77:3a:3a:58:11:f9:19:f5:bb:12:0e:a5:96:7c user@newton.physics.drexel.edu
Now scp this key to a machine you want to get access to without typing your password many times, e.g.,
scp .ssh/id_rsa.pub einstein:.ssh/authorized_keys
Now ssh into that server, and bada-bing. If it doesn't work you did something wrong.
For multiple machines, perhaps try, e.g.:
for i in `seq 1 8`;do scp .ssh/id_rsa.pub 192.168.2.10$i:.ssh/authorized_keys; done
IMPORTANT This key should be given permissions 0600, so do this on the side you created the key on:
chmod 0600 ~/.ssh/id_rsa*
Now ssh into the other side and do this:
chmod 0600 ~/.ssh/authorized_keys
Safer Keys (with passphrases)
The following steps are a combination of the procedures detailed here and here, where for this particular example we take advantage of the fact that users on newton and the xphy* computers share a common home directory. The setup will let you ssh from newton onto any of the xphy* computers (or newton itself) without a password/passphrase, although you will need a passphrase to ssh back into newton from an xphy*.
x@newton$ cd ~/.ssh x@newton$ ssh-keygen -t dsa -f ~/.ssh/id_dsa Enter passphrase (empty for no passphrase): <Some kind of passphrase> Enter same passphrase again: <Some kind of passphrase> x@newton$ cat id_dsa.pub >> authorized_keys x@newton$ chmod 600 authorized_keys
This creates a private/public key pair for authentication, as in the previous section. The public key gets sent to the server (here xphy*) which compares it against the authorized key list. To tell ssh where to look to find the private half create a config file
x@newton$ cat > ~/.ssh/config
Host newton.physics.drexel.edu
IdentityFile ~/.ssh/id_dsa
Now you can ssh into xphy* without a password, but you'd need to enter your passphrase each time! The solution is to start up an agent to keep track of the passphrase and enter it for you. Make a script for setting up (priming) the agent.
x@newton$ cat > ~/ssh_prime #!/bin/bash # Creates an ssh-agent, writes ssh agent info # to the file '~/.ssh-agent-info-`hostname`' and then prompts # user for keys. Then any shell can use the agent # by sourcing the contents of ~/.ssh-agent-info-`hostname`: # . ~/ssh-agent-info-`hostname` # by Ted Dustman, http://www.cvrti.utah.edu/~dustman/no-more-pw-ssh/ ssh_info_file=~/.ssh/.ssh-agent-info-`hostname` ssh-agent >$ssh_info_file chmod 600 $ssh_info_file . $ssh_info_file ssh-add ~/.ssh/id_dsa
Then you can prime the agent (once per per boot) by running
source ~/ssh_prime
Now you have a passphrase-protected key, but password/phrase-less login :).
Safer keys as a set of scripts
I'd been setting up a number of these passphrased key systems, so I put the above commands (with a few tweaks) into a set of three scripts. See here.
Tricks
It is often desirable to have a quicker way to ssh into machines, especially if you do it frequently or have many computers that require maintenance - like on a cluster. One way to do this is to make aliases as above as shortcuts to shh. Another, system accessible way to do this is to make the following script and put it in an accessible path, like /usr/local/bin:
#!/bin/sh SSH="ssh -x" $SSH `basename $0` $*
and then make symlinks to this script with the names of the computer(s) you want to ssh into, ex:
ln -s /usr/local/bin/ssh-to /usr/local/bin/node1
and then running "node1" will ssh you into that computer.
Note that those are tick marks (on the key with ~ next to 1) and not apostrophes. The script as written disables X forwarding since in typical applications I don't need X, but this is not necessary. The script works because of the basename command, which returns the command you typed into the console. $0 is a variable which returns the first part of that command (the actual command name) and then $* returns all the options passed to that command. So if you type
node1 echo hi
then basename $0 is node1 and $* is 'echo hi' and the actual command that will be executed is 'ssh node1 echo hi'.
Broken X window
If you try to open an X Windows app on a remote machine that you've SSHed into, you might get this error (or "Error: Can't open display"). To provide the remote app with an X server, you'll either have to run one on your local machine, and forward that connection to the remote machine with
ssh -X machine
or
ssh -Y machine
See "man ssh" for details.
If the application thinks it needs an X serve, but really doesn't, you can fake it with Xvfb.
SSH Fedora issues
For Fedora machines, use,
ssh -Y machine
Web browsing by proxy
Many journal articles are not freely available, but require some kind of Drexel subscription. Usually, they will seem free when you connect from a Drexel IP address, but when you connect from home you have to go through the whole rigmarole with Drexel Library's SFX doodad to get your article. What a pain. I had previously SSH tunneled my X server out to Newton, and fired up Firefox on Newton. Not much better, since tunneling Firefox is *slow*. w3m is faster, but without good JavaScript support a lot of “modern” sites leave you without much functionality. I recently discovered a neat solution courtesy of [1], [2], and [3].
You can get around the drag of forwarding X from Newton, and just forward the webpages directly by setting up a SOCKS proxy with SSH. This is done in a number of possible ways through SSH, but the following two lines are the most common. If you want to simply carry the connection through without a shell opening:
ssh -fND localhost:9999 you@newton.physics.drexel.edu
if you want to open a tunnel and a shell at the same time, you could run:
ssh -D localhost:9999 you@newton.physics.drexel.edu
Now port 9999 on your computer takes you to a SOCKS proxy on Newton. Open Firefox on your home computer and set it up to use the proxy with
Edit -> Preferences -> Advanced -> Network -> Settings -> Manual Proxy Configuration
And enter “localhost” and “9999” in the “SOCKS Host” fields. Click OK and you're done.
For bonus points, you can also make your DNS queries from Newton by entering
about:config
in Firefox's URL field, and setting
network.proxy.socks_remote_dns
to “true”.
If you're tunneling your DNS queries, you can also use this method to access services otherwise screened by intervening firewalls. For example, I can log in from home to check the status of our lab's chemical inventory, but the only port our router needs to expose to incoming connections is for SSH.
This method will work for most computers running ssh (unless something is unusual with the configuration).
Further, this can be used on Windows as well using a shell such as Secure Shell or Putty.
Remote desktops
Want to ssh in and then open your desktop (Gnome, KDE, ...). See remote desktop.
