SSH¶

Overview¶

Servers running SSH are usually a soft target for brute-force attacks. Hackers are constantly coming up with innovative software tools and bots for automating brute-force attacks which further increase the risk of intrusion.

In this guide, we explore some of the tips that you can implement to safeguard your SSH servers from brute-force attacks on RHEL-based Linux distributions and Debian derivatives.

Disable SSH Password Authentication and Enable SSH-Key Authentication The default authentication method for SSH is username/password authentication. But as we have seen, password authentication is prone to brute-force attacks. To be on the safe side, it is recommended to implement key-based SSH authentication where authentication is made possible by public and private SSH key pairs. The private key remains on the client’s PC while the public key is copied to the server.

During SSH key authentication, the server checks whether the client PC possesses the private key. If the check is successful, a shell session is created or the command sent to the remote server is executed successfully. We have a comprehensive guide on how to configure SSH key-based authentication.

Implement Fail2ban Intrusion Prevention Tool Written in Python, Fail2ban is an open-source intrusion prevention framework that scans log files of services for authentication failures and bans IPs that repeatedly fail password authentication checks for a specified amount of time.

Fail2ban constantly monitors server log files for intrusion attempts and other nefarious activity, After a predefined number of authentication failures – in most cases, 3 failed login attempts – Fail2ban automatically blocks the remote host from accessing the server, and the host is kept in a ‘Jail‘ for a specific duration of time.

In doing so, Fail2ban significantly reduces the rate of incorrect password authentication attempts. Check out our guide on how you can install and configure Fail2ban on Linux to secure your server from Bruteforce attacks.

Limit Maximum Number of SSH Authentication Attempts Another simple way of safeguarding your server from brute-force attacks is by limiting the number of SSH login attempts. By default, this is set to 3, but if by any chance this is set to a higher value, set it to 3 connection attempts at most.

For example, to set the maximum connection attempts to 3 set the MaxAuthTries parameter to 3 as shown

MaxAuthTries = 3 Once again, save the changes and reload the SSH service.

$ sudo systemctl reload ssh

TCP wrappers is a library that provides a host-based Access Control List (ACL) that restricts access to TCP services by remote clients based on their IP addresses

Remote hosts from accessing services on the system. TCP wrappers uses the /etc/hosts.allow and /etc/hosts.deny configuration files (in that order) to determine if the remote client is allowed to access a specific service or not.

Usually, these files are commented out and all hosts are allowed through the TCP wrappers layer. Rules for allowing access to a given service are placed in the /etc/hosts.allow file and take precedence over the rules in the /etc/hosts.deny file.

Usecase: Deploy code to an target server using SSH

Configure the hosts or domains that can connect to the server via SSH as shown. In this example, we are allowing only two remote hosts to connect to the server (173.82.227.89 and 173.82.255.55) and denying the rest.

sshd: 173.82.227.89 173.82.255.55 sshd: ALL: DENY

Best practice recommends blocking all incoming connections. Therefore, open the /etc/hosts.deny file.

$ sudo vim /etc/hosts.deny Add the following line.

ALL: ALL Save the changes and exit the file.

Then access the /etc/hosts.allow file.

$ sudo vim /etc/hosts.allow

https://www.tecmint.com/prevent-ssh-brute-force-login-attacks/

how ssh work

SSH Essentials: Working with SSH Servers, Clients, and Keys Published on October 17, 2014 · Updated on September 18, 2020 Linux Basics Security Networking System Tools Default avatar By Justin Ellingwood

SSH Essentials: Working with SSH Servers, Clients, and Keys Introduction SSH is a secure protocol used as the primary means of connecting to Linux servers remotely. It provides a text-based interface by spawning a remote shell. After connecting, all commands you type in your local terminal are sent to the remote server and executed there.

In this cheat sheet-style guide, we will cover some common ways of connecting with SSH to achieve your objectives. This can be used as a quick reference when you need to know how to connect to or configure your server in different ways.

How To Use This Guide Read the SSH Overview section first if you are unfamiliar with SSH in general or are just getting started. Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the following examples independently. Use the Contents menu on the left side of this page (at wide page widths) or your browser’s find function to locate the sections you need. Copy and paste the command-line examples given, substituting the highlighted values with your own values. SSH Overview The most common way of connecting to a remote Linux server is through SSH. SSH stands for Secure Shell and provides a safe and secure way of executing commands, making changes, and configuring services remotely. When you connect through SSH, you log in using an account that exists on the remote server.

How SSH Works When you connect through SSH, you will be dropped into a shell session, which is a text-based interface where you can interact with your server. For the duration of your SSH session, any commands that you type into your local terminal are sent through an encrypted SSH tunnel and executed on your server.

The SSH connection is implemented using a client-server model. This means that for an SSH connection to be established, the remote machine must be running a piece of software called an SSH daemon. This software listens for connections on a specific network port, authenticates connection requests, and spawns the appropriate environment if the user provides the correct credentials.

The user’s computer must have an SSH client. This is a piece of software that knows how to communicate using the SSH protocol and can be given information about the remote host to connect to, the username to use, and the credentials that should be passed to authenticate. The client can also specify certain details about the connection type they would like to establish.

How SSH Authenticates Users Clients generally authenticate either using passwords (less secure and not recommended) or SSH keys, which are very secure.

Password logins are encrypted and are easy to understand for new users. However, automated bots and malicious users will often repeatedly try to authenticate to accounts that allow password-based logins, which can lead to security compromises. For this reason, we recommend always setting up SSH key-based authentication for most configurations.

SSH keys are a matching set of cryptographic keys which can be used for authentication. Each set contains a public and a private key. The public key can be shared freely without concern, while the private key must be vigilantly guarded and never exposed to anyone.

To authenticate using SSH keys, a user must have an SSH key pair on their local computer. On the remote server, the public key must be copied to a file within the user’s home directory at ~/.ssh/authorized_keys. This file contains a list of public keys, one-per-line, that are authorized to log into this account.

When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use. The server then checks its authorized_keys file for the public key, generates a random string, and encrypts it using the public key. This encrypted message can only be decrypted with the associated private key. The server will send this encrypted message to the client to test whether they actually have the associated private key.

Upon receipt of this message, the client will decrypt it using the private key and combine the random string that is revealed with a previously negotiated session ID. It then generates an MD5 hash of this value and transmits it back to the server. The server already had the original message and the session ID, so it can compare an MD5 hash generated by those values and determine that the client must have the private key.

Now that you know how SSH works, we can begin to discuss some examples to demonstrate different ways of working with SSH

https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys

Finally, ensure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

chmod -R go= ~/.ssh

Output ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test Access your remote host using whichever method you have available.

Once you have access to your account on the remote server, you should make sure the ~/.ssh directory exists. This command will create the directory if necessary, or do nothing if it already exists:

mkdir -p ~/.ssh Now, you can create or modify the authorized_keys file within this directory. You can add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if necessary, using this command:

echo public_key_string >> ~/.ssh/authorized_keys In the above command, substitute the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you executed on your local system. It should start with ssh-rsa AAAA....

Finally, ensure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

chmod -R go= ~/.ssh This recursively removes all "group" and "other" permissions for the ~/.ssh/ directory.

If you’re using the root account to set up keys for a user account, it’s also important that the ~/.ssh directory belongs to the user and not to root. In the following example, the user is named sammy but you should substitute the appropriate username into the command.

chown -R sammy:sammy ~/.ssh You can now attempt passwordless authentication with your CentOS server.

Step 3 — Authenticating to your CentOS Server Using SSH Keys If you have successfully completed one of the procedures above, you should be able to log into the remote host without the remote account’s password.

The basic process is the same:

ssh username@remote_host If this is your first time connecting to this host (if you used the last method above), you may see something like this:

Output The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes This means that your local computer does not recognize the remote host. Type yes and then press ENTER to continue.

If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created it, you will be prompted to enter the passphrase now. After authenticating, a new shell session should open for you with the configured account on the CentOS server.

If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.

Step 4 — Disabling Password Authentication on your Server If you were able to login to your account using SSH without a password, you have successfully configured SSH-key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.

Before completing the steps in this section, make sure that you either have SSH-key-based authentication configured for the root account on this server, or preferably, that you have SSH-key-based authentication configured for a non-root account on this server with sudo privileges. This step will lock down password-based logins, so ensuring that you will still be able to get administrative access is crucial.

Once you’ve confirmed that your remote account has administrative privileges, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Then, open up the SSH daemon’s configuration file:

sudo vi /etc/ssh/sshd_config Inside the file, search for a directive called PasswordAuthentication. This may be commented out. If it is, press i to insert text, and then uncomment the line by deleting the # in front of the PasswordAuthentication directive. When you find the directive, set the value to no. This will disable your ability to log in via SSH using account passwords:

/etc/ssh/sshd_config ... PasswordAuthentication no ... When you are finished making changes, press ESC and then :wq to write the changes to the file and quit. To implement these changes, you need to restart the sshd service:

sudo systemctl restart sshd.service As a precaution, open up a new terminal window and test that the SSH service is functioning correctly before closing this session:

ssh username@remote_host Once you have verified your SSH service, you can safely close all current server sessions.

The SSH daemon on your CentOS server now only responds to SSH keys. Password-based authentication has successfully been disabled.

Conclusion You should now have SSH-key-based authentication configured on your server, allowing you to sign in without providing an account password.

If you’d like to learn more about working with SSH, take a

https://devpress.csdn.net/cicd/62ec3f7219c509286f416951.html

When you write your secret name, please use uppercase letters with underscores as spaces (as shown in the placeholder). This is a format we usually use for specifying secrets.

In this case, I chose to name the secret SSH_PRIVATE_KEY.

For the value, we need to go back into your server and open up the github-actions private key. We can do this with nano.. nano github-actions

You'll see a file similar to this. (Don't worry about me exposing this key, I trashed it already. I just wanted to show you exactly what to expect :)).

github actions private key

We need to copy everything and paste it inside the Secret value

paste private key inside secret value

We can use the key like this:

Next, click on "Add secret" and you'll be brought back to the secrets page. Here, you'll see SSH_PRIVATE_KEY under the repository's secrets.

saved secret ssh-private-key

Step 4: Adding the Private key to a Github Actions Workflow I'm assuming you already know how to create a basic Github Actions file, so I'll only talk about steps for adding the SSH Key here.

Adding the private key is a complex business, I chose to look for available Github Actions here. The only action that worked for me was Shimataro's Install SSH Key. steps:

• name: Install SSH Key uses: shimataro/ssh-key-action@v2

The Install SSH Key action requires two inputs — key and known_hosts value.

key is the private key we added to Github Secrets. We can use the secrets like this: steps:

• name: Install SSH Key uses: shimataro/ssh-key-action@v2 with: key: ${{ secrets.SSH_PRIVATE_KEY }}

The known_hosts value is a weird hashed value. If you open up a known_hosts file in the .ssh server, you'll see something like this:

opened known hosts file

We're supposed to add ONE of these values into a Github Actions secret. How do we even get this value in the first place?! Unfortunately, none of the Github Actions showed me how to do this, so I had to google around for a while -_-.

Thankfully, we can use a command to generate this weird hashed value. I'll talk about this command in the next step. For now, we simply have to add a random value to known_hosts so Shimataro's Install SSH Key won't give us an error. steps:

• name: Install SSH Key uses: shimataro/ssh-key-action@v2 with: key: ${{ secrets.SSH_PRIVATE_KEY }} known_hosts: 'just-a-placeholder-so-we-dont-get-errors'

Step 5: Adding a correct known_hosts value We can generate the correct known_hosts value with a ssh-keyscan command. It looks like this: ssh-keyscan -H IP_ADDRESS_OF_HOST

If you replace IP_ADDRESS_OF_HOST with the actual ip address of your server, you should get a result like this. (I omitted my ip address but tried to show you everything else).

inserted ip address result

Once we know this, we can manually add the IP address (which I named as SSH_HOST) into the Github Secrets.

add IP address to github secrets

Then we can generate the correct information via ssh-keyscan and append it to the known_hosts file. steps:

...¶

• name: Adding Known Hosts run: ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

Step 6: Rsync into Server We can finally rsync via SSH into the server. To do this, you need to know your SSH user and host. Here's what the command looks like. rsync -flags source user@host:destination

flags are the flags you would like to rsync with. We commonly use avz which stands for archive, verbose, and compress. If you're rsync-ing for the first time, I recommend using the n flag for dry-run as well. source is the source file you want to copy from user@host is the username and ip address of the your server. These values should be kept as secrets. destination is the location of the files you want to copy to. Here's a real example of what I use to deploy zellwk.com to my server.

• name: Deploy with rsync run: rsync -avz ./dist/ \({{ secrets.SSH_USER }}@\):/home/zellwk/zellwk.com/dist/}

Since we have the verbose flag, you should be able to see a list of resources that are copied via rsync.

I wanted to use Github Actions to deploy zellwk.com — when I push a commit into Github, I want Github Actions to build my site and deploy to my Digital Ocean server.

The hardest part of this process is deploying to the server with SSH and rsync. I tried various Github actions like SSH Deploy and SSH Action, but I couldn't get the permissions to work for A LONG TIME.

I found most articles about Github actions and SSH didn't help me much. I got stuck with debugging for a few days before I finally figured out how to make the process work.

Today, I want to share the exact steps to deploy via rsync and SSH. This process works for any server, even if you don't use Digital Ocean.

Step 2: Adding the Public Key to authorized_keys We need to add the public key (github-actions.pub) to authorized_keys so machines using the private key (github-actions) can access the server.

The easiest way is to use a cat command to append github-actions.pub into authorized_keys. It look like this: cat github.pub >> authorized_keys

Wrapping up Here are the steps to summarize everything:

Generate a SSH Keyphrase using the standard RSA format Add the public key to authorized_keys Add the private key as a Github secret Use Shimataro's Install SSH Key action to generate a SSH Key in the runner. Append the correct known_hosts configuration with ssh-keyscan Deploy with Rysnc via SSH Done! :)

Progress¶

Genenerate key

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Note: Some Github Action authors said we need the PEM format for SSH keys to work. This is false. I've tested with the standard RSA format (which I recommended above) and it works.

Next we need to name the SSH Key file. Here, I don't recommend using the default file name (which is id_rsa). I recommend switching the file name to github-actions so we know this key is used for Github Actions. It pays to be explicit when you view your SSH keys 6 months down the road.

SSH Config Examples¶

Overview¶

Understanding ~/.ssh/config entries Host : Defines for which host or hosts the configuration section applies. The section ends with a new Host section or the end of the file. A single * as a pattern can be used to provide global defaults for all hosts. HostName : Specifies the real host name to log into. Numeric IP addresses are also permitted. User : Defines the username for the SSH connection. IdentityFile : Specifies a file from which the user’s DSA, ECDSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2. ProxyCommand : Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with the user’s shell. In the command string, any occurrence of %h will be substituted by the host name to connect, %p by the port, and %r by the remote user name. The command can be basically anything, and should read from its standard input and write to its standard output. This directive is useful in conjunction with and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.1.0.253: ProxyCommand /usr/bin/nc -X connect -x 192.1.0.253:3128 %h %p LocalForward : Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be [bind_address:]port and the second argument must be host:hostport. Port : Specifies the port number to connect on the remote host. Protocol : Specifies the protocol versions ssh(1) should support in order of preference. The possible values are 1 and 2. ServerAliveInterval : Sets a timeout interval in seconds after which if no data has been received from the server, will send a message through the encrypted channel to request a response from the server. See blogpost "Open SSH Server connection drops out after few or N minutes of inactivity" for more information. ServerAliveCountMax : Sets the number of server alive messages which may be sent without receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session.

This is copy-paste example. Verify before using it.

## Default for all
Host *
     ForwardAgent no
     ForwardX11 no
     ForwardX11Trusted yes
     User nixcraft
     Port 22
     Protocol 2
     ServerAliveInterval 60
     ServerAliveCountMax 30

## override as per host
Host server1
     HostName server1.cyberciti.biz
     User nixcraft
     Port 4242
     IdentityFile /nfs/shared/users/nixcraft/keys/server1/id_rsa

## Home nas server ##
Host nas01
     HostName 192.168.1.100
     User root
     IdentityFile ~/.ssh/nas01.key

## Login AWS Cloud ##
Host aws.apache
     HostName 1.2.3.4
     User wwwdata
     IdentityFile ~/.ssh/aws.apache.key

## Login to internal lan server at 192.168.0.251 via our public uk office ssh based gateway using ##
## $ ssh uk.gw.lan ##
Host uk.gw.lan uk.lan
     HostName 192.168.0.251
     User nixcraft
     ProxyCommand  ssh nixcraft@gateway.uk.cyberciti.biz nc %h %p 2> /dev/null

## Our Us Proxy Server ##
## Forward all local port 3128 traffic to port 3128 on the remote vps1.cyberciti.biz server ##
## $ ssh -f -N  proxyus ##
Host proxyus
    HostName vps1.cyberciti.biz
    User breakfree
    IdentityFile ~/.ssh/vps1.cyberciti.biz.key
    LocalForward 3128 127.0.0.1:3128

CHECK service erquired

check sshd is online

man sshd

An alias is nothing but shortcut to commands and you can create the alias use the following syntax in your ~/.bashrc file:

create a new bash shell alias as follow¶

alias server1="ssh -i /nfs/shared/users/nixcraft/keys/server1/id_rsa -p 4242 nixcraft@server1.cyberciti.biz" Then, to ssh into the server1, instead of typing full ssh -i /nfs/shared/users/nixcraft/keys/server1/id_rsa -p 4242 nixcraft@server1.cyberciti.biz command, you would only have to type the command ‘server1’ and press the [ENTER] key: $ server1

Overriding ssh config file option The ssh command reads its configuration in the following order:

ssh command line-option ~/.ssh/config option /etc/ssh/ssh_config options Say you have the following options set in ~/.ssh/config:

Host ln.openvpn-sg-vpn1 ln.wireguard-sg-vpn1 Hostname 172.16.0.1 User vivek port 22 IdentityFile ~/.ssh/id_ed25519.pub StrictHostKeyChecking no Now want to use all other options from ~/.ssh/config but to connect using admin user instead of vivek, then: $ ssh -o "User=admin" ln.openvpn-sg-vpn1

We can specifies an alternative per-user configuration file such as /dev/null to disable ~/.ssh/config too by passing the -F: $ ssh -F /dev/null admin@172.16.0.1 $ ssh -F /dev/null vivek@172.16.0.1 $ ssh -F /dev/null -i ~/.ssh/aws/id_ed25519.pub vivek@172.16.0.1

If your team has GitHub Action:

you can use

- name: Install SSH key of target
  uses: shimataro/ssh-key-action@v2
  with:
    key: ${{ secrets.SSH_KEY_OF_TARGET }}
    name: id_rsa-target
    known_hosts: ${{ secrets.KNOWN_HOSTS_OF_TARGET }} # will be appended to existing .ssh/known_hosts
    config: | # will be appended to existing .ssh/config
      Host target
        HostName yyy.yyy.yyy.yyy
        User user-of-target
        IdentityFile ~/.ssh/id_rsa-target
        ProxyCommand ssh -W %h:%p bastion

Toolset¶

I built an interactive set to use with SSH

Troubleshooting¶

What is PEM style

Note: Some Github Action authors said we need the PEM format for SSH keys to work. This is false. I've tested with the standard RSA format (which I recommended above) and it works.

Finally, ensure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

chmod -R go= ~/.ssh

Check the permission

I had the same issue, and I solved it as follows:

Allow SSH Access To A User

To allow SSH access for a particular user, for example superuser, edit in your server /etc/ssh/sshd_config file:

sudo nano /etc/ssh/sshd_config

Add or modify the following line:

AllowUsers superuser

Save the file (Ctrl+O)

Restart ssh, in Debian for example: sudo /etc/init.d/ssh restart

Now, you should be able to connect!

https://superuser.com/questions/522094/how-do-i-resolve-a-ssh-connection-closed-by-remote-host-due-to-inactivity

System-wide OpenSSH config file client configuration /etc/ssh/ssh_config : This files set the default configuration for all users of OpenSSH clients on that desktop/laptop and it must be readable by all users on the system.

Tăng Tốc độ ssh session Thêm đoạn sau vào config:

ControlPath ~/.ssh/controlmasters/%r@%h:%p ControlMaster auto

Sau khi thêm đoạn code sẽ như sau:

Host viblo_project Hostname 192.168.1.100 User root Port 4444 ControlPath ~/.ssh/controlmasters/%r@%h:%p ControlMaster auto

Giới thiệu Hiện nay server là vps đã khá phổ biến, vì vậy việc cần ssh vào server để cài đặt cấu hình đã rất quen thuộc đối với những người hay phải quản trị server. Việc nhớ tất cả các thông tin của server để ssh vào chạy lệnh là một công việc phức tạp, nhất là đối với ai quản trị nhiều server cùng một lúc.

Hôm này mình giới thiệu cho các bạn một cách có thể rút ngắn thời gian ssh vào server cũng như không cần nhớ những thông tin phức tạp của server như ip, port ...

Bạn có thể cấu hình máy khách OpenSSH ssh của bạn bằng các tệp tin khác nhau như sau để tiết kiệm thời gian và nhập các tùy chọn dòng lệnh ssh thường xuyên được sử dụng như port, user, hostname, identity-file và nhiều hơn nữa:

Cấu hình. Đầu tiên bạn cần edit file ~/.ssh/config bằng một text editor nào đó, ví dụ như nano, vi ... Cú pháp để config có dạng như sau: config value config1 value1 value2

Nếu trên máy tính của bạn chưa tồn tại thư mục .ssh thì cần chạy lệnh sau: mkdir -p $HOME/.ssh chmod 0700 $HOME/.ssh

Một số option hay dùng để cấu hình ssh config như sau:

Host: Tên viết tắt của máy chủ, bạn có thể đặt bất kì cái nào dễ nhớ nhất, giả sử tên dự án HostName: Địa chỉ ip của máy chủ User : User để ssh vào server. IdentityFile: Chính là public key của ssh, mặc định nó sẽ tìm trong ~/.ssh/id_rsa nếu bạn không config. ProxyCommand: Command đặc biệt khi connect vào server

$ ssh root@173.82.235.7

kex_exchange_identification: read: Connection reset by peer Connection reset by 173.82.235.7 port 22 lost connection

diagnoss the server

Reference¶

https://devpress.csdn.net/cicd/62ec3f7219c509286f416951.html

https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys

https://www.cyberciti.biz/faq/create-ssh-config-file-on-linux-unix/

https://viblo.asia/p/cau-hinh-shortcut-ssh-config-4P8560RRZY3