How to set up your SSH config file: Simplify Your Life With an SSH Config File, a blog post from 2011. I’m 45 and have been using GNU/Linux since way back before people had Internet at home here in Switzerland and I’ve only learned about this today. 😮
Simplify Your Life With an SSH Config File
@danyspin97 recommended autossh which keeps connections alive. “Autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic.” I don’t often run into this problem, though.
@zladuric recommended multiplexing which speeds up reconnecting to a server. “OpenSSH can reuse an existing TCP connection for multiple concurrent SSH sessions. This results into reduction of the overhead of creating new TCP connections.” I never saw this as problem, though. Probably because the host I connect to most often is in the same city as I am and I have fibre to the home. But if you’re a heavy duty system administrator perhaps?
@oliof recommended sshshuttle for people that forward many ports and don’t have a virtual private network (VPN). “Transparent proxy server that works as a poor man’s VPN. Forwards over ssh. Doesn’t require admin.” I don’t need that, either. Maybe if I had more need to circumventing geoblocking. 😁
Since we’re talking about SSH, here’s the most important server-side advice I have for you:
1. use `fail2ban` to temporarily ban IP numbers that cause too many failed login attempts
2. change the default port to something else in orther to reduce the number of login attempts
3. if you need to allow `root` access on your system (which I do if I want to make backups using `rsync`) then use the `prohibit-password` option
The last two are changes you make to the `/etc/ssh/sshd_config` file. Uncomment `#Port 22` and change the port, and set the `PermitRootLogin` option to `prohibit-password`.
#Administration
(Please contact me if you want to remove your comment.)
⁂
One thing I like to do is to configure a group, which a user has to be in, to be allowed to ssh in. So the default is that a user can’t.
This avoids e.g. the problem where you create a dummy user with a weak password to test something, and forget to delete the user. Not that I’ve ever done that. Noooo.
I’ve split the users allowed to ssh in up into “sshusers” and “sshkeyusers”, the first category is allowed to use a password (basically, me), and the second category can only login with a key (the handful of friends that have access). In `/etc/ssh/sshd_config` I have:
# Only allow sshusers/sshkeyusers to ssh in: AllowGroups sshusers sshkeyusers Match Group sshkeyusers PasswordAuthentication no
– Adam 2018-11-11 15:22 UTC
---
Hahaha! 😎
Luckily, that server should only have me on it. But you’re right. Better be safe than sorry!
– Alex Schroeder 2018-11-11 18:32 UTC
---
I currently have the following:
# List of user names allowed to log in. # We need root for our backup script. # We need git for git-via-SSH repos. AllowUsers alex git root PermitRootLogin prohibit-password
So let me think this through:
1. I want `alex` to connect using a password just in case.
2. I don’t want `git` to connect using a password (not sure why it seems to have a password in `/etc/shadow` and `/usr/bin/git-shell` as its shell in `/etc/passwd` and I don’t know whether any of these obviate a setting in `/etc/sshd_config`) 🤔❓
3. I don’t want `root` to connect using a password.
So I added the following:
Match User git
PasswordAuthentication no
Seems to work as intended, for now.
– Alex Schroeder 2018-11-12 13:26 UTC
---
“The rage that one felt was an abstract, undirected emotion which could be switched from one object to another like the flame of a blowlamp.” – George Orwell, 1984, chapter 1
– Alex Schroeder 2018-11-12 13:30 UTC