Setting up an SSH connection to a remote server

Setting up an SSH server with all the trimmings

Setting up an SSH connection to a remote server

Change hostname of server

# edit hostname
vi /etc/hostname
<change name>

# restart
sudo apt install openssh-server

Create the asymetric keys

(this solution assumes using linux based machines)

  1. create an SSH key (public and private) on your machine
ssh-keygen -t rsa -b 4096


ssh-keygen -t mytest -C "email@email.eml"

follow the prompts as appropriate. it will ask if you want to rename the file it saves and whether you want a protecting password.

  1. get the public key (this assumes you didnt rename the file in step 1. the default file name is
cat ~/.ssh/

copy the key to the server:

ssh-copy-id -i ~/.ssh/mykey user@host

this command will print the public key. this is the key you need to upload to your SSH service - GitHub, Azure Devops, etc.

that should be it! this key will be linked to your account and you will be afforded the same access restrictions as your own account. the reason i mention that is normally these providers offer the 'api key' method too, which provides you the facility to determine the access restrictions.

but you can get fancier:

  1. create a config entry
vi ~/.ssh/config

I chose vi to edit the file but you can use nano or whatever you fancy.

add a section for this new server:

# add config sections for each site with location of key
Host mygithub
  User git
  IdentityFile ~/.ssh/_id_rsa
  IdentitiesOnly yes

this is a section for the SSH connection configuration to it has my username, the SSH public key file to use and the IdentitiesOnly option says yes, meaning only attempt to login using the identity specified in this config file or from the command line. do try to be clever`

this set up means I can now do:

ssh mygithub

and it does the rest!

if you are using MacOS, you can add the key passwords to your keychain:

ssh-add -K ~/.ssh/id_rsa

we can clear the keychain of passwords for SSH keys with:

ssh-add -l
ssh-add -D

there are other helpful options for the SSH configuration here

Edit the ssh configuration of access

On the SSH server we can edit the file /etc/ssh/sshd_config where things can make things more secure.

We could change the default SSH port of 22 to anything. We could disable SSH authentication via password to ensure the the caller has the private key and we should prevent root login.

The following flags are available in the /etc/ssh/sshd_config file:

  • change port
  • passwordauthentication
  • permitrootlogin

After making the changes we can restart the service

sudo systemctl restart sshd

Insecure key files

You may be presented with the following message when you attempt to connect to a remote host:

The authenticity of host 'xx.xx.xx.xx (xx.xx.xx.xx)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xx.xx.xx.xx' (ECDSA) to the list of known hosts.
Permissions 0644 for '/Users/user/.ssh/xxx_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/user/.ssh/xxx_key.pem": bad permissions
user@xx.xx.xx.xx: Permission denied (publickey).


This is because you have too many rights afforded to all users meaning it is vulnerable to hijacking/editing. all we need to do is secure the file by editing the permissions.

any one or more of the following command may help:

sudo chmod 600 ~/.ssh/my_key.pem
sudo chmod 644 ~/.ssh/known_hosts
sudo chmod 755 ~/.ssh

In this case it seems that just the .pem file is too open so we can secure it with:

sudo chmod 600 ~/.ssh/my_key.pem

no host keys available - exiting

You may find this error when setting up a new SSH server


You can find this error by running sshd -t. This command can reveal errors in the service.

Assuming you have the correct authority:

ssh-keygen -A

then you can start the service:

/etc/init.d/ssh start

Remote host identification has changed

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /Users/klagan/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/klagan/.ssh/known_hosts:47
ECDSA host key for has changed and you have requested strict checking.
Host key verification failed.


The host key in your known-hosts file on your client machine does not match the host. Assuming neither your client or host not compromised, we need to remove the host key from the client and start again.

ssh-keygen -R <server ip address>

Now you can attempt to connect to the remote server

Download a file over ssh

# to download a file
scp azureuser@azurehost:uploads/file targetfile

# to download folder
scp -r azureuser@azurehost:uploads .

Upload a file over ssh

# to upload a file
scp kam.txt azureuser@azurehost:uploads

# to upload a folder
scp -r kam.txt azureuser@azurehost:uploads

How can i debug an SSH connection

use the vvv switch:

ssh -vvv someone@somewhere

SSH changed server id

This means the key you are using is not associated with the machine you are attempting to connect to.

An example of this is where

  1. I create a VM X and configure it with public key A to private key A.
  2. I connect, SSH will register private key A on my host to public key A on machine X.
  3. I then destroy machine X and create machine Y using the same private key A and public key A.
  4. I attempt to connect to machine Y using private key A on my host and public key A on VM Y I am told my private/public key A pair are associated with a different VM.

We need to remove the key association from our machine so the keys may be registered against the new machine.

ssh-keygen -f "~/.ssh/known_hosts" -R "<my remote address>"