You will want to:
There are a few practical details, but it is that simple.
In what follows there are two machines talked about:
You will make your life easier if you have the same username on both machines.
It is worth working hard today to learn the above and so be lazy tomorrow.
Generate the public/private keys, do this on your Workstation:
W$ ssh-keygen -t dsa
This will ask you for a passphrase that you later given to
It will create in your
id_dsa- this contains your private key, to be kept secret
id_dsa.pub- this contains your public key that you give to remote machines
You should only do the above step once, i.e. you use the same public key for all remote machines.
You need to arrange that a ssh-agent program is started when you login and that it is known to the commands that you type.
Since you may login on a plain console or via X (a GUI) you need to configure this twice in files in
HOME directory on your workstation.
Add to your
.bash_profile on your workstation:
# So that ssh will work, take care with X logins - see .xsession [[ -z $SSH_AGENT_PID && -z $DISPLAY ]] && exec -l ssh-agent $SHELL -c "bash --login"
Add to your
.xsession on your workstation:
#!/bin/sh # This is called from /etc/X11/xdm # Run ssh-agent (so that all children have $SSH_??? set) and then run the clients or xsession manager. # -l is a bashism, so this assumes that /bin/sh is really bash, if not just remove -l. xsm=xsm [ -x /etc/X11/xinit/Xclients ] && xsm=/etc/X11/xinit/Xclients [ -x $HOME/.Xclients ] && xsm=$HOME/.Xclients exec -l ssh-agent $SHELL -c "$xsm" # should never get here; failsafe fallback echo "Whoops! exec of '$xsm' failed from '$0'" >> .xsession-errors exec -l $SHELL -c "xterm -geometry 80x24-0-0" echo "Arrrgh! exec of 'xterm' failed from '$0'" >> .xsession-errors exit 2
The easy way is to run the command:
W$ ssh-copy-id S
W$ ssh-copy-id server.example.com W$ ssh-copy-id firstname.lastname@example.org
You will need to use the second form if your username is different on the two machines.
ssh-copy-id is not available on your machine (it is newish), you will need to do this by hand:
Copy your public key from your workstation into your
HOME directory on the remote machine:
W$ scp ~/.ssh/id_dsa.pub S:.ssh/id_dsa.pub.W
Login to the server S, you need to append your public key to your
S$ cat ~/.ssh/id_dsa.pub.W >> ~/.ssh/authorized_keys S$ rm ~/.ssh/id_dsa.pub.W S$ chmod 600 ~/.ssh/authorized_keys S$ chmod 700 ~/.ssh
Note the 'z' in
You may need to edit
.ssh/id_dsa.pub.W so that the name
YourLogin@workstation.example.com at the end of
the line matches the name that is seen when you connect to the server.
If you have not got
ssh-agent running (via
.xsession as above) you start it:
Every time after you login to your workstation you must prove who you are to your
program will talk to your
When it prompts you, you type the passphrase that you typed to
You do not need to do this again unless you logout of your workstation.
To login, using the same username, to another machine from your workstation:
W$ ssh -X server.example.com
-X option will allow you to run X (GUI) applications on the server and have them display on your workstation,
the X traffic will be encrypted by
To copy a file to another machine:
W$ scp SomeFile.txt server.example.com: W$ scp SomeFile.txt server.example.com:/tmp W$ scp SomeFile.txt server.example.com:/tmp/FileFromWorkstation.txt
The first copies to your home directory on the remove machine.
Note that the trailing colon (':') is very much needed.
It helps if you have the same usernames on all machines, but if you can't manage this you put
before the other machine name, eg:
W$ ssh -X email@example.com W$ scp SomeFile.txt firstname.lastname@example.org:
A few things to check:
ssh, although you may need to use a password. If you cannot do this — you have bigger problems.
getfacl $HOME $HOME/.ssh HOME/.ssh/authorized_keys
/var/log/audit/audit.log). Read a description of such a problem. You may be able to fix SELinux labels thus:
restorecon -R -v /home
You can, but don't have to, put individual machine options into your own configuration file.
Most of the time you do this to save yourself typing, not infrequently remove servers need special options.
Create a plain text file called
.ssh/config, it should not be writable by anyone
W$ touch ~/.ssh/config W$ chmod 600 ~/.ssh/config
Entries in there begin with
Host nick-name, this allows you to use
for the remote server instead of its probably longer name.
You can also have generic options, but I am not talking about that.
HostName: the complete DNS name of the machine. You can also put IP addresses (but try to avoid this since it breaks when the networking guys change things)
Port: sometimes the server admins will have the ssh server listening on a different TCP port. This can increase security in a small way
User: useful if the username on the server is different from what you use on the workstation
ForwardX11: has the same effect as the
-Xoption, ie allows GUI applications on the server to display on to your workstation
Example showing all of the above (but you only use the ones that you need):
Host web-server HostName hosting_cloud.example.com Port 2020 User alainw ForwardX11 yes
To connect using the nick-name:
W$ ssh web-server
Want to have different options for different servers, just add a new set with the
All description & sample files copyright (c) 2008, 2013 Parliament Hill Computers. Author: Alain D D Williams.
You may used these files as the basis your own (or organisation's/company's) project(s) (under whatever licence that you see fit). You may not claim ownership or copyright of any substantially unmodified files. Acknowledgement would be appreciated, but is not necessary.
These demonstrations are made available in the hope that they are useful. There may be errors: there is no warranty at all, use at your own risk.