SSH authenticatie met een publieke sleutel ipv password

SSH

Hoe werkt SSH
maak met putty/ssh een connectie met remote server
bijv ssh myserver1

HOST Validation

The first time around it will ask you if you wish to add the remote host to a list of known_hosts, go ahead and say yes. 

The authenticity of host 'arvo.suso.org (216.9.132.134)' can't be established. RSA key fingerprint is 53:b4:ad:c8:51:17:99:4b:c9:08:ac:c1:b6:05:71:9b. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'arvo.suso.org' (RSA) to the list of known hosts.

It is important to pay attention to this question however because this is one of SSH's major features. Host validation. To put it simply, ssh will check to make sure that you are connecting to the host that you think you are connecting to. That way if someone tries to trick you into logging into their machine instead so that they can sniff your SSH session, you will have some warning, like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for arvo.suso.org has changed, and the key for the according IP address 216.9.137.111 is unchanged. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. Offending key for IP in /home/oracle/.ssh/known_hosts:10 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 99:92:62:15:90:ec:40:12:47:08:00:b8:f8:4c:df:5b. Please contact your system administrator. Add correct host key in /home/suso/.ssh/known_hosts to get rid of this message. Offending key in /home/oracle/.ssh/known_hosts:53 RSA host key for oracle..org has changed and you have requested strict checking. Host key verification failed.

Once you've read the alert, then if this is the first time you are connecting to this machine from this computer, go ahead and click 'Yes' to accept the key and cache it for the future. From then on, when you try to connect to that server, it should present the same host key and your ssh client will check if the key you receive is the same as the one in the .ssh/known_hosts

Optioneel: Stappen om in te loggen met ssh via een sleutel ipv een password.

Als je kan inloggen via SSH met een server side password is dat in principe voldoende. Het is echter veiliger en handiger om private/public key pairs with passphrase te gebruiken.

Stap 1: 

Genereer op de client een key-pair via ssh-keygen. Deze genereert in homedirectory een .ssh directory met daarin een publieke en private key (id_rsa, id_rsa.pub). In windows kan dit met Putty Key generator

bash :
>ssh-keygen (-t dsa)

it will ask for a passphrase.
- kies een een lange zin, geen bekende zin.

Stap 2: 

Na cre-eren keypair moet public key op account op de remote host geinstalleerd worden. De private key blijft altijd op de locale computer, de public key moet op de machines waar je naartoe wil connecten geplaatsen worden in de .ssh/authorized_keys file

create or edit de file : ~/.ssh/authorized_keys

Kopieer de id_rsa.pub naar de remote machine waarop je wil inloggen en geef de volgende commando's

bash
> cd ~
> mkdir .ssh
> chmod 700 .ssh
> cd .ssh
> touch authorized_keys
> chmod 600 authorized_keys
> cat ~/id_rsa.pub >> authorized_keys
> rm ~/id_rsa.pub


ssh -i /home/oracle/.ssh/id_rsa -l oracle server2

zet bijvoorbeeld in .bashrc
alias lga='ssh -i $HOME/.ssh/beasvba.id_rsa -l beasvba'

Waarom keyfile veiliger?

The reason why you would generate a keyfile is so that you can increase the security of your SSH session by not using your system password. When you generate a key, you are actually generating two key files. One private key and one public key, which is different from the private key. The private key should always stay on your local computer and you should take care not to lose it or let it fall into the wrong hands. Your public key can be put on the machines you want to connect to in a file called .ssh/authorized_keys. The public key is safe to be viewed by anybody and mathematically cannot be used to derive the private key. Its just like if I gave you a number 38,147,918,357 and asked you to find the numbers and operations I used to generate that number. There are nearly infinite possibilities.

Whenever you connect via ssh to a host that has your public key loaded in the authorized_keys file, it will use a challenge response type of authentication which uses your private key and public key to determine if you should be granted access to that computer It will ask you for your key passphrase though. But this is your local ssh process that is asking for your passphrase, not the ssh server on the remote side. It is asking to authenticate you according to data in your private key. So your password is never sent over the network to the remote computer and nobody can sniff it.
Using key based authentication instead of system password authentication may not seem like much of a gain at first, but there are other benefits that will be explained later, such as logging in automatically from X windows.

 SSH-agent

The true usefulness of using key based authentication comes in the use of the ssh-agent program. Usually, the ssh-agent program is a program that starts up before starting X windows and in turn starts X windows for you. All X windows programs inherit a connection back to the ssh-agent, including your terminal windows like Gnome Terminal, Konsole, xfce4-terminal, aterm, xterm and so on. What this means is that after you've started up X windows through ssh-agent, you can use the ssh-add program to add your passphrase one time to the agent and the agent will in turn pass this authentication information automatically every time you need to use your passphrase. So the next time you run:

ssh username@arvo.suso.org

you will be logged in automatically without having to enter a passphrase or password. Most recent distributions will automatically start ssh-agent when you login to X windows through a session manager like gdm (graphical login).