Start of ssh config article
This commit is contained in:
parent
c98ed3bf85
commit
c433d3801a
184
content/rambles/ssh-configuration.md
Normal file
184
content/rambles/ssh-configuration.md
Normal file
|
|
@ -0,0 +1,184 @@
|
|||
---
|
||||
title: "SSH Configuration"
|
||||
date: "2022-09-27T11:40:31+02:00"
|
||||
author: "$HUMANOID"
|
||||
tags: ["ssh", "technology"]
|
||||
description: "An article on configuring SSH from the ground up to something that can grow out into my monster of a configuration"
|
||||
draft: true
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
If you're anything like me, you'll have at least a hand full of servers you'll log into (at least) every now and then using SSH.
|
||||
These servers don't all have the same key.
|
||||
And on top of that, I frequently have multiple keys per host.
|
||||
Managing this by hand is a pain in the arse.
|
||||
Thankfully there are a few tools that make it a breeze.
|
||||
I will be going through what I have done to both my local configuration and what I tend to do with my server configuration.
|
||||
|
||||
# Generating keys
|
||||
|
||||
In order to do anything with SSH in a secure way, you'll need to make use of public and private keys.
|
||||
These keypairs are generated using `ssh-keygen`.
|
||||
I typically generate mine using:
|
||||
```sh
|
||||
ssh-keygen -t ed25519 -f ~/.ssh/<new-key>
|
||||
```
|
||||
Without any parameters, it will generate an rsa3072 key.
|
||||
This form of cryptography isn't the recommended as it's become a bit flimsy with computers becoming stronger.
|
||||
Instead I recommend at least adding the `-t ed25519` flag to generate a ed25519 key instead.
|
||||
|
||||
When prompted for a passphrase, **_always_** give it one.
|
||||
The only reason where _not_ using a passphrase is acceptable is when you are planning on using the key for a [forced command]().
|
||||
|
||||
# Server Configuration
|
||||
|
||||
This is all done under the assumption that the you use OpenSSH implementation on your server.
|
||||
If you use something like Dropbear, I can't help you as haven't properly dug through it's configuration file (yet).
|
||||
|
||||
The thing I see way to often on the internet is
|
||||
|
||||
* People not disabling password authentication.
|
||||
* Changing the default port or only allowing.
|
||||
* Don't disable root login and never use it.
|
||||
|
||||
So lets go through these steps one by one.
|
||||
|
||||
## Password Authentication
|
||||
|
||||
Password authentication is _the_ most basic thing every server should have disabled.
|
||||
Otherwise, it is possible to brute force a connection into your server.
|
||||
|
||||
> "But my server is not exposed to the internet."
|
||||
|
||||
I guess you _could_ get away with not disabling password authentication, but it's still not a good idea in case, say, your network gets compromised.
|
||||
On top of that, it's less convenient to have to type in a password every time you want to log into your server (more in that in the SSH Agent section).
|
||||
|
||||
In order to disable password authentication, open your SSH daemon configuration file: `/etc/ssh/sshd_config` and look for the following lines...
|
||||
```sshd_config
|
||||
...
|
||||
# To disable tunneled clear text passwords, change to no here!
|
||||
#PasswordAuthentication yes
|
||||
#PermitEmptyPasswords no
|
||||
...
|
||||
```
|
||||
...uncomment `PasswordAuthentication` and replace "yes" for "no".
|
||||
Make sure you still have a way into your server before restarting the daemon.
|
||||
|
||||
If you're not planning on logging in as the root user, uncomment and set the following setting to "no"
|
||||
```sshd_config
|
||||
...
|
||||
#PermitRootLogin prohibit-password
|
||||
...
|
||||
```
|
||||
|
||||
Be aware of the fact that you can still utilise the root account using `sudo su -` (assuming you're using `sudo` on your server, else use whatever other privilege escalation tool you have at hand).
|
||||
|
||||
Restarting the daemon on modern systems is usually done using:
|
||||
```sh
|
||||
systemctl restart sshd
|
||||
```
|
||||
If you're not using systemd, I'm sure you know what command to use instead.
|
||||
|
||||
## Adding keys to `authorized_keys`
|
||||
|
||||
When going through `/etc/ssh/sshd_config` you've probably come across a few lines resembling:
|
||||
```sshd_config
|
||||
...
|
||||
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
|
||||
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
|
||||
...
|
||||
```
|
||||
|
||||
This means that the SSH daemon will check in `.ssh/authorized_keys` in the home directory of the user as whom you're trying to log in for public keys.
|
||||
So the next step is to append your public key to this file in the home directory of the user as whom you want to be able to log in.
|
||||
This can be done in a few ways.
|
||||
The proper way is by using:
|
||||
|
||||
```sh
|
||||
ssh-copy-id -i ~/.ssh/<key-file> <user>@<host>
|
||||
```
|
||||
I'm usually too lazy to use the proper way and just open the file in `vi` paste it in there by hand during the same initial login where I'm disabling password authentication.
|
||||
Either way works fine.
|
||||
|
||||
## Changing the port
|
||||
|
||||
The advantage to this is that your logs will be a lot cleaner if your host is exposed to the internet.
|
||||
There are large amounts of bots hammering port `22` on every IP address they can find with common usernames and passwords like "root" and "admin".
|
||||
A solution next to this is to use `fail2ban` along side changing the port.
|
||||
|
||||
> "Won't this mean I have to add the port to my login command every time I go to this server?"
|
||||
|
||||
No, more in this in [the client configuration] section
|
||||
|
||||
In `/etc/ssh/sshd_config` look for
|
||||
```sshd_config
|
||||
...
|
||||
#Port 22
|
||||
#AddressFamily any
|
||||
#ListenAddress 0.0.0.0
|
||||
#ListenAddress ::
|
||||
...
|
||||
```
|
||||
and change the `Port` to your liking, I tend to change this to something like 6969 or some other meme number.
|
||||
|
||||
Another thing I tend to do is not open a port in my firewall, thus preventing any normal outside connections all together.
|
||||
Instead opting to only connecting over Yggdrasil and/or Tor.
|
||||
|
||||
# Client configuration
|
||||
|
||||
If people tend not to think much about their server configuration, their client configuration is probably not even touched at all.
|
||||
|
||||
## The `~/.ssh/config` file
|
||||
|
||||
The very first thing I do after setting up a server, is add an entry to my `~/.ssh/config` in order to manage its key, the user, the port and possibly subdomain should the need arise.
|
||||
|
||||
A basic configuration section looks like the following:
|
||||
```ssh_config
|
||||
Host <host> # this is something you can easily identify
|
||||
Host <hostname> # this does need to be an IP address or DNS record pointing to an IP address
|
||||
IdentityFile ~/.ssh/<key-file>
|
||||
User <username>
|
||||
Port 6969
|
||||
```
|
||||
This allows you to log into host `<host>` with on port `6969` with key `~/.ssh/<key-file>` as user `<username>` without by typing:
|
||||
```sh
|
||||
ssh <username>@<hostname> -p 6969 -i ~/.ssh/<key-file>
|
||||
```
|
||||
Instead the following command will work:
|
||||
```sh
|
||||
ssh <host>
|
||||
```
|
||||
|
||||
Some other frequently used settings for me are:
|
||||
* `AddKeysToAgent`
|
||||
* `IdentitiesOnly`
|
||||
* `ProxyCommand`
|
||||
|
||||
### `AddKeysToAgent`
|
||||
|
||||
Automatically adds the key to your SSH agent if you have one running.
|
||||
|
||||
This is useful if you frequently log in and out of a certain host and don't want to take the time to add it's key to your agent manually.
|
||||
|
||||
### `IdentitiesOnly`
|
||||
|
||||
Ignore whatever keys your agent has and only use the contents of `IdentityFile`.
|
||||
|
||||
Useful for when you want to be able to log into the same host using multiple keys.
|
||||
|
||||
### `ProxyCommand`
|
||||
|
||||
Always connect to your host using a proxy.
|
||||
|
||||
Useful for when you can only access a host through a certain proxy.
|
||||
|
||||
I use this for my Tor hosts:
|
||||
|
||||
```ssh_config
|
||||
Host tor-<host>
|
||||
Hostname <lengthy-56-character-string>.onion
|
||||
ProxyCommand nc -X 5 -x localhost:9050 %h %p # this assumes you are running a tor proxy on your local system and attempts to make a connection through that
|
||||
Identityfile ~/.ssh/<key-file>
|
||||
User <user>
|
||||
```
|
||||
Loading…
Reference in a new issue