The good method for remote access is to use SSH protocol. The OpenSSH server has been installed during the setup process, but if you do not install this package, you can do this by this command:
|
|
After this command the SSH server is running and fully configured then you can start to use it immediately.
To improve security, I can recommend to you to provide some small changes in your ssh daemon config file /etc/ssh/sshd_config
|
|
Check if the file contains those lines with specified values:
|
|
If you find different values, or missing lines, change it or add missing item to the file, then save file and restart ssh daemon:
|
|
To connect to your server from Linux, you can use native Open SSH client. You can check if the client is installed by typing ssh in your console. If the client is not available, you can install it by this command:
|
|
now you can connect to your server by this command:
|
|
where server_user_name is the login name of the user created during install and server_ip_address_or_host_name is IP address of your server assigned during setup. Then final command can looks like this:
|
|
At first connection, you are asked to verify and confirm a SSH key fingerprint. This is for security purposes, because in “wild” internet network someone can spoof your connection between you and server and can redirect you to “own fake server” where you write real credentials which can be stolen by this way.
Second well known attack is “Man In The Midle” when attacker redirects you to own server, and you establish connection with attacker server instead. Then attacker connects with credentials which you provided to him to your server from his fake server.
Now he will forward all your communication from his fake server to original destination and back. But he can capture in unencrypted form all content of communication between you and your server and you do not detect this attack, because all looks that you are connected directly with your server, attacker in the middle is stealth to you.
In both attacks, attacker server offers to you own SSH key, and this key have different fingerprint then your original key. Due this, on first connection from client to new server the client display fingerprint of remote server key. It offers to you possibility to verify this fingerprint with known value obtained directly from server or from server admin. When fingerprint not match, you can detect that something is wrong and connection is probably compromised.
When you confirmed fingerprint as correct, client stores this value to his own database, and verify it during any new connection which you establish with the same server. If this fingerprint doesn’t match in the future, you get new notification. If you do not provide SSH server reinstallation which provide old key replacement or client reinstallation which destroy old client database then it is info that an attacker is trying a kind of attack against you.
At the end of this theory part I have to noticed that client stores confirmed fingerprints in own file _~./.ssh/known_hosts _ on Linux or in registry when you are using PuTTy on Windows and then creates new record for any new “connection string”. Connection string is value specified in our ssh line example as server_ip_address_or_host_name.
So if you use one time IP address and second time DNS name for connection to the same server, you will be prompted again, but the key fingerprint will be always same. If your server will change the IP address and you will use DNS name, you can be prompted again too, because ssh client store for DNS names the name and the resolved IP in one record. Additionally, if you are changed listening port for the SSH server, the result will be same, because port is stored in the DB too.
When you confirm displayed fingerprint, then client doesn’t ask you again until the fingerprint of the server will change or DNS name or IP address as I mentioned before.
Then, how you can get the key fingerprint by safe way? You can do this from the server console by this command:
|
|
To be sure that the fingerprint is real fingerprint of your server key, you have to do this on your server terminal, not by an established ssh connection, because this connection can be crippled by attacker from first try.
To be more complicated, depends on client implementation you can get fingerprint of RSA or DSA key. These fingerprints are different, because server has two different keys, one for RSA and second for DSA encryption. SSH client notifies you about the key type; you can find info if the fingerprint is from RSA or DSA key here.
To list DSA key fingerprint, use this command:
|
|
DSA keys are supported by SSH for backward compatibility only. At present is strongly recommended to use RSA keys.
After this theory, I can say that if you connect to your server inside your local network with NAT, you do not need to take care about key fingerprints so much. But when you connect remotely from internet, then it makes sense.
When you establish connection through the SSH to the server, you will get the same console with all capabilities as you are sitting against the monitor and typing commands by keyboard to the server.
If you can connect to the server from Windows Os, then you can use famous application PuTTy available for download here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
It is implementation of the SSH client for windows with easy GUI control. You will only type host name or IP address to the edit box “Host Name (or IP address) on default putty config dialogue then press Open button on the bottom edge of the dialogue.
The functionality is same as for native OpenSSH client on Linux. To get better PuTTy functionality, some special settings are necessary, but this I’ll provide in a next part of this HowTo later.
Now you are able to connect to your own server remotely and provide any necessary maintenance steps from everywhere.