Category Archives: security

backup, mac, mail, networking, postfix, security, Uncategorized

Setting up a mac remotely

I want to be able to get to my wife’s mac, in another city. She is an unsophisticated user, and I’d like to be able to help her when she needs help, but I can’t ask her to do very much setup. I also want to be able to provide backup for her files.

The first step was to outfit her with one of the little gateway pis previously described. Once that was done, we managed, together, to enable me to get to her mac with ssh, by way of the pi tunnel. And we managed to set up an account on her mac under my name.

Continue reading Setting up a mac remotely →
backup, linux, networking, postfix, security, ubuntu

Gateway pi

1 Comment

I realized as I was writing a new post that I had never documented the gateway pi undertaking.

This started when a friend in the mountains got a new internet service where the ISP would not allow him (and therefore me) access to his router. As a result I could no longer use ssh to connect to his systems.

I solved this problem by setting his systems up to use a tool called autossh, with which I could have his system start, monitor, and keep running an ssh daemon with reverse tunnels open to my system. I could then reach him by attaching through the reverse tunnels.

Continue reading Gateway pi →
encryption, linux, networking, security, ubuntu, vpn

Adding a VPN Router to the network

The topology for the handling of downloads of stuff via a vpn previously involved a vpn client directly on rosemary. The problem with this was that sometimes the vpn would fail – it would get disconnected from the remote end. If I didn’t realize this, and started a download, it would be in the clear.

I thought a better solution was to have a separate router (herein the “vpn” router) between rosemary and the external router, and to have that router establish a constant vpn through it’s wan interface, through the external router. Everything that connected to a lan port on the vpn router would be protected. Rosemary would then use the vpn router as its path to the internet. Everything that rosemary sends or receives from the internet would come exclusively through the vpn router.

Continue reading Adding a VPN Router to the network →
cloud, encryption, fedora, linux, security, ubuntu, vpn

Setting Up Openvpn Server

The objective of this project was to install a vpn server on one of the boxes in the cloud (initially asafoetida, then moved to tarragon), in order to provide a VPN server service for a friend who was traveling. My friend uses the name Darrell for his client, so in what follows the vpn is called by this name.

Create a Certificate Authority

A lot of the instructions, even from openvpn site, say to use the “easyrsa” package to generate the certificates for openvpn. This package seems to be put out by the openvpn boys, or at least with their cooperation. But I didn’t do that. I created a ca with raw openssl.

Continue reading Setting Up Openvpn Server →

encryption, gateways, linux, openssh, security

Using openssh certificates

I’m writing this in February 2020, but I should have posted it last April. This is about using openssh certificates for authentication.

For many years I have used exclusively public-key authentication for ssh connections. None of the boxes I support ever allows password authentication for ssh. But as the number of boxes in the constellation has grown, the problem of keeping the public keys up to date has become nightmarish. If I really truly needed NxN capability it would be unmanageable. The truth is though that there are only 3 or 4 boxes from which I typically establish ssh connections to all the others.

Still it is – if not a full-blown nightmare, at least a bad dream. The folks at openssh implemented a mechanism to make it easier: certificates. These are not full blow x509 certificates, they are simpler, but the idea is the same. The problem: how do we arrange to get a public key on to some box with confidence that the public key belongs to the party it purports to represent? The certificate answer is to have the public-key signed by a party that the recipient trusts.

So how does it work. I designate a box as my “signer”. All the other boxes in my world trust the signer. Instead of putting public keys on every box, instead every box has its own public key signed by the “signer”. When it wishes to connect to another box (in my own constellation of boxes) it presents its certificate – i.e. its signed public key. Since the recipient trusts the signer, it will accept the signed public key as being the genuine public key, and it can then proceed to authenticate.

How it works mechanically is that when I initialize a new box, and create a new key pair for it, I have to send the new public key to the signer. Then, on the signer system I sign the key, and send it back to the new box. I’m actually using my repository for the moving of this stuff back and forth. I think this is ok, since the only thing that ever appears in the repository are public keys and public certificates. The public keys exist in the repo for mere moments. The certificates stay there. But the private keys of course never leave the box on which they originate.

boot issues, fedora, linux, networking, security

New Internal Network setup

Owing to the failure of oregano detailed in the last post, I have finally taken steps to clean up a long standing issue in my internal network, viz: that oregano, the primary development computer was offering essential network services which all the other boxes relied upon. When oregano was down, almost everything else suffered.

This problem dates back at least 20 years. In early days I began the practice of having my primary linux computer act as a firewall separating the rest of the network from the internet, and as the dhcp server. I won’t try to defend the practice – it was what I did; but it has made less and less sense over the years. Plus it had the very undesirable side effect that when that primary computer was down the other systems lost their dhcp server and their path to the net.

I had this generic Chinese openwrt router which I bought last year, for reasons passing understanding. I’d planned to replace the primary router with it, but that proved a bad plan. I decided to use this extra router to fill the role oregano had filled, of separating the internal and external networks.

So this router, named obelisk, performs dhcp and dns forwarding. Henceforth Oregano will be just another box on the internal network.

apache, cloud, encryption, fedora, linux, mail, postfix, security, ubuntu, website building

Certificates Redux

An earlier post talked about switching my server tarragon (where this blog sits) to a wildcard certificate from letsencrypt. There were two reasons why I was using a wildcard certificate. One had to do with test versions of websites that run on this server, and the need that some of those sites have for wildcards, of the form: bob.websitename.com, sally.websitename.com, etc. The other reason was that I have a lot of hosts (oregano, cinnamon, paprika, lemongrass) in addition to tarragon that “need” to have a certificate, for https, for imap, and for smtp, and when I was having to pay for them, it was cheaper to get one wildcard for wmbuck.net. Continue reading Certificates Redux →

apache, encryption, fedora, linux, security, website building

Apache Quiet Failure on Certificate/Key mismatch

In an earlier post I related how I had moved to letsencrypt for tarragon. In the process of doing some cleanup of the /etc/letsencypt directory, and my repository, I managed to stupidly get one wrong private key file into the batch of all the https vhosts, such that the http config file for xyz.com specified an SSLCertificateFile and SSLCertificateKeyFile which did not match.

It took me hours and hours to figure this out, because Apache simply fails to start and gives no indication whatever what has pissed him off. I wasn’t too stupid to figure out that I had been messing with the certs yesterday, and the problem might lie there somehow. But I have about 15 vhosts, so it was tedious. In the end I resorted to strace, and saw the problem.

 

apache, cloud, encryption, fedora, linux, security, ubuntu, website building

LetsEncrypt Wildcard Certificates

1 Comment

Comodo is after me to renew, offering a free year. The last time I attempted to install a wildcard certificate from Lets Encrypt, shortly after they introduced the feature, I wasn’t able to figure it out. Now, 9 months later, there is a lot more information about how to do it. Before spending the money for a commercial cert, I thought I would give it a try.

I used the following on tarragon:


certbot certonly \
--server https://acme-v02.api.letsencrypt.org/directory \
--manual
-d wmbuck.net -d *.wmbuck.net \
--preferred-challenges dns

It is important that the server url by v02, because v01 servers can’t issue wildcard certs. I had to put TXT records in the DNS for them to verify, and they created the cert into the /etc/letsencrypt/live directory where all the others are.

This was trivially easy. Goodbye Comodo.