| 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 passwords 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. The ssh keys are the two files as id_<key_type>.pub and id_<key type>. If there are no keys, create them as regular user: ssh-keygen
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 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
The server needs to have the clients public keys listed in the ~/.ssh/authorized_keys file.
One safe way of doing is is using a USB stick.
on the client copy id_ to the USB stick<key_type>.pub
on the server cat id_<key_type>.pub >> ~/.ssh/authorized_keys to append the key.
If a ssh connection using password logging is possible, then the key of the client can be copied and appended to the servers ssh keys over the network:
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_rsa.pub and shown when generating the key with ssh-keygen. It also can be recalculated with ssh-keygen -lf ~/.ssh/id_rsa.pub or ssh-keygen -lf <someones id_rsa.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 is setup is more complicated and appears often during development as obstacle.
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 |
