SSH Connection Setup: Difference between revisions

From WikiMLT
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
<noinclude>{{ContentArticleHeader/Linux_Server|toc=off}}{{ContentArticleHeader/Linux_Desktop}}</noinclude>
<noinclude>{{ContentArticleHeader/Linux_Server|toc=off}}{{ContentArticleHeader/Linux_Desktop|toc=off}}{{ContentArticleHeader/DevOps and SRE|toc=off}}{{ContentArticleHeader/Network_and_Security}}</noinclude>
The [[wikipedia:Secure_Shell|Secure Shell Protocol]] ('''[https://manpages.ubuntu.com/manpages/jammy/man1/ssh.1.html SSH]''') is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.


== Install SSH Server and Client ==
== Install SSH Server and Client ==
The SSH client is the software that makes an SSH connection to a remote instance. The SSH server is the software that accepts the connection no the remote instance. In case we don't need to connect to the client instance - i.e. it is laptop, we do not neet to install the server.<syntaxhighlight lang="shell" line="1">
The SSH client is the software that makes an SSH connection to a remote instance. The SSH server is the software that accepts the connection no the remote instance. In case we don't need to connect to the client instance - i.e. it is laptop, we do not need to install the server.<syntaxhighlight lang="shell" line="1">
sudo apt install openssh-server openssh-client
sudo apt install openssh-server openssh-client
</syntaxhighlight>When the server is installed its service is automatically enabled and started, so if we have installed both packages above, we can test whether it is operational by an SSH to the loop-back interface.<syntaxhighlight lang="shell" line="1">
</syntaxhighlight>When the server is installed its service is automatically enabled and started, so if we have installed both packages above, we can test whether it is operational by an SSH to the loop-back interface.<syntaxhighlight lang="shell" line="1">
sudo apt install openssh-server openssh-client
ssh localhost
</syntaxhighlight>By default within the SSH server's configuration the password login is enabled. It is much safer to use key based authentication and once it is setup and operational we can safely disable the password authentication.
</syntaxhighlight>I normal case you would like to test the connection to a remote host, where, let's assume, the SSH server is also fresh installed.<syntaxhighlight lang="shell" line="1">
ssh -p 22 <user>@<ip.address-or-host.name>
</syntaxhighlight>
 
* The <code>-p</code> option is not mandatory while the default SSH port at the server's side isn't changed.
 
By default, within the SSH server's configuration, the password login authentication is enabled. It is much safer to use key based authentication and once it is setup and operational we can safely disable the password authentication.


== Setup Key Based Authentication ==
== Setup Key Based Authentication ==
{{collapse/begin}}
First we need to generate SSH key pair . This should be done at the client's side. It is preferable to use '''ED25519''' based key, because it is more secure and also it is faster because is much shorten especially than 4096 bit RSA key. For more details read the references below.
First we need to generate SSH key pair . This should be done at the client's side. It is preferable to use '''ED25519''' based key, because it is more secure and also it is faster because is much shorten especially than 4096 bit RSA key.
{{collapse/div|#References}}
*[https://security.stackexchange.com/q/90077/131156 SSH Key: Ed25519 vs RSA]
* [https://security.stackexchange.com/q/101044/131156 Is it bad that my ed25519 key is so short compared to a RSA key?]
* [https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54 Upgrade Your SSH Key to Ed25519]
* [https://cryptsus.com/blog/how-to-secure-your-ssh-server-with-public-key-elliptic-curve-ed25519-crypto.html How to secure your SSH server with public key Ed25519 Elliptic Curve Cryptography]
* [https://wiki.metalevel.tech/index.php?oldid=30758 <u>The previous version of the answer which uses RSA key</u>].
{{collapse/end}}


=== Generate SSH Key Pair ===
=== Generate SSH Key Pair ===
To generate public and private SSH keys within ''your'' user's <code>'''~/.ssh'''</code> directory use the following commands.
To generate public and private SSH keys within ''your'' user's <code>'''~/.ssh'''</code> directory use the following commands.
<syntaxhighlight lang="shell" line="1" class="mlw-continue">
<syntaxhighlight lang="shell" line="1" class="mlw-shell-gray code-continue">
mkdir -m700 ~/.ssh/access-remote.host.name
EMAIL="me@metalevel.tech"
ssh-keygen -t ed25519 -C 'your@email.com' -f ~/.ssh/access-remote.host.name/id_ed25519
SSH_KEY_DIR="${HOME}/.ssh/access-remote.host.name"
</syntaxhighlight>
<syntaxhighlight lang="shell" line="1" class="code-continue">
mkdir -m700 "$SSH_KEY_DIR"
ssh-keygen -t ed25519 -C "$EMAIL" -f "${SSH_KEY_DIR}/id_ed25519"
</syntaxhighlight>
</syntaxhighlight>
<syntaxhighlight lang="shell" line="1" class="mlw-shell-gray">
<syntaxhighlight lang="shell" line="1" class="mlw-shell-gray">
ls -la ~/.ssh/access-remote.host.name
ls -la "$SSH_KEY_DIR"
</syntaxhighlight>
</syntaxhighlight>
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 38: Line 41:
*Is's not mandatory to enter a real email address.
*Is's not mandatory to enter a real email address.


=== Copy The Public Key to the Remote host ===
=== Copy the Public key to the Remote host ===
We need to copy the content of the generated public key - <code>id_ed25519.pub</code>, - to the remote hosts user's <code>~/.ssh/authorized_keys</code> file. This could be done in various ways, but if you cold login to the remote in some way - i.e. with password authentication, the most easiest way is to use the command <code>ssh-copy-id</code>, which is a part of the <code>openssh-client</code> package and is already installed.<syntaxhighlight lang="shell" line="1" class="mlw-continue">
We need to copy the content of the generated public key - <code>id_ed25519.pub</code>, - to the remote hosts user's <code>~/.ssh&shy;/&shy;autho&shy;rized&shy;_&shy;keys</code> file. This could be done in various ways, but if you cold login to the remote in some way - i.e. with password authentication, the most easiest way is to use the command <code>ssh-copy-id</code>, which is a part of the <code>openssh-client</code> package and is already installed.<syntaxhighlight lang="shell" line="1" class="code-continue">
ssh-copy-id -p 22 -i ~/.ssh/access-remote.host.name/id_ed25519 <user>@<ip.address-or-host.name>
ssh-copy-id -p 22 -i ~/.ssh/access-remote.host.name/id_ed25519 <user>@<ip.address-or-host.name>
</syntaxhighlight>
</syntaxhighlight>
Line 53: Line 56:
and check to make sure that only the key(s) you wanted were added.
and check to make sure that only the key(s) you wanted were added.


</syntaxhighlight>At this point you should be able to establish a SSH connection to the remote host by a command as the following.<syntaxhighlight lang="shell" line="1" class="code-continue">
ssh -p 22 -i ~/.ssh/access-remote.host.name/id_ed25519 <user>@<ip.address-or-host.name>
</syntaxhighlight>
== Setup the <code>'''~/.ssh/config'''</code> file at the Client's side ==
for easy access the remote instances, without needing type the whole command above, you can add an entry within the user's configuration file <code>[https://manpages.ubuntu.com/manpages/jammy/man5/ssh_config.5.html ~/.ssh/config]</code> at the client's side. In case the file isn't exist you must need to create it first.<syntaxhighlight lang="shell" line="1" class="code-continue mlw-shell-gray">
touch ~/.ssh/config && chmod 600 ~/.ssh/config
</syntaxhighlight>
</syntaxhighlight>
<syntaxhighlight lang="shell" line="1" class="code-continue">
nano ~/.ssh/config
</syntaxhighlight>
<syntaxhighlight lang="terraform">
Host remote.host.name
HostName <ip.address-or-host.name>
IdentityFile ~/.ssh/access-remote.host.name/id_ed25519
User <user>
Port 22
</syntaxhighlight>
* note the <code>remote.host .name</code> that I've used several times is like a ''nickname'' for the remote instance.
At this point you should be able to connect to the remote host by the following synopsis.the remote host by the following command.<syntaxhighlight lang="shell" line="1" class="code-continue">
ssh remote.host.name
</syntaxhighlight>
== Setup the <code>'''/etc/ssh/sshd_config'''</code> file at the Server's side ==
<code>[https://manpages.ubuntu.com/manpages/jammy/man5/sshd_config.5.html /etc/ssh/sshd_config]</code> is the daemon's (server's) configuration file. The minimum security tweaks that should be done, once there is SSH key based authentication available, are at least: 1) Disable the password authentication, 2) Disable the root login, 3) Change the default port or add a second port to listen which will be forwarded through a NAT and will be publicly available.
For this purpose add or modify the relevant lines in your <code>/etc/ssh/sshd_config</code> file.<syntaxhighlight lang="shell" line="1" class="code-continue">
sudo nano /etc/ssh/sshd_config
</syntaxhighlight>
<syntaxhighlight lang="bash" class="code-continue">
Port 22
Port 10181
PermitRootLogin no
PasswordAuthentication no
</syntaxhighlight>
<syntaxhighlight lang="shell" line="1" class="code-continue">
sudo systemctl restart ssh.service
</syntaxhighlight>'''Important!''' When you makes changes to a remote server's configuration keep an additional SSH connection open to be sure you can access the instance in case there is something wrong.
== Firewall Setup ==
This topic is out of the scope of this I'm placing this section as remainder of that, you need to open the SSH port(s) in use within the server's firewall.
== References ==
== References ==
* ...
* [[SSH Persistent Tunnel and SSHFS Mount via "systemd" units]]


* ...
* [[GitHub SSH key based authentication]]




Line 65: Line 111:
  | Прндл  = Linux Server
  | Прндл  = Linux Server
  | Прндл1 = Linux Desktop
  | Прндл1 = Linux Desktop
  | Стадий = 3
| Прндл2 = DevOps and SRE
  | Фаза  = Разработване
| Прндл3 = Network and Security
  | Статус = Разработван
  | Стадий = 6
  | Фаза  = Утвърждаване
  | Статус = Утвърден
  | ИдтПт  = Spas
  | ИдтПт  = Spas
  | РзбПт  = {{REVISIONUSER}}
  | РзбПт = Spas
| АвтПт  = Spas
| УтвПт = {{REVISIONUSER}}
  | ИдтДт  = 5.09.2022
  | ИдтДт  = 5.09.2022
  | РзбДт  = {{Today}}
  | РзбДт = 5.09.2022
| АвтДт  = 5.09.2022
| УтвДт = {{Today}}
  | ИдтРв  = [[Special:Permalink/31155|31155]]
  | ИдтРв  = [[Special:Permalink/31155|31155]]
  | РзбРв  = {{REVISIONID}}
  | РзбРв = [[Special:Permalink/31178|31178]]
| АвтРв  = [[Special:Permalink/31180|31180]]
| УтвРв = {{REVISIONID}}
}}
}}
</div>
</div>
</noinclude>
</noinclude>

Latest revision as of 13:24, 9 April 2023

The Se­cure Shell Pro­to­col (SSH) is a cryp­to­graph­ic net­work pro­to­col for op­er­at­ing net­work ser­vices se­cure­ly over an un­se­cured net­work. Its most no­table ap­pli­ca­tions are re­mote lo­gin and com­mand-line ex­e­cu­tion.

In­stall SSH Serv­er and Client

The SSH client is the soft­ware that makes an SSH con­nec­tion to a re­mote in­stance. The SSH serv­er is the soft­ware that ac­cepts the con­nec­tion no the re­mote in­stance. In case we don't need to con­nect to the client in­stance – i.e. it is lap­top, we do not need to in­stall the serv­er.

sudo apt install openssh-server openssh-client

When the serv­er is in­stalled its ser­vice is au­to­mat­i­cal­ly en­abled and start­ed, so if we have in­stalled both pack­ages above, we can test whether it is op­er­a­tional by an SSH to the loop-back in­ter­face.

ssh localhost

I nor­mal case you would like to test the con­nec­tion to a re­mote host, where, let's as­sume, the SSH serv­er is al­so fresh in­stalled.

ssh -p 22 <user>@<ip.address-or-host.name>
  • The -p op­tion is not manda­to­ry while the de­fault SSH port at the server's side isn't changed.

By de­fault, with­in the SSH server's con­fig­u­ra­tion, the pass­word lo­gin au­then­ti­ca­tion is en­abled. It is much safer to use key based au­then­ti­ca­tion and once it is set­up and op­er­a­tional we can safe­ly dis­able the pass­word au­then­ti­ca­tion.

Set­up Key Based Au­then­ti­ca­tion

First we need to gen­er­ate SSH key pair . This should be done at the client's side. It is prefer­able to use ED25519 based key, be­cause it is more se­cure and al­so it is faster be­cause is much short­en es­pe­cial­ly than 4096 bit RSA key. For more de­tails read the ref­er­ences be­low.

Gen­er­ate SSH Key Pair

To gen­er­ate pub­lic and pri­vate SSH keys with­in your user's ~/.ssh di­rec­to­ry use the fol­low­ing com­mands.

EMAIL="me@metalevel.tech"
SSH_KEY_DIR="${HOME}/.ssh/access-remote.host.name"
mkdir -m700 "$SSH_KEY_DIR"
ssh-keygen -t ed25519 -C "$EMAIL" -f "${SSH_KEY_DIR}/id_ed25519"
ls -la "$SSH_KEY_DIR"
total 16
drwx------  2 <user> <user> 4096 Jul 20 21:36 .
drwx------ 12 <user> <user> 4096 Jul 20 21:28 ..
-rw-------  1 <user> <user> 3381 Jul 20 21:36 id_ed25519
-rw-r--r--  1 <user> <user>  742 Jul 20 21:36 id_ed25519.pub
  • You can add a passphrase to pro­tect your pri­vate key in case it be­come stolen, oth­er­wise leave it emp­ty. You will need to en­ter the passphrase each tine the pri­vate key is used.
  • Is's not manda­to­ry to en­ter a re­al email ad­dress.

Copy the Pub­lic key to the Re­mote host

We need to copy the con­tent of the gen­er­at­ed pub­lic key – id_ed25519.pub, – to the re­mote hosts user's ~/.ssh­/­autho­rized­_­keys file. This could be done in var­i­ous ways, but if you cold lo­gin to the re­mote in some way – i.e. with pass­word au­then­ti­ca­tion, the most eas­i­est way is to use the com­mand ssh-copy-id, which is a part of the openssh-client pack­age and is al­ready in­stalled.

ssh-copy-id -p 22 -i ~/.ssh/access-remote.host.name/id_ed25519 <user>@<ip.address-or-host.name>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/<user>/.ssh/<access-remote.host.name>/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
<user>@<ip.address-or-host.name>'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh -p '22' '<user>@<ip.address-or-host.name>'"
and check to make sure that only the key(s) you wanted were added.

At this point you should be able to es­tab­lish a SSH con­nec­tion to the re­mote host by a com­mand as the fol­low­ing.

ssh -p 22 -i ~/.ssh/access-remote.host.name/id_ed25519 <user>@<ip.address-or-host.name>

Set­up the ~/.ssh/config file at the Client's side

for easy ac­cess the re­mote in­stances, with­out need­ing type the whole com­mand above, you can add an en­try with­in the user's con­fig­u­ra­tion file ~/.ssh/config at the client's side. In case the file isn't ex­ist you must need to cre­ate it first.

touch ~/.ssh/config && chmod 600 ~/.ssh/config
nano ~/.ssh/config
Host remote.host.name
	HostName <ip.address-or-host.name>
	IdentityFile ~/.ssh/access-remote.host.name/id_ed25519
	User <user>
	Port 22
  • note the remote​.host .name that I've used sev­er­al times is like a nick­name for the re­mote in­stance.

At this point you should be able to con­nect to the re­mote host by the fol­low­ing synopsis.the re­mote host by the fol­low­ing com­mand.

ssh remote.host.name

Set­up the /​​​etc/​​​ssh/​​​sshd_​​​config file at the Server's side

/​​​etc/​​​ssh/​​​sshd_​​​config is the daemon's (server's) con­fig­u­ra­tion file. The min­i­mum se­cu­ri­ty tweaks that should be done, once there is SSH key based au­then­ti­ca­tion avail­able, are at least: 1) Dis­able the pass­word au­then­ti­ca­tion, 2) Dis­able the root lo­gin, 3) Change the de­fault port or add a sec­ond port to lis­ten which will be for­ward­ed through a NAT and will be pub­licly avail­able.

For this pur­pose add or mod­i­fy the rel­e­vant lines in your /​​​etc/​​​ssh/​​​sshd_​​​config file.

sudo nano /etc/ssh/sshd_config
Port 22
Port 10181
PermitRootLogin no
PasswordAuthentication no
sudo systemctl restart ssh.service

Im­por­tant! When you makes changes to a re­mote server's con­fig­u­ra­tion keep an ad­di­tion­al SSH con­nec­tion open to be sure you can ac­cess the in­stance in case there is some­thing wrong.

Fire­wall Set­up

This top­ic is out of the scope of this I'm plac­ing this sec­tion as re­main­der of that, you need to open the SSH port(s) in use with­in the server's fire­wall.

Ref­er­ences