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.
These are the different ways that the client authenticates itself to the server. What is recommended has changed over time; but older servers might not support newer algorithms. With some you can change the key length (-b option) ‐ bigger is better but slower.
For more comments
Generate the public/private keys, do this on your Workstation:
W$ ssh-keygen -t rsa -b 3072 W$ ssh-keygen -t ed25519
This will ask you for a passphrase that you later given to
It will create in your
id_ed25519 - these contains your private keys, to be kept secret
id_ed25519.pub - these contains your public keys that you give to remote machines
(The file names reflect the key type)
Above is shown for two key types, do for all types that you need ‐ use the same passphrase for all of them.
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 [[ -n $SHELL && -z $SSH_AGENT_PID && -z $DISPLAY ]] && exec -l ssh-agent $SHELL -c "bash --login"
You might need to modify your workstation's
.xsession ‐ on older systems
where you are running
Try this without modifying
.xsession, add it later if it does not work.
#!/usr/bin/bash # 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 you are running 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_rsa.pub ~/.ssh/id_ed25519.pub S:~
Login to the server S, you need to append your public key to your
S$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys S$ cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys S$ rm ~/id_rsa.pub ~/id_ed25519.pub S$ chmod 600 ~/.ssh/authorized_keys S$ chmod 700 ~/.ssh
Note the 'z' in
You may need to edit
.ssh/id_rsa.pub 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:
W$ ssh-agent bash
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
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
-X option, 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, 2020, 2023 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.