Bo2SS

Experimental Environment: Ubuntu 18.04 Remote Server + WSL 2 Local Machine

Evaluation Instructions#

• 

• The data you need during the evaluation process can be found here: Public Key for Evaluation Service

• Additional: What is the essence of passwordless login?

Final Effect#

【Local Testing】

• 

• SSH hostname, passwordless login is now available

• It's green again :)

Implementation Process#

Two Steps ⭐#

【Generate Key Pair 👉 Copy Public Key】

• ① Generate a public-private key pair on the local WSL 2 [.pub suffix is the public key], here we choose the RSA encryption algorithm

ssh-keygen -t rsa

• • You can use ssh-keygen --help to view various information about key types, etc.
  • Generally, you do not need to set a passphrase [for encrypting the private key], unless you want to enter a password every time for passwordless login
• ② Configure the public key on the remote server, just one command

ssh-copy-id ten

• • Here, ten is the alias for the remote server (the username defaults to the local user, otherwise you can use the format hz@ten), specific setup methods can refer to “Linux Introduction and Usage” Notes Summary - 5 Basic System - Additional Knowledge Points: Use SSH nickname to log in to the cloud host
  • Alternatively, you can use the ssh-copy-id username@IP format, where ten and username@IP are equivalent in the following text

🔚 At this point, passwordless login has been achieved, connect to the cloud host ten for testing

ssh ten

Detailed Steps of ssh-copy-id#

If you want to manually achieve the effect of ssh-copy-id, you can refer to the following steps:

• Copy the local public key to the home directory of the remote server

scp ~/.ssh/id_rsa.pub ten:

• SSH into the home directory of the remote server and append the contents of the public key to the key configuration file

cat id_rsa.pub >> .ssh/authorized_keys
rm id_rsa.pub  # Can delete

• • authorized_keys can store multiple different public keys, each line corresponds to one
  • If there is no .ssh directory and authorized_keys file, create them yourself
  • 【Key】 is the 【permissions】 of both, which need to be specifically set: make the .ssh directory have full permissions only for the owner, and make the authorized_keys file have read and write permissions only for the owner; otherwise, passwordless login may fail

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

🔚 At this point, passwordless login has also been achieved

【Permission Requirements】

• You can refer to man sshd
  • 
  • For security reasons, if the permission settings do not meet the requirements, the public key file cannot be used

Additional Notes#

• Ensure that the PubkeyAuthentication in /etc/ssh/sshd_config on both the local machine and the remote server is set to yes, and restart the sshd service after modification: systemctl restart sshd.service
• To enable passwordless login for a specific user on the remote server, place the public key in the corresponding location in that user's 【home directory】

The Essence of Passwordless Login#

Process ⭐#

• The local machine initiates an SSH connection and sends the local public key
• The remote server receives the public key and compares it with the local public key
• If they match, the server encrypts a "random string" with the public key and sends it back to the local machine
• The local machine uses the private key to decrypt the "random string" and sends the result back to the server
• If they match, the connection is established

❗ Refer to Principles and Implementation of Passwordless SSH Login——Juejin

【This mentions the specific processes of password login and passwordless login】

• Password Login
  • 
  • Encrypting the password using the public key of the remote server
• Passwordless Login
  • 
  • The transmission process does not expose the private key

Password login is simpler than passwordless login, as password login is faster during connection
However, passwordless login is more secure:

• ① Passwords are easier to crack
• ② The referenced article mentions that passwordless login does not have the risk of "man-in-the-middle attacks," which I do not completely agree with
  • Both rely on .ssh/known_hosts to identify machines
  • Passwordless login involves an additional public key match, making it more secure
  • 【Note】 But this is under the condition that the local public key has not been stolen by a man-in-the-middle

Additional Notes#

• ssh -v ten: You can see a more detailed process
• There is a widely circulated image online, but it contains details errors, as follows:
  • 
  • The request information is not the username and IP ❌, but the local public key
  • The public key does not store the IP [otherwise it would pose a risk], it stores the local username and hostname
  • You can try removing the user information [username and hostname] from the local or remote server's public key, and you can still connect via SSH without a password
  • It can be seen that the remote server verifies the public key string itself!

Points of Reflection#

• What is the authentication displayed during the first login to the cloud host?
  • 
  • What is the ECDSA key fingerprint? It is the key fingerprint from the remote server; each machine with SSH installed has its own fingerprint
  • After entering yes, the corresponding fingerprint information will be stored in the local .ssh/known_hosts, which can raise an alert if a spoofing machine exists during the next connection
  • If there is a spoofing machine [man-in-the-middle] attack during the first connection, then congratulations, you have won a prize
  • Refer to Verifying Remote Host SSH Fingerprint——Blog

Additional#

• Usage of ssh-copy-id

  • Directly copies the public key of the local user to the authorized_keys file in the remote machine's home directory/.ssh
  • 
  • Simpler and more direct, can specify specific public keys, specific ports, etc.

• You can use man sshd_config to view the specific configuration instructions for sshd_config

• ⭐ Disable password login by changing PasswordAuthentication to no in /etc/ssh/sshd_config

  • 
  • Restart the sshd service: systemctl restart sshd.service to take effect

• The location of the public key can be set through AuthorizedKeysFile in /etc/ssh/sshd_config

  • 
  • By default, it looks for the public key in the corresponding location in the user's home directory

• What is ChallengeResponseAuthentication?

  • 

ChallengeResponseAuthentication no
# Allows any type of password authentication! Therefore, any authentication method specified in login.conf can be applied!
# However, we currently prefer to use the PAM module to help manage authentication, so this option can be set to no!

References#

• SSH Login Without a Password——howchoo
• Pitfalls and Solutions for Passwordless SSH Login——Coder's Garden
  • It mentions setting the permissions of authorized_keys to 644, as the file owner is root; you can also change the file owner [I personally think the latter is safer]
• Text Interface Online Server: SSH Server——Bird Brother's Linux Cookbook
• Changing SSH Login Port to Disable Password Login and Enable Passwordless Login——Jianshu
• Can SSH Public Key Verification Prevent Man-in-the-Middle Attacks?——Zhihu
  • No, it is avoided through the known_hosts verification during the first connection.