| SSH | ||
|---|---|---|
 |
Chapter 8. Networking |  |
| SSH | ||
|---|---|---|
| |
Chapter 8. Networking | |
Secure Shell connects a client with a server via Ethernet. A typical application is open a console and log into a remote machine.
The server configuration is in /etc/ssh/sshd_config
Different ways of authentication are supported:
Login via user name and password. It takes place after having a encrypted connection, so password and user name are transmitted encrypted.
Login via ssh keys
sudo systemctl restart ssh restarts the sshd daemon under systemd
Under OpenRC, the server ssh daemon sshd can be started as
/etc/init.d/sshd start
or to bring it each time alive type rc-update add sshd default.
To copy a file from the local machine to a remote machine you can type
scp <path and file on the local machine><user or root>@<ip address or host name of remote machine>:<path on the remote machine>.
There are different authentication possibilities in ssh, that have a different level of security:
/etc/ssh/sshd_conf holds the configuration and defines what authentication method is enabled
Secure password authentication (default)
RSA (Rivest, Samir, Ademan = 3 mathematicians) authentication (ssh version 1)
DSA (Digital Signature Algorithm) (ssh version 2)
RSA and DSA use two keys:
a public key to encrypt the local message before sent
a private key to decrypt the message on the remote machine
The private key has to get stored secretly and might be stored encrypted on the local machines hard disk.
The public key will be copied to the remote machine.
Many of the following including the keys is done by the command /etc/init.d/sshd start
or at boot when rc-update add sshd default got made.
On the remote machine type into console:
ssh 192.168.1.34
or
ssh username@machine opens the console from the remote machine
then the keys are exchanged and you have to login.
To copy a file from a remote machine to the local machine:
scp <user or root>@<ip address or host name of remote machine>:<path on the remote machine><path and file on the local machine>
The command exit quits.
Typing in continuously (the same) password is not the the safest way. More safe and convenient is using private and public keys.
The private key of the client is kept hidden, whereas the clients public key must be given to the server.
There is the client program ssh whereas on the other end the sshd server daemon has to run.
Check if the client has ssh keys: ls -a ~/.ssh. ssh key pairs are two files as id_ and <key_type>.pubid_. If there are no keys, create them as regular user: ssh-keygen <key type>
additionally an optional passphrase can be entered.
The public key is ~/.ssh/id_ and the private key is <key_type>.pub~/.ssh/id_ <key_type>
There are different key types as rsa or ed25519. The rsa keys are longer and therefore more safe.
The public key in ~/.ssh/id_ starts with the key type and ends with username@hostname<key_type>.pub
Since host names can appear in the public key files instead of IP addresses, the server involved needs to know those host names. Usually this works fine otherwise edit /etc/hosts at the server
Consider disabling password login once the key login works
The server needs to have the clients public keys listed in its ~/.ssh/authorized_keys file. So the public key needs to be exchanged. Safe ways doing that are:
One safe way of doing is is using a USB stick. On the client copy id_ to the USB stick.<key_type>.pub
If having a console running as for raspberries with rpi-connect then cat id_ed25519.pub and cut and paste it to an empty id_ file on the server.<key_type>.pub
On the server cat id_<key_type>.pub >> ~/.ssh/authorized_keys to append the key.
If a ssh connection as from a using password logging is possible, then the key of the client can be copied and appended to the servers ssh keys over the network with the following commands that will ask for the password:
ssh-copy-id <ssh server name or IP> or
ssh-copy-id <user name>@<ssh server name or IP>
A more manual way is using sftp the ssh ftp version
scp ~/.ssh/identity.pub username@machine copies over the public key in a safe way
To make it even safer, a passphrase can be entered when generating the keys with ssh-keygen. The private key can then just be used together with the passphrase.
The drawback is that the passphrase must be entered each time the private key is required.
The ssh_agent daemon and the keychain program make handling of the passhrase easier.
The fingerprint is a hash of the id_ and shown when generating the key with ssh-keygen. It also can be recalculated with ssh-keygen -lf ~/.ssh/id_<key_type>.pub<key_type>.pub or ssh-keygen -lf <someones id_<key_type>.pub>
ssh-keyscan -t rsa <host> gives the public key if exists
ssh-keyscan -t rsa oldraspi | ssh-keygen -lf - pipes the public key (if exist) into ssh-keygen and creates therefore a fingerprint that can then be compared with the expected one.
To make it easier to compare it for human beings there is a randomart image showing the fingerprint when doing ssh-keygen or ssh-keygen -lv -f id_rsa.pub
It is used to compare if the public key really belongs to the expected without requiring the private key for it. The private key can stay private the fingerprint can be used instead. It can therefore be used to detect man in the middle attacks.
When using ssh for new connection, the user is asked to accept. ssh can not know it there is a man in the middle and therefore passes the decision to the user, so the user might step into the trap.
Recently ssh login via password is often disabled, since login via public keys is more safe and user friendly. However its setup is more complicated and appears often during development as obstacle. It should be considered to remove this obstacle and install the public keys since this will save time in the long run.
Anyway to enable login via passwords edit /etc/ssh/sshd_config
PasswordAuthentication yes
Once having the ssh connection the public keys for key login can easily be exchanged. So consider doing it and disable password authentication. In a long run this saves a lot of time.
When changing hardware the following can occur:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:xst06A5oYmr2KleaFzpE8rCVQ672301cYJ6blFoYN0E. Please contact your system administrator. Add correct host key in /home/lindegur/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/lindegur/.ssh/known_hosts:6 ECDSA host key for 192.168.1.131 has changed and you have requested strict checking. Host key verification failed.
if sure that nothing is wrong, delete the entry in ~/.ssh/known_hosts
Get putty from https://www.putty.org/ and select SSH using port 22
| |
|
|
| SSL TLS |
|
VPN |
