Write section on changing password, but there's more to do
All checks were successful
continuous-integration/laminar-elessar Build 72 succeeded in 1 minute 20 seconds .
All checks were successful
continuous-integration/laminar-elessar Build 72 succeeded in 1 minute 20 seconds .
This commit is contained in:
parent
f40245d004
commit
e86218f944
1 changed files with 24 additions and 4 deletions
|
@ -120,14 +120,34 @@ Execute the command as above, replacing `"yourusername"` with the user you creat
|
|||
|
||||
At this point, you should be able to logout and log back in as the new user account you've just created - you should do this now.
|
||||
|
||||
If you're creating a new account to replace the default non-root user account, it's a good idea at this point to delete the old default user account now. This helps ensure that
|
||||
If you're creating a new account to replace the default non-root user account, it's a good idea at this point to delete the old default user account now. This helps keep your VM secure, as fewer user accounts (note: system accounts are a different topic) mean fewer potential entry points for attackers.
|
||||
|
||||
The Linux security model: Knowing why you're typing your password
|
||||
Don't forget also that you should always know _why_ you're typing your password. This is a key security mechanism in Linux: anything that needs administrative privileges should be done through `sudo`, and `sudo` requires your password. If it didn't require your password, then _anything_ running under a user account that has `sudo` privileges would be able to run a command as `root` at any time, which is obviously a bad thing.
|
||||
|
||||
### Setting your password
|
||||
If you didn't change the default user account that's come with your VM (or even if you did), you should probably change your account password. Leaving your account password as the default is the best way to invite an attacker in to hack your server.
|
||||
|
||||
Thankfully, this is really easy to do. Simply enter the following command:
|
||||
|
||||
```bash
|
||||
passwd
|
||||
```
|
||||
|
||||
It will ask you for your current password, and ten for a new password twice. Once done, try logging out and then back in again to see that your new password has been applied. Note that this will also affect things when you're using `sudo`: you should use your new password instead of the old one, since the password you use with `sudo` is synced with your local user account.
|
||||
|
||||
It's also worth mentioning at this point that storing said password in a secure _password manager_ would be a good idea, rather than writing it down in a text file. Password databases are encrypted with a master password, which is much more secure. Many password managers exist, from [KeePass](https://keepass.info/) to [Firefox Lockwise](https://www.mozilla.org/en-GB/firefox/lockwise/) to [(insert another suggestion here)]()
|
||||
|
||||
|
||||
### Securing SSH
|
||||
Used by servers and their administrators across the world to talk to one another, if someone manages to get in who isn't supposed to, they could do all kinds of damage!
|
||||
At this point if you're still using the physical VMware console, it might be worth signing in to your VM via _SSH_. Standing for _Secure SHell_, it's used by servers and their administrators across the world to talk to one another. TO do this, you'll need the IP address of your server. Get this like so:
|
||||
|
||||
```bash
|
||||
hostname -I
|
||||
```
|
||||
|
||||
Then, open PuTTY **TODO: Finish this**
|
||||
|
||||
If someone manages to get in who isn't supposed to, they could do all kinds of damage!
|
||||
|
||||
The first, and easiest thing we can do it improve security is to prevent the `root` user logging in. We already have a non-root account that we use `sudo` with, so why allow direct access to `root` at all? Edit `/etc/ssh/sshd_config`, finding the line that says something like this:
|
||||
|
||||
|
@ -214,7 +234,7 @@ When the key is generated, you’ll see the public key displayed in a text box.
|
|||
|
||||
Next, you’ll be prompted to enter a passphrase for your SSH key. This improves security by preventing someone who gains access to your private key from using it without also knowing the passphrase. You’ll need to provide your passphrase every time you use this key (unless you use SSH agent software that stores the decrypted key).
|
||||
|
||||
![A screenshot fo PuTTYgen asking for a password.](images/puttygen-password.png)
|
||||
![A screenshot of PuTTYgen asking for a password.](images/puttygen-password.png)
|
||||
|
||||
When you’re done, click the "save private key" button and select a secure location to keep it. You can name your key whatever you’d like, and the extension `.ppk` is automatically added.
|
||||
|
||||
|
|
Loading…
Reference in a new issue