Difference between revisions of "Access server"

From Anarchaserver
 
(54 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<div style="font-family:monospace; font-size:14px; background-color:#E9F8A8;">


====== SSH ======


===›››››››››››››› SSH===


SSH keys provide **a more secure way** of logging into a virtual private server with SSH than using a password alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on the server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.
:: '''SSH keys''' provide '''a more secure way''' of logging into a virtual private server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.  
<br>
<br>
===›››››››››››››› Making changes in ssh===


===== Debug =====
:: Remember to:
with -v flag. max 3 "v"s
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> sudo service ssh restart</pre>
ssh [[user@server]]  -vvv


::'''Tip''': I can check all available services in /etc/init.d
::'''Attention''': if there are problems, grep to see if it actually stops the service Like this:
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> sudo service ssh stop</pre>
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> ps aux | grep ssh</pre>
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> sudo service ssh start</pre>
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> ps aux | grep ssh</pre>
<br>
<br>


===== Create RSA Key Pair =====
===›››››››››››››› Debug===
You create your rsa key pair in the computer you want to log to the server. I can use this key pair for several servers, but if I want to enter a same server from different computers, I create different rsa key pairs.
Lo voy a crear a nivel local (en mi compu) y esa va a ser la llave rsa ssh que voy a usar para entrar en mis vps. NO genero una para cada vps sino que esa misma me sirve para todas. Si voy a usar varios ordenadores para entrar en un vps, sí necesitaré crear una llave ssh por máquina desde la cual estoy accediendo.


So each admin in a server is going to have at least one rsa key pair.
::Debug with a <code style="border-color:#DDE3DB; color:red;">-v</code> flag. max 3 "v"s


Be careful to pay attention from which user you create this in your local machine (computer). Since the rsa key pairs are saved in a hidden directory in my user home directory (~/.ssh), if Im trying to login from a different user, it will confuse home directories since each user has a different home directory.
:: <pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> ssh <user>@<server> -vvv </pre>
<br>
<br>
===›››››››››››››› Create RSA Key Pair===


So, from the user in my localmachine that I wish to use to access the server, I will create my rsa key pair:
::You create your '''RSA key pair''' in the computer from which you want to log to the server.


$ **ssh-keygen**
::I can use this key pair for several servers, but if I want to enter a same server from different computers, I create different rsa key pairs.


By default it will generate two keys in [[~/.ssh,]] a public key and a private key. We are going to copy our private key to the server. If we dont have access to this server, we will send it to the admin so that she can do it.
::Lo voy a crear a nivel local [en mi compu] y esa va a ser la llave rsa ssh que voy a usar para entrar en mis vps. NO genero una para cada vps sino que esa misma me sirve para todas. Si voy a usar varios ordenadores para entrar en un vps, sí necesitaré crear una llave ssh por máquina desde la cual estoy accediendo.  


When generating the key, you will need to introduce a **"passphrase".**
::So each admin in a server is going to have at least one rsa key pair.  


===== Copy public key to the server =====
::Be careful to pay attention from which user you create this in your local machine [computer]. Since the rsa key pairs are saved in a hidden directory in my user home directory [<code style="border-color:#DDE3DB; color:red;">~/.ssh</code>], if Im trying to login from a different user, it will confuse home directories since each user has a different home directory.


After generating an SSH key pair, you will want to copy your public key to your new server.
::So, from the user in my localmachine that I wish to use to access the server, I will create my rsa key pair:


Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ssh-keygen -t rsa -b 4096</pre>


**cat ~/.ssh/id_rsa.pub**
::By default it will generate two keys in <code style="border-color:#DDE3DB; color:red;">~/.ssh</code>, a public key and a private key. We are going to copy our public key to the server. If we don't have access to this server, we will send it to an admin of Anarcha server so that she can do it.  


This should print your public SSH key, which should look something like the following:
::When generating the key, you will need to introduce a '''passphrase'''.
<br>
<br>
===›››››››››››››› Copy public key to the server===


ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local
::After generating an SSH key pair, you will want to copy your public key to your new server.  


Select the public key, and copy it to your clipboard.
::To securely copy the public key, we shall enable password authentication on the remote server, by editing the <code style="border-color:#DDE3DB; color:red;">/etc/ssh/sshd_config</code> file, and disable it after having copied the public key
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo nano /etc/ssh/sshd_config</pre>


To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user's home directory of the directory. Assuming that we are going to create superuser accounts for each new admin we will do the following:
::uncomment and set <code style="border-color:#DDE3DB; color:red;">PasswordAuthentication</code> to <code style="border-color:#DDE3DB; color:red;">yes</code> and then to <code style="border-color:#DDE3DB; color:red;">no</code> after copying is done.


=== creating super user accounts ===
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">PasswordAuthentication yes</pre>
Changing to root user
su root


we create superuser (note: it will ask me to introduce a passwd)
::To copy your public key, run the following command
adduser superusername
then we will add the superuser to sudoers:
gpasswd -a superusername sudo


we now change to superuser:
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ssh-copy-id <user>@<server></pre>
su superuser
::To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the <code style="border-color:#DDE3DB; color:red;">.ssh</code> directory in the user's home directory. Assuming that we are going to create superuser accounts for each new admin we will do the following:  
<br>
<br>


===›››››››››››››› Creating new sysadmin accounts===
   
::Changing to root user       
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo su</pre>
::Check the sudo users
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%"> grep '^sudo:.*$' /etc/group | cut -d: -f4</pre>


When we change user, we will be by default in the user's home directory (~). You can do "cd ~" just in case.
::If you are not yet, we create a ''superuser'' ['''note''': it will ask me to introduce a passwd]     
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">adduser <superusername></pre>
::Then we will add the ''superuser'' to sudoers:       
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">usermod -aG sudo <superuser></pre>
   
::We now change to ''superuser'':       
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">su <superuser></pre>


::When we change user, we will be by default in the user's home directory [<code style="border-color:#DDE3DB; color:red;">~</code>]. You can do <code style="border-color:#DDE3DB; color:red;">cd ~</code> just in case.


::It is also possible to create a user [<code style="border-color:#DDE3DB; color:red;">waters</code> for example] and give it a limited privilege [to execute a certain command[s] as ''root'']. To do this, create a new file [<code style="border-color:#DDE3DB; color:red;">waters</code> for instance] in the <code style="border-color:#DDE3DB; color:red;">/etc/sudoers.d/</code> directory


=== creating .ssh directory and authorized_keys document in the superuser home directory ===
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">touch /etc/sudoers.d/waters</pre>


As the superuser to whom we want to give ssh access to the server, create a new directory called .ssh and restrict its permissions with the following commands:
::and edit it with <code style="border-color:#DDE3DB; color:red;">visudo</code> ['''this is very important''' as it alerts you regarding any syntax errors]


**mkdir .ssh**
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo visudo /etc/sudoers.d/waters</pre>
**chmod 700 .ssh**
        chown [[superuser:group]]


Now open a file in .ssh called authorized_keys with a text editor. We will use nano to edit the file:
::and add the following line to allow the user <code style="border-color:#DDE3DB; color:red;">waters</code> to use a <code style="border-color:#DDE3DB; color:red;">chmod</code> command for example


**nano .ssh/authorized_keys**
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">waters ALL=(ALL) /usr/bin/chmod</pre>


Now copy-paste the public key (which should be in your clipboard) by pasting it into the editor.
::To allow user <code style="border-color:#DDE3DB; color:red;">waters</code> to run a <code style="border-color:#DDE3DB; color:red;">chmod</code> command without entering a password edit the file this way


Save and close.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">waters ALL= NOPASSWD: /usr/bin/chmod</pre>


Now restrict the permissions of the authorized_keys file with this command:
<br>
<br>


**chmod 600 .ssh/authorized_keys**
===›››››››››››››› .ssh directory and authorized_keys===
        chown [[superuser:group]]


Type this command once to return to the root user:
::'''Creating <code style="border-color:#DDE3DB; color:red;">.ssh</code> directory and <code style="border-color:#DDE3DB; color:red;">authorized_keys</code> document in the superuser home directory'''.


exit
::As the superuser to whom we want to give ssh access to the server, create a new directory called <code style="border-color:#DDE3DB; color:red;">.ssh</code> and restrict its permissions with the following commands:


Now you may SSH login as your new user, using the private key as authentication.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">mkdir .ssh</pre>
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">chmod 700 .ssh</pre>
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">chown superuser:group</pre>
     
::Now open a file in <code style="border-color:#DDE3DB; color:red;">.ssh</code> called <code style="border-color:#DDE3DB; color:red;">authorized_keys</code> with a text editor. We will use nano to edit the file:


::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">nano .ssh/authorized_keys</pre>
       
::Now copy-paste the public key [which should be in your clipboard] by pasting it into the editor. Save and close.


===== SSH Reverse DNS Lookup Disable =====
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ctrl + s</pre>
The invalid logins are normal, since there are bots that try to bruteforce servers.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ctrl + x</pre>
::Now restrict the permissions of the <code style="border-color:#DDE3DB; color:red;">authorized_keys</code> file with this command:


As for the "possible break-in attempt" message, The system is trying to do a reverse DNS lookup to match the connecting IP with the hostname that is trying to connect and fails to do so.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">chmod 600 .ssh/authorized_keys</pre>
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">chown superuser:superuser</pre>
     
::Type this command once to return to the root user:
   
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">exit</pre>


The setting that controls that is "UseDNS" in /etc/ssh/sshd_config
::As we are creating a new user + authentication as root, we have to change the owner of the <code style="border-color:#DDE3DB; color:red;">.ssh</code> directory to the new user [recursively <code style="border-color:#DDE3DB; color:red;">- R</code>]


sudo nano [[/etc/ssh/sshd_config]]
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">chown <user>:<user> .ssh -R</pre>


y agrega la línea:
::Now you [the new sysadmin] may SSH login as your new user, using the private key as authentication.
<br>


UseDNS no
====. . . . . . › How to login with a Host name ====
::You can more smoothly login by ssh with a Host name [ssh anarchaserver, for example] as opposed to ssh superuser@[ip]  you'll need to modify the config file in .ssh directory. Open it:


::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">        sudo nano ~/.ssh/config</pre>


sudo /etc/init.d/ssh restart
::


        Host anarchaserver
        User superuser
        Hostname [IP]
        Port 22
        Identityfile /home/superuser/.ssh/[key]
        Serveraliveinterval 30


===== Force ssh login to server =====
:: Now you can ssh as Host
<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">        ssh anarchaserver</pre>


**sudo nano /etc/ssh/sshd_config**


and change:


ChallengeResponseAuthentication no
<br>
PasswordAuthentication no
====. . . . . . › After reboot====
UsePAM yes


::Access physical mainframe to reboot the encrypted virtual machine. Ask permissions to the syteradmins, by posting on the mailingslist <code style="border-color:#DDE3DB; color:red;">anarchaserver@lists.systerserver.net</code>
<br>
<br>
====. . . . . . › SSH Reverse DNS Lookup Disable====


sudo /etc/init.d/ssh restart
::The invalid logins are normal, since there are bots that try to bruteforce servers.
::As for the "possible break-in attempt" message, The system is trying to do a reverse DNS lookup to match the connecting IP with the ''hostname'' that is trying to connect and fails to do so.
::The setting that controls that is <code style="border-color:#DDE3DB; color:red;">UseDNS</code> in <code style="border-color:#DDE3DB; color:red;">/etc/ssh/sshd_config</code>


::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo nano /etc/ssh/sshd_config</pre>


===== Change ssh port access =====
::y agrega la línea:
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">UseDNS no</pre>


sudo nano /etc/ssh/sshd_config
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo service ssh restart</pre>


The first option that you may want to change is the port that SSH runs on. Find the line that looks like this:
::Force ssh login to server
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo nano /etc/ssh/sshd_config</pre>


Port 22
::and change & uncomment:
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ChallengeResponseAuthentication no</pre>


If we change this number to something in **between 1025 and 65536**, the SSH service on our server will look for connections on a different port. This is sometimes helpful because unauthorized users sometimes try to break into servers by attacking SSH. If you change the location, they will need to complete the extra step of sniffing it out.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">PasswordAuthentication no</pre>


If you change this value, you will need to keep in mind that your server is running on the new port.
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">UsePAM yes</pre>


::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo service ssh restart</pre>
<br>
<br>


**service ssh restart**
====. . . . . . › Change ssh port access====


So now you would have to access to the server like this:
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">sudo nano /etc/ssh/sshd_config</pre>


ssh superuser[[@server]] -p portnumber
::The first option that you may want to change is the port that SSH runs on. Find the line that looks like this: <code style="border-color:#DDE3DB; color:red;">Port 22</code>


::If we change this number to something in '''between 1025 and 65536''', the SSH service on our server will look for connections on a different port. This is sometimes helpful because unauthorized users sometimes try to break into servers by attacking SSH. If you change the location, they will need to complete the extra step of sniffing it out.
::If you change this value, you will need to keep in mind that your server is running on the new port.


====== References ======
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">service ssh restart</pre>


http://ubuntuforums.org/showthread.php?t=1773227
::So now you would have to access to the server like this:


http://bodhizazen.net/Tutorials/SSH_security
::<pre style="background-color:#F2E4F5; border-color:#7F1594; color:blue; width:90%">ssh <superuser>@<server> -p <portnumber></pre>
<br>
<br>
===›››››››››››››› References===
 
::_ [http://ubuntuforums.org/showthread.php?t=1773227  Thread: log full of "POSSIBLE BREAK-IN ATTEMPT!" ]
::_ [https://www.simplified.guide/ssh/restart-service How to start, restart and stop SSH service]
::_ [https://www.simplified.guide/ssh/copy-public-key How to add SSH key to server]
::_ [https://www.golinuxcloud.com/add-user-to-sudoers/ How to add user to sudoers with best practices & examples]
::_ [https://www.cyberciti.biz/faq/linux-unix-running-sudo-command-without-a-password/ How to run sudo command without a password on a Linux or Unix]
::_ [https://pzwiki.wdka.nl/mediadesign/User:E.zn/rpi#Login_with_a_Host_name / How to make config file]

Latest revision as of 10:13, 13 June 2023


›››››››››››››› SSH

SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.



›››››››››››››› Making changes in ssh

Remember to:
 sudo service ssh restart
Tip: I can check all available services in /etc/init.d
Attention: if there are problems, grep to see if it actually stops the service Like this:
 sudo service ssh stop
 ps aux | grep ssh
 sudo service ssh start
 ps aux | grep ssh



›››››››››››››› Debug

Debug with a -v flag. max 3 "v"s
 ssh <user>@<server> -vvv 



›››››››››››››› Create RSA Key Pair

You create your RSA key pair in the computer from which you want to log to the server.
I can use this key pair for several servers, but if I want to enter a same server from different computers, I create different rsa key pairs.
Lo voy a crear a nivel local [en mi compu] y esa va a ser la llave rsa ssh que voy a usar para entrar en mis vps. NO genero una para cada vps sino que esa misma me sirve para todas. Si voy a usar varios ordenadores para entrar en un vps, sí necesitaré crear una llave ssh por máquina desde la cual estoy accediendo.
So each admin in a server is going to have at least one rsa key pair.
Be careful to pay attention from which user you create this in your local machine [computer]. Since the rsa key pairs are saved in a hidden directory in my user home directory [~/.ssh], if Im trying to login from a different user, it will confuse home directories since each user has a different home directory.
So, from the user in my localmachine that I wish to use to access the server, I will create my rsa key pair:
ssh-keygen -t rsa -b 4096
By default it will generate two keys in ~/.ssh, a public key and a private key. We are going to copy our public key to the server. If we don't have access to this server, we will send it to an admin of Anarcha server so that she can do it.
When generating the key, you will need to introduce a passphrase.



›››››››››››››› Copy public key to the server

After generating an SSH key pair, you will want to copy your public key to your new server.
To securely copy the public key, we shall enable password authentication on the remote server, by editing the /etc/ssh/sshd_config file, and disable it after having copied the public key
sudo nano /etc/ssh/sshd_config
uncomment and set PasswordAuthentication to yes and then to no after copying is done.
PasswordAuthentication yes
To copy your public key, run the following command
ssh-copy-id <user>@<server>
To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the .ssh directory in the user's home directory. Assuming that we are going to create superuser accounts for each new admin we will do the following:



›››››››››››››› Creating new sysadmin accounts

Changing to root user
sudo su
Check the sudo users
 grep '^sudo:.*$' /etc/group | cut -d: -f4
If you are not yet, we create a superuser [note: it will ask me to introduce a passwd]
adduser <superusername>
Then we will add the superuser to sudoers:
usermod -aG sudo <superuser>
We now change to superuser:
su <superuser>
When we change user, we will be by default in the user's home directory [~]. You can do cd ~ just in case.
It is also possible to create a user [waters for example] and give it a limited privilege [to execute a certain command[s] as root]. To do this, create a new file [waters for instance] in the /etc/sudoers.d/ directory
touch /etc/sudoers.d/waters
and edit it with visudo [this is very important as it alerts you regarding any syntax errors]
sudo visudo /etc/sudoers.d/waters
and add the following line to allow the user waters to use a chmod command for example
waters ALL=(ALL) /usr/bin/chmod
To allow user waters to run a chmod command without entering a password edit the file this way
waters ALL= NOPASSWD: /usr/bin/chmod



›››››››››››››› .ssh directory and authorized_keys

Creating .ssh directory and authorized_keys document in the superuser home directory.
As the superuser to whom we want to give ssh access to the server, create a new directory called .ssh and restrict its permissions with the following commands:
mkdir .ssh
chmod 700 .ssh
chown superuser:group
Now open a file in .ssh called authorized_keys with a text editor. We will use nano to edit the file:
nano .ssh/authorized_keys
Now copy-paste the public key [which should be in your clipboard] by pasting it into the editor. Save and close.
ctrl + s
ctrl + x
Now restrict the permissions of the authorized_keys file with this command:
chmod 600 .ssh/authorized_keys
chown superuser:superuser
Type this command once to return to the root user:
exit
As we are creating a new user + authentication as root, we have to change the owner of the .ssh directory to the new user [recursively - R]
chown <user>:<user> .ssh -R
Now you [the new sysadmin] may SSH login as your new user, using the private key as authentication.


. . . . . . › How to login with a Host name

You can more smoothly login by ssh with a Host name [ssh anarchaserver, for example] as opposed to ssh superuser@[ip] you'll need to modify the config file in .ssh directory. Open it:
         sudo nano ~/.ssh/config
       Host anarchaserver
       User superuser
       Hostname [IP]
       Port 22
       Identityfile /home/superuser/.ssh/[key]
       Serveraliveinterval 30
Now you can ssh as Host
         ssh anarchaserver



. . . . . . › After reboot

Access physical mainframe to reboot the encrypted virtual machine. Ask permissions to the syteradmins, by posting on the mailingslist anarchaserver@lists.systerserver.net



. . . . . . › SSH Reverse DNS Lookup Disable

The invalid logins are normal, since there are bots that try to bruteforce servers.
As for the "possible break-in attempt" message, The system is trying to do a reverse DNS lookup to match the connecting IP with the hostname that is trying to connect and fails to do so.
The setting that controls that is UseDNS in /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config
y agrega la línea:
UseDNS no
sudo service ssh restart
Force ssh login to server
sudo nano /etc/ssh/sshd_config
and change & uncomment:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM yes
sudo service ssh restart



. . . . . . › Change ssh port access

sudo nano /etc/ssh/sshd_config
The first option that you may want to change is the port that SSH runs on. Find the line that looks like this: Port 22
If we change this number to something in between 1025 and 65536, the SSH service on our server will look for connections on a different port. This is sometimes helpful because unauthorized users sometimes try to break into servers by attacking SSH. If you change the location, they will need to complete the extra step of sniffing it out.
If you change this value, you will need to keep in mind that your server is running on the new port.
service ssh restart
So now you would have to access to the server like this:
ssh <superuser>@<server> -p <portnumber>



›››››››››››››› References

_ Thread: log full of "POSSIBLE BREAK-IN ATTEMPT!"
_ How to start, restart and stop SSH service
_ How to add SSH key to server
_ How to add user to sudoers with best practices & examples
_ How to run sudo command without a password on a Linux or Unix
_ / How to make config file