Unixcat.net Wiki - User contributions [en]

Should You Switch to Linux?

2024-02-10T09:18:11Z

ToroidalCore:

Note: At the moment this article is unfinished.

Most desktop computing is dominated by the Windows operating system from Microsoft. There's a good chance you're reading this on a Windows machine, although you really might not be. It might be running macOS as well, or maybe it could be a phone or tablet running Android or iOS. Or something else. Or, you might very well be reading this on a Linux machine... Or some sort of BSD. You get the idea. One way or another, you're reading it.

But you are a a computer user of some sort. And if you primarily use Windows or macOS, you may or may not be contemplating using Linux on your desktop. There are different reasons for this. Maybe the idea of it or the philosophy behind it sounds interesting, or maybe you're just curious about it. Maybe you need it for work. Or, you're just frustrated with the system you already use, and want to try an alternative. Maybe people have recommended it to you. Or perhaps tried to discourage you from trying it.

I pretty much use it exclusively outside of work as my "daily driver," and have for years, and plan to continue doing so. Does this mean I think it's the greatest thing ever? Not really. I've had my share of ups and downs with it, and have had my share of frustration with it. I keep using it because it works for me, and overall I'm happy with it. The purpose of this page is to give an account of Linux as a desktop system from my point of view, to encourage you to try it, or discourage you, but mostly just to lay out what it is.

== Who This is For ==

This page is intended for a variety of people. Obviously, for anyone giving some thought into daily driving a Linux-based system, but there are some particular types of computer users I have in mind. The important thing I'll point out is that I will try to strike a balance between Note that it's quite possible to fall into or between these groups, or outside of them completely. You don't have to fall in line exactly, these are just some examples. :)

=== Power Users ===

This is someone who uses Windows and/or macOS routinely for a certain set of tasks, professionally or at home. This person probably does this enough that they've put some effort into streamlining what they do, ie customizing their system to some extent, and learning ins and outs like keyboard shortcuts.

=== Causal Users ===

This is someone for whom the computer is kind of like an appliance, someone who boots it up now and then to check on something or do some one-off task. I imagine this to be someone who types a document now and then, checks email or social media, or browses the web. The computer is most definitely general purpose, and they may or may not have deep familiarity with the operating system they use. Unlike the power user, this type's usage patterns are less rigid.

=== Enthusiast ===

This person is generally interested in computers, and may own several of them. They may actually run Linux or some other Unix-like system on some machine, and be contemplating using it as their main desktop. This person will probably be interested in exploring how the OS on their computer works, and what it can do. They may also have more tolerance for problems that arise due to bugs or mistakes.

=== Required For Something ===

This type of user needs to learn Linux for a specific reason, like for work or school. Could also be secondary to some other interest, such as an enthusiast who wants to learn Linux for a Raspberry Pi project, for example.

=== Anyone Growing Their Skills ===

Similar to the enthusiast, or someone who needs it for something, this person just wants to gain a new skill.

=== Looking for Something Different ===

This person just wants a change. I don't know how how likely it is for someone to be learning Linux for this reason, but I can imagine someone just wanting a different computing environment to escape to for some reason, perhaps to put one into a different state of mind.

=== Misc ===

As I mentioned, you may fit into one, several, or none of these as per your specific circumstances.

[[Category:Desktop_Linux]]

Should You Switch to Linux?

2024-02-10T09:01:59Z

ToroidalCore:

Should You Switch to Linux?

2024-01-22T06:30:51Z

ToroidalCore:

Should You Switch to Linux?

2024-01-22T06:13:48Z

ToroidalCore:

**Note: At the moment this article is unfinished.

Most desktop computing is dominated by the Windows operating system from Microsoft. There's a good chance you're reading this on a Windows machine, although you really might not be. It might be running macOS as well, or maybe it could be a phone or tablet running Android or iOS. Or something else. Or, you might very well be reading this on a Linux machine... Or some sort of BSD. You get the idea. One way or another, you're reading it.

But you are a a computer user of some sort. And if you primarily use Windows or macOS, you may or may not be contemplating using Linux on your desktop. I pretty much use it exclusively outside of work as my "daily driver,"

[[Category:Desktop_Linux]]

Should You Switch to Linux?

2024-01-22T06:06:34Z

ToroidalCore: Created page with " Category:Desktop_Linux"

[[Category:Desktop_Linux]]

Category:Desktop Linux

2024-01-22T06:05:35Z

ToroidalCore:

Desktop-specific pages for GNU/Linux and other *nix systems (eg BSDs). Basically, this means using these systems as workstations, primarily graphical.

Includes howtos, workflows, etc.

[[Category:UnixLike]]

Main Page

2024-01-05T08:39:15Z

ToroidalCore:

Welcome to the Unixcat.net wiki. Here you will find different articles and pages that I don't feel fit into the [https://blog.unixcat.net blog] format. These include things like how-tos, descriptions of projects, and other pages I'm not publishing in chronological order.

Note that at some point in the future, this may disappear if I decide to present it all in some other way. For now, though, wiki it is.

=== Some Categories to Check Out ===

[[:Category:Desktop Linux]]

Not just GNU/Linux. Tips, tricks, notes, etc. on using *nix systems on the desktop.

Main Page

2024-01-05T08:38:58Z

ToroidalCore:

Welcome to the Unixcat.net wiki. Here you will find different articles and pages that I don't feel fit into the [https://blog.unixcat.net blog] format. These include things like how-tos, descriptions of projects, and other pages I'm not publishing in chronological order.

Note that at some point in the future, this may disappear if I decide to present it all in some other way. For now, though, wiki it is.

{{Special:RecentChanges}}

=== Some Categories to Check Out ===

[[:Category:Desktop Linux]]

Not just GNU/Linux. Tips, tricks, notes, etc. on using *nix systems on the desktop.

FFMPEG Commands

2024-01-05T06:47:44Z

ToroidalCore:

Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another. Many of the scripts are working on the Bourne Shell on FreeBSD, since that's where I'm converting most of my media at the moment. They haven't been tested in Bash, but should work.

You should have some familiarity with FFMPEG and shell scripting. These are provided as a convenience; use at your own risk and be sure to make backups. I am not responsible for any loss of data as a result of using these!

== Video ==

Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal:

$ ffmpeg -i infile.avi outfile.mp4

Whereas something meant to run as a script will look like this:

#!/bin/sh

ffmpeg -i infile.avi outfile.mp4

The above should go in a text file and be made executable.

Unless otherwise noted, the scripts are meant to be run in a directory full of files you want to convert. You can put the script someplace like <code>~/bin</code>, change to the directory, and just run it. If you have a lot of files something like <code>screen</code> or <code>tmux</code> is recommended.

=== Convert Video to x264 ===

This script is useful if you have a device that's older and just plays x264-encoded files. You probably need <code>libx264</code> installed.

x264conv.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -acodec copy -vcodec h264 "$j"
done

This assumes that the file has x265 in the name. It writes a new file with x265 changed to x264, which is reencoded to x264. You'll have to go in and delete the x265 files if you don't want to save them. You should probably also check that the new x264 files play correctly.

=== Convert 10 Bit HEVC x265 to 8 Bit x264 ===

Some devices don't like 10 bit HEVC x265 files. This converts the files to x264.

10to8x264.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -map 0 -c:v libx264 -crf 18 -vf format=yuv420p -c:a copy "$j"
done

See this [https://superuser.com/questions/1380946/how-do-i-convert-10-bit-h-265-hevc-videos-to-h-264-without-quality-loss SuperUser page] for reference. As before, x265 is renamed to x264 for the new file. Run this in a directory and delete the old files if desired, after verifying the new ones play.
[[Category:Multimedia]]

FFMPEG Commands

2024-01-05T06:47:20Z

ToroidalCore:

Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another. Many of the scripts are working on the Bourne Shell on FreeBSD, since that's where I'm converting most of my media at the moment. They haven't been tested in Bash, but should work.

You should have some familiarity with FFMPEG and shell scripting. These are provided as a convenience; use at your own risk and be sure to make backups. I am not responsible for any loss of data as a result of using these!

== Video ==

Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal:

$ ffmpeg -i infile.avi outfile.mp4

Whereas something meant to run as a script will look like this:

#!/bin/sh

ffmpeg -i infile.avi outfile.mp4

The above should go in a text file and be made executable.

Unless otherwise noted, the scripts are meant to be run in a directory full of files you want to convert. You can put the script someplace like <code>~/bin</code>, change to the directory, and just run it. If you have a lot of files something like <code>screen</code> or <code>tmux</code> is recommended.

=== Convert Video to x264 ===

This script is useful if you have a device that's older and just plays x264-encoded files. You probably need <code>libx264</code> installed.

x264conv.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -acodec copy -vcodec h264 "$j"
done

This assumes that the file has x265 in the name. It writes a new file with x265 changed to x264, which is reencoded to x264. You'll have to go in and delete the x265 files if you don't want to save them. You should probably also check that the new x264 files play correctly.

=== Convert 10 Bit HEVC x265 to 8 Bit x264 ===

Some devices don't like 10 bit HEVC x265 files. This converts the files to x264.

10to8x264.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -map 0 -c:v libx264 -crf 18 -vf format=yuv420p -c:a copy "$j"
done

See this [https://superuser.com/questions/1380946/how-do-i-convert-10-bit-h-265-hevc-videos-to-h-264-without-quality-loss SuperUser page] As before, x265 is renamed to x264 for the new file. Run this in a directory and delete the old files if desired, after verifying the new ones play.
[[Category:Multimedia]]

Category:Multimedia

2024-01-05T06:43:56Z

ToroidalCore:

Articles about manipulating multimedia on Unixlike systems, mainly Linux. This includes sound and video for things like recording and composing music, editing video, visual effects, etc., as well as format conversion.

[[Category:UnixLike]]

Category:Multimedia

2024-01-05T06:43:23Z

ToroidalCore: Created page with "Articles about manipulating multimedia on Unixlike systems, mainly Linux. This includes sound and video for things like recording and composing music, editing video, visual effects, etc., as well as format conversion. Category:Unixlike"

FFMPEG Commands

2024-01-05T06:41:58Z

ToroidalCore:

Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another. Many of the scripts are working on the Bourne Shell on FreeBSD, since that's where I'm converting most of my media at the moment. They haven't been tested in Bash, but should work.

You should have some familiarity with FFMPEG and shell scripting. These are provided as a convenience; use at your own risk and be sure to make backups. I am not responsible for any loss of data as a result of using these!

== Video ==

Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal:

$ ffmpeg -i infile.avi outfile.mp4

Whereas something meant to run as a script will look like this:

#!/bin/sh

ffmpeg -i infile.avi outfile.mp4

The above should go in a text file and be made executable.

Unless otherwise noted, the scripts are meant to be run in a directory full of files you want to convert. You can put the script someplace like <code>~/bin</code>, change to the directory, and just run it. If you have a lot of files something like <code>screen</code> or <code>tmux</code> is recommended.

=== Convert Video to x264 ===

This script is useful if you have a device that's older and just plays x264-encoded files. You probably need <code>libx264</code> installed.

x264conv.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -acodec copy -vcodec h264 "$j"
done

This assumes that the file has x265 in the name. It writes a new file with x265 changed to x264, which is reencoded to x264. You'll have to go in and delete the x265 files if you don't want to save them. You should probably also check that the new x264 files play correctly.

=== Convert 10 Bit HEVC x265 to 8 Bit x264 ===

Some devices don't like 10 bit HEVC x265 files. This converts the files to x264.

10to8x264.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -map 0 -c:v libx264 -crf 18 -vf format=yuv420p -c:a copy "$j"
done

As before, x265 is renamed to x264 for the new file. Run this in a directory and delete the old files if desired, after verifying the new ones play.
[[Category:Multimedia]]

FFMPEG Commands

2024-01-05T06:41:21Z

ToroidalCore:

Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another. Many of the scripts are working on the Bourne Shell on FreeBSD, since that's where I'm converting most of my media at the moment. They haven't been tested in Bash, but should work.

You should have some familiarity with FFMPEG and shell scripting. These are provided as a convenience; use at your own risk and be sure to make backups. I am not responsible for any loss of data as a result of using these!

== Video ==

Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal:

$ ffmpeg -i infile.avi outfile.mp4

Whereas something meant to run as a script will look like this:

#!/bin/sh

ffmpeg -i infile.avi outfile.mp4

The above should go in a text file and be made executable.

Unless otherwise noted, the scripts are meant to be run in a directory full of files you want to convert. You can put the script someplace like <code>~/bin</code>, change to the directory, and just run it. If you have a lot of files something like <code>screen</code> or <code>tmux</code> is recommended.

=== Convert Video to x264 ===

This script is useful if you have a device that's older and just plays x264-encoded files. You probably need <code>libx264</code> installed.

x264conv.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -acodec copy -vcodec h264 "$j"
done

This assumes that the file has x265 in the name. It writes a new file with x265 changed to x264, which is reencoded to x264. You'll have to go in and delete the x265 files if you don't want to save them. You should probably also check that the new x264 files play correctly.

=== Convert 10 Bit HEVC x265 to 8 Bit x264 ===

Some devices don't like 10 bit HEVC x265 files. This converts the files to x264.

10to8x264.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -map 0 -c:v libx264 -crf 18 -vf format=yuv420p -c:a copy "$j"
done

As before, x265 is renamed to x264 for the new file. Run this in a directory and delete the old files if desired, after verifying the new ones play.
[[Category:Multimedia]]

FFMPEG Commands

2024-01-05T06:30:34Z

ToroidalCore: Created page with "Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another. == Video == Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal: $ ffmpeg -i infile.avi outfile.mp4 Whereas something meant to run as a script will look like this: #!/bin/sh ffmpeg -i infile.avi outfile.mp4 The above should go in a text file and be made..."

Here are some FFMPEG scripts I've come up with for various things, mostly converting media of one format to another.

== Video ==

Converting video from one format or container to another. Lines that look like this are meant to just be run as a single command at the terminal:

$ ffmpeg -i infile.avi outfile.mp4

Whereas something meant to run as a script will look like this:

#!/bin/sh

ffmpeg -i infile.avi outfile.mp4

The above should go in a text file and be made executable.

=== Convert Video to x264 ===

This script is useful if you have a device that's older and just plays x264-encoded files. You probably need <code>libx264</code> installed.

x264conv.sh
#!/bin/sh

for i in *.mp4 *.mkv
do
j=$(echo $i | sed 's/x265/x264/g')
ffmpeg -i "$i" -acodec copy -vcodec h264 "$j"
done

This assumes that the file has x265 in the name. It writes a new file with x265 changed to x264, which is reencoded to x264. You'll have to go in and delete the x265 files if you don't want to save them. You should probably also check that the new x264 files play correctly.
[[Category:Multimedia]]

Category:UnixLike

2024-01-05T05:58:19Z

ToroidalCore: Created page with "Unixlike systems are computer operating systems such as the myriad of GNU/Linux distributions, the BSDs, MacOS, Irix, etc. This category will mostly focus on computing with Linux and BSD systems."

Unixlike systems are computer operating systems such as the myriad of GNU/Linux distributions, the BSDs, MacOS, Irix, etc. This category will mostly focus on computing with Linux and BSD systems.

Category:Desktop Linux

2024-01-05T05:56:43Z

ToroidalCore:

Desktop-specific pages for GNU/Linux and other *nix systems (eg BSDs). Includes howtos, workflows, etc.

[[Category:UnixLike]]

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-22T03:29:46Z

ToroidalCore:

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net

SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 16 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

= 3. Configuring System Logins =

The above sections allow a user to get a Kerberos ticket and use it to retrieve information from LDAP. Now, we need to allow the system to do this so that a user can actually log in at the console or via a display manager.

=== Kerberos Authentication ===
First, we need to configure the system to check passwords against Kerberos. Edit <code>/etc/login.conf</code> and look for the same <code>default:\</code> block as in Section 1, and edit it to add the line <code>:auth=-krb5-or-pwd:\</code> third from the bottom. The whole block should now look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:auth=-krb5-or-pwd:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

=== LDAP Authorization ===
This allows the system to retrieve information from LDAP about users and groups. OpenBSD does not directly support doing this with LDAP, but it does support network information services (NIS), and provides a bridge called <code>ypldap</code> to interface with an LDAP server.

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-22T03:26:30Z

ToroidalCore:

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net

SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 16 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

= 3. Configuring System Logins =

First, we need to configure the system to check passwords against Kerberos. Edit <code>/etc/login.conf</code> and look for the same <code>default:\</code> block as in Section 1, and edit it to add the line <code>:auth=-krb5-or-pwd:\</code> third from the bottom. The whole block should now look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:auth=-krb5-or-pwd:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-22T03:25:34Z

ToroidalCore:

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net
ode
SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 16 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

= 3. Configuring System Logins =

First, we need to configure the system to check passwords against Kerberos. Edit <code>/etc/login.conf</code> and look for the same <code>default:\</code> block as in Section 1, and edit it to add the line <code>:auth=-krb5-or-pwd:\</code> third from the bottom. The whole block should now look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:auth=-krb5-or-pwd:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-22T03:25:05Z

ToroidalCore:

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net
ode
SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 16 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

== Configuring System Login ==

First, we need to configure the system to check passwords against Kerberos. Edit <code>/etc/login.conf</code> and look for the same <code>default:\</code> block as in Section 1, and edit it to add the line <code>:auth=-krb5-or-pwd:\</code> third from the bottom. The whole block should now look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:auth=-krb5-or-pwd:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-15T05:06:47Z

ToroidalCore: /* Testing the LDAP Client */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net
ode
SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 16 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-15T05:06:25Z

ToroidalCore: /* 2. LDAP Client */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter.

=== Configuring the LDAP Client ===

Edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net
ode
SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively. This not only points the LDAP client programs to your LDAP server by default, but it also tells them to use GSSAPI.

=== Testing the LDAP Client ===

Log in with a KRB/LDAP user. Get a Kerberos ticket using <code>kinit</code>, entering the user's password when prompted. Next, verify that ticket exists using <code>klist</code>. You should then be able to access the LDAP server, for instance using the <code>ldapwhoami</code> program. Here's an example of this exchange:

openbsd$ kinit
ben@EXAMPLE.NET's Password:
openbsd$ klist
Credentials cache: FILE:/tmp/krb5cc_10000
Principal: ben@EXAMPLE.NET

Issued Expires Principal
May 15 12:57:30 2023 May 17 12:57:30 2023 krbtgt/EXAMPLE.NET@EXAMPLE.NET
openbsd$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: ben@EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
dn:uid=ben,ou=users,dc=example,dc=net
openbsd$

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-15T04:57:18Z

ToroidalCore: /* Prerequisites */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
** Another client machine pointing toward the Kerberos/LDAP server for troubleshooting purposes is helpful.
* The LDAP server configured with an SSL server certificate, and the appropriate CA certificate installed on the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter. Next, edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net

SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-15T04:55:43Z

ToroidalCore: /* 2. LDAP Client */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
* The LDAP server configured with an SSL server certificate, and a client certificate for the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv openldap-client

Select the option for the package supporting GSSAPI and hit Enter. Next, edit <code>/etc/openldap/openldap.conf</code>. The uncommented lines should look something like this:

BASE dc=example,dc=net
URI ldap://krbldapsrv.example.net

SASL_MECH GSSAPI

Change <code>dc=example,dc=net</code> and <code>krbldapsrv.example.net</code> to reflect your LDAP server's DN and DNS name, respectively

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T04:23:32Z

ToroidalCore: /* 2. LDAP Client */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
* The LDAP server configured with an SSL server certificate, and a client certificate for the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

You probably have user-related information that you want to store centrally. This includes not only system-related things like user and group IDs, but also other user information such as email addresses, SSH keys, phone numbers, etc. LDAP can even be used to store things like photos, and with some scripting you have a lot of options. Some of what is stored in LDAP should be restricted, eg the user shouldn't be able to change their UID. On the other hand, they may need to edit something else, like their phone number. What they can and can't edit and how to set this up is outside the scope of this document.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). In order to use it, you must have set up Kerberos as in the previous section.

=== Install the LDAP Client ===

Install the LDAP client with GSSAPI support as follows:

openbsd# pkg_add -iv

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T04:16:42Z

ToroidalCore: /* 2. LDAP Client */

Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate against a network database (the key distribution center (KDC)), and LDAP lets you store information about things like users and groups and more. With one or more (hopefully more, for redundancy) Kerberos and LDAP servers, it should be possible to set up client hosts such that a user created on the server can log into the client host, without a local user account. (Local users can still be used if needed, eg as a backup or for system services.)

This is useful for a couple reasons. Obviously, being able to use the same password across different hosts is handy, as is single sign-on. However, keeping UIDs/GIDs in sync is nice as well, when it comes to things like removeable media and NFS shares - it ensures that <code>user</code> is always <code>user</code> on every host. Of course, you also have LDAP available, and all that entails. This makes it possible to store other information about a user (or group or host), depending on what you want to accomplish. You can, for instance, store SSH keys this way.

This guide describes setting up OpenBSD, specifically OpenBSD 7.3 to authenticate in this way. Note that due to Kerberos being removed from the OpenBSD base system, integration is not as tight as perhaps in other operating systems, such as Linux distributions or FreeBSD. Note also that while this authentication scheme is similar to that used for Microsoft's Active Directory, this guide is not specifically about integrating it with OpenBSD. If you are trying to do that, however, this may be helpful.

= Overview =

A client host in a Kerberos/LDAP environment will do a couple things. First, the user should be able to log in using the password on their Kerberos principal - ideally, if coming from another host in the Kerberos realm with an existing ticket, they wouldn't need a password. (At this time, this is not possible per this guide, see the Limitations section below.) At this point, they're authenticated as a normal user of the host, and have a UID/GID that the host knows about via LDAP. At the same time, the user should be able to acquire their own Kerberos ticket, to log onto other hosts.

To do this, there are three primary goals:

# Configure Kerberos on OpenBSD to point to a KDC, so a user can request and destroy a ticket.
# Set up LDAP for authorization, so users and the system can retrieve information such as UIDs and GIDs, and group membership.
# Configure BSD auth so that users can log in to the system with the password for their Kerberos principal.

== Prerequisites ==

In addition to an OpenBSD 7.3 host you want to actually set this up on, we will assume you have a few things available:

* A working Kerberos KDC and LDAP directory server you can make changes to, eg creating users and principals.
** An account/LDAP entry in the above directory server, with a host principal for the OpenBSD machine.
** A normal user account with an LDAP entry and Kerberos principal, that you want to be able to use to log into the OpenBSD machine.
* The LDAP server configured with an SSL server certificate, and a client certificate for the OpenBSD machine.
* An up-to-date OpenBSD system you want to set up as a client, with root access. I recommend having a local user set up as well. (Created during the install process, for instance.)

'''Note:''' This assumes you have knowledge about Kerberos and LDAP; setting them up is a subject of another guide. Knowledge of OpenBSD is of course helpful as well. :)

== Limitations ==

There are some things to be aware of in this configuration. OpenBSD removed Kerberos (the Heimdal package) from the base years ago, but you can still install it with pkg_add. System integration with Kerberos is not very strong, and presently I haven't been able to acquire a ticket automatically on log in - this is something I'm looking into. Additionally, OpenSSH is compiled without GSSAPI support, so by default you cannot log in to a the OpenBSD client from another machine using just a Kerberos principal.

In my setup, I use MIT Kerberos for the KDC. You can still get a ticket from a Heimdal client, but the protocols for administration (used by the <code>kadmin</code> command) are different between the two. This means that certain things, eg getting a host principal have to be done manually.

OpenBSD provides LDAP-based authorization (ie, info about the user such as their user and group, as opposed to authenticating them by their password) via the <code>ypldap</code> program. This does not support GSSAPI, meaning that communication to the LDAP server won't be encrypted. We get around this by using an SSL certificate.

= 1. Kerberos Client =

The first step is to configure the Kerberos client programs - a user on the OpenBSD machine should be able to get a ticket by running <code>kinit</code>. Install the following packages:

openbsd# pkg_add -iv heimdal heimdal-libs

You should now have the packages installed - check to make sure you have the appropriate directory:

openbsd# ls /usr/local/heimdal

That directory should exist and have folders in it. Next, to add it to the path, open <code>/etc/login.conf</code> in a text editor, and look for the default block (begins with <code>default:\</code>). Add <code>/usr/local/heimdal/bin</code> to the path, so that at this point the block should look like this:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin /usr/local/heimdal/bin:\
:umask=022:\
:datasize-max=1024M:\
:datasize-cur=1024M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

Next, to ensure that OpenBSD relinks the libraries on boot, add the following line to <code>/etc/rc.conf.local</code>:

shlib_dirs=/usr/local/heimdal/lib

At this point, a user should be able to log in and run the <code>kinit</code> - in other words, it's in their path.

= 2. LDAP Client =

Usually, on a Unix-like system, authorization information would be stored in the files <code>/etc/passwd</code> and <code>/etc/group</code>. In this case, we want to pull this information from our LDAP server. Depending on your setup, there may be other information stored in LDAP as well, such as email addresses or SSH keys. This means that there needs to be a way for the system itself to access the directory, as well as normal users through the LDAP command line clients.

This guide assumes you are authenticating the users connecting to the LDAP server. The command line client can do this using the user's Kerberos principal using the Generic Security Services Application Programming Interface (GSSAPI). For authorization, OpenBSD uses the <code>ypldap</code> daemon, which acts as a translation layer between Network Information Service (NIS) and an LDAP server. This does not support GSSAPI.

The first task will be to

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T04:09:25Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T03:59:07Z

ToroidalCore: /* Overview */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T03:57:44Z

ToroidalCore: /* Overview */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T03:57:17Z

ToroidalCore: /* Overview */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-12T03:54:38Z

ToroidalCore: /* Prerequisites */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-04T07:17:57Z

ToroidalCore: /* 1. Kerberos Client */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-04T07:16:47Z

ToroidalCore: /* 1. Kerberos Client */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-04T07:03:12Z

ToroidalCore: /* Limitations */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-04T07:01:01Z

ToroidalCore: /* 1. Kerberos Client */

Kerberos and LDAP Client on OpenBSD 7.3

2023-05-04T06:59:34Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-30T02:42:27Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-30T02:13:10Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-28T05:29:04Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-28T04:54:15Z

ToroidalCore:

Main Page

2023-04-28T04:42:28Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-14T21:05:36Z

ToroidalCore:

Kerberos and LDAP Client on OpenBSD 7.3

2023-04-14T20:48:44Z

ToroidalCore: Created page with "Kerberos and LDAP are often used to centralize authentication and authorization respectively on Unix-like systems. Kerberos allows users and applications to authenticate agai..."

Syncthing Server

2020-09-12T20:07:13Z

ToroidalCore:

[https://syncthing.net/ Syncthing] is a tool written in Go to keep files synchronised between computers. It's decentralized, meaning instead of syncing to a server, your computers can find each other on the network and sync amongst themselves. While I don't use it outside of my home network, it can run over the internet as well - it uses relay and discovery severs, and can even traverse NAT.

Prior to Syncthing, I used [https://nextcloud.com/ NextCloud], which runs on a web server. I used this to keep some directories on several computers in my home network synchronized. It worked, and I actually still have an install I point my phone too (although Syncthing has an Android app as well). However, sometimes it would be slow, particularly with a lot of small files. The server also stores all of its files in its own directory, and depends on a database (I have used both MariaDB and SQLite), as opposed to Syncthing which is just its own executable.

One advantage of the central model NextCloud uses is that if you only have one of the computers you're syncing online, it can still keep the copy of the server up to date. While Syncthing can deal with conflicts (by renaming the conflicting files), it's nice to not have to have both machines on for them to sync in all cases. (Although again, Syncthing can sync the two if only the two of them are online; NextCloud would still need to talk to its server.) I had already had a machine running with an external hard drive as kind of a stopgap NAS, so I looked into how to get Syncthing going on this as well.

== Syncthing on a Headless Server ==

Syncthing can run just fine on a headless machine, with a caveat - each user requires a running instance. (This is the case as far as I know, I don't know if a multiuser version is in the works at the moment.) Also, on my laptops and desktop, I start it with my desktop environment, whereas my server doesn't have a GUI installed. I'd like it to start up on boot, but running as my user.

I'm running this on Debian 10 on a single board computer (PC Engines Alix, an i386 board), but it should work on a Raspberry Pi as well. In fact, with a Pi 3 or 4, it would probably run better.

=== Configuring Syncthing ===

The first thing to do is to actually configure Syncthing. This is based on the [https://docs.syncthing.net/intro/getting-started.html Getting Started] page in the docs, which covers things pretty well. However, since this is a headless server, you can use SSH to forward the GUI to your local machine:

ssh -L 7000:localhost:8384 servername

That forwards the GUI, which is running on port 8384 on the server, to port 7000 on your local machine. I chose port 7000 since I was already running Syncthing on my local machine. When you log in just run <code>syncthing</code> at the command line to get it started. Then, in a web browser, just connect to <code>http://localhost:7000</code> on your machine. Reconfiguring Syncthing to listen to the whole network and not just on localhost is another option, but a little less secure. I recommend setting up a username and password for the GUI, even if you only have it listen on localhost.

If you have multiple users who want to sync on your server, they'll each need their own instance. In that case, change the GUI port each listens on so there are no conflicts.

Starting it for the first time gets the initial configuration going. Before configuring any shared folders I set it up to autostart (next section), otherwise you need to leave Syncthing running in your SSH session. After you start it and confirm you can connect, hit <code>Ctrl C</code> in the terminal to stop the server and move on.

=== Starting the Server ===

These instructions are from the [https://docs.syncthing.net/users/autostart.html#linux Syncthing documentation] for autostarting on Linux. Basically, I'm using a systemd unit file to start as a normal user. There should be one with syncthing when you installed it; I found it in <code>/usr/lib/systemd/user/</code>. Copy it to your home directory like this, where <code>user</code> is your username:

cp /usr/lib/systemd/user/syncthing.service /home/user/.config/systemd/user/

Next, as a normal user, run these commands to enable the service on boot and start it immediately:

systemctl enable syncthing@user.service
systemctl start syncthing@user.service

You can confirm that it's running by either using <code>ps</> or using <code>systemctl</code> like this:

systemctl --user status syncthing.service

At this point Syncthing should start as your user on boot. When this is configured, SSH in as above and set up folders to sync. In the case of the NAS, I chose to locate the synced folders on an external hard drive, and not my home directory (which is on a CF card). On my desktop and laptops, the synced folders are all in my home directory.

Syncthing Server

2020-09-12T20:00:08Z

ToroidalCore:

[https://syncthing.net/ Syncthing] is a tool written in Go to keep files synchronised between computers. It's decentralized, meaning instead of syncing to a server, your computers can find each other on the network and sync amongst themselves. While I don't use it outside of my home network, it can run over the internet as well - it uses relay and discovery severs, and can even traverse NAT.

Prior to Syncthing, I used [https://nextcloud.com/ NextCloud], which runs on a web server. I used this to keep some directories on several computers in my home network synchronized. It worked, and I actually still have an install I point my phone too (although Syncthing has an Android app as well). However, sometimes it would be slow, particularly with a lot of small files. The server also stores all of its files in its own directory, and depends on a database (I have used both MariaDB and SQLite), as opposed to Syncthing which is just its own executable.

One advantage of the central model NextCloud uses is that if you only have one of the computers you're syncing online, it can still keep the copy of the server up to date. While Syncthing can deal with conflicts (by renaming the conflicting files), it's nice to not have to have both machines on for them to sync in all cases. (Although again, Syncthing can sync the two if only the two of them are online; NextCloud would still need to talk to its server.) I had already had a machine running with an external hard drive as kind of a stopgap NAS, so I looked into how to get Syncthing going on this as well.

== Syncthing on a Headless Server ==

Syncthing can run just fine on a headless machine, with a caveat - each user requires a running instance. (This is the case as far as I know, I don't know if a multiuser version is in the works at the moment.) Also, on my laptops and desktop, I start it with my desktop environment, whereas my server doesn't have a GUI installed. I'd like it to start up on boot, but running as my user.

I'm running this on Debian 10 on a single board computer (PC Engines Alix, an i386 board), but it should work on a Raspberry Pi as well. In fact, with a Pi 3 or 4, it would probably run better.

=== Configuring Syncthing ===

The first thing to do is to actually configure Syncthing. This is based on the [https://docs.syncthing.net/intro/getting-started.html Getting Started] page in the docs, which covers things pretty well. However, since this is a headless server, you can use SSH to forward the GUI to your local machine:

ssh -L 7000:localhost:8384 servername

That forwards the GUI, which is running on port 8384 on the server, to port 7000 on your local machine. I chose port 7000 since I was already running Syncthing on my local machine. When you log in just run <code>syncthing</code> at the command line to get it started. Then, in a web browser, just connect to <code>http://localhost:7000</code> on your machine. Reconfiguring Syncthing to listen to the whole network and not just on localhost is another option, but a little less secure.

I configured the directories to sync to point to an external hard drive; on my laptops and desktop I just have the folders in my home directory. From then on, directories on your computers should sync as long as you allow them to be shared in the GUI; make sure the Folder IDs are the same.

=== Starting the Server ===

These instructions are from the [https://docs.syncthing.net/users/autostart.html#linux Syncthing documentation] for autostarting on Linux. Basically, I'm using a systemd unit file to start as a normal user. There should be one with syncthing when you installed it; I found it in <code>/usr/lib/systemd/user/</code>. Copy it to your home directory like this, where <code>user</code> is your username:

cp /usr/lib/systemd/user/syncthing.service /home/user/.config/systemd/user/

Next, as a normal user, run these commands to enable the service on boot and start it immediately:

systemctl enable syncthing@user.service
systemctl start syncthing@user.service

You can confirm that it's running by either using <code>ps</> or using <code>systemctl</code> like this:

systemctl --user status syncthing.service

Syncthing Server

2020-09-12T19:43:27Z

ToroidalCore:

[https://syncthing.net/ Syncthing] is a tool written in Go to keep files synchronised between computers. It's decentralized, meaning instead of syncing to a server, your computers can find each other on the network and sync amongst themselves. While I don't use it outside of my home network, it can run over the internet as well - it uses relay and discovery severs, and can even traverse NAT.

Prior to Syncthing, I used [https://nextcloud.com/ NextCloud], which runs on a web server. I used this to keep some directories on several computers in my home network synchronized. It worked, and I actually still have an install I point my phone too (although Syncthing has an Android app as well). However, sometimes it would be slow, particularly with a lot of small files. The server also stores all of its files in its own directory, and depends on a database (I have used both MariaDB and SQLite), as opposed to Syncthing which is just its own executable.

One advantage of the central model NextCloud uses is that if you only have one of the computers you're syncing online, it can still keep the copy of the server up to date. While Syncthing can deal with conflicts (by renaming the conflicting files), it's nice to not have to have both machines on for them to sync in all cases. (Although again, Syncthing can sync the two if only the two of them are online; NextCloud would still need to talk to its server.) I had already had a machine running with an external hard drive as kind of a stopgap NAS, so I looked into how to get Syncthing going on this as well.

== Syncthing on a Headless Server ==

Syncthing can run just fine on a headless machine, with a caveat - each user requires a running instance. (This is the case as far as I know, I don't know if a multiuser version is in the works at the moment.) Also, on my laptops and desktop, I start it with my desktop environment, whereas my server doesn't have a GUI installed. I'd like it to start up on boot, but running as my user.

These instructions are from the [https://docs.syncthing.net/users/autostart.html#linux Syncthing documentation] for autostarting on Linux. I'm running this on Debian 10 on a single board computer (PC Engines Alix, an i386 board), but it should work on a Raspberry Pi as well. In fact, with a Pi 3 or 4, it would probably run better.

The first thing to do is to actually configure Syncthing. This is based on the [https://docs.syncthing.net/intro/getting-started.html Getting Started] page in the docs, which covers things pretty well. However, since this is a headless server, you can use SSH to forward the GUI to your local machine:

ssh -L 7000:localhost:8384 servername

That forwards the GUI, which is running on port 8384 on the server, to port 7000 on your local machine. I chose port 7000 since I was already running Syncthing on my local machine. Then, in a web browser, just connect to <code>http://localhost:7000</code> on your machine.

I configured the directories to sync to point to an external hard drive; on my laptops and desktop I just have the folders in my home directory.

Basically, I'm using a systemd unit file to start as a normal user. There should be one with syncthing when you installed it; I found it in <code>/usr/lib/systemd/user/</code>. Copy it to your home directory like this, where <code>user</code> is your username:

cp /usr/lib/systemd/user/syncthing.service /home/user/.config/systemd/user/

Next, as a normal user, run these commands to enable the service on boot and start it immediately:

systemctl enable syncthing@user.service
systemctl start syncthing@user.service

You can confirm that it's running by either using <code>ps</> or using <code>systemctl</code> like this:

systemctl --user status syncthing.service

Syncthing Server

2020-09-12T19:36:37Z

ToroidalCore:

Syncthing Server

2020-09-11T03:02:58Z

ToroidalCore: Created page with "[https://syncthing.net/ Syncthing] is a tool written in Go to keep files synchronised between computers. It's decentralized, meaning instead of syncing to a server, your comp..."

[https://syncthing.net/ Syncthing] is a tool written in Go to keep files synchronised between computers. It's decentralized, meaning instead of syncing to a server, your computers can find each other on the network and sync amongst themselves. It can work over the internet as well, although I don't use it that way.

Prior to Syncthing, I used [https://nextcloud.com/ NextCloud], which runs on a web server. I used this to keep some directories on several computers in my home network synchronized. It worked, and I actually still have an install I point my phone too (although Syncthing has an Android app as well). However, sometimes it would be slow, particularly with a lot of small files. The server also stores all of its files in its own directory, and depends on a database (I have used both MariaDB and SQLite).

While I like the idea of not having to have a dedicated server in the sense of NextCloud, I do have a NAS I would like to keep the directories I sync on.

Main Page

2020-06-13T20:01:15Z

ToroidalCore:

Welcome to the Unixcat.net wiki. Here you will find different articles and pages that I don't feel fit into the [https://blog.unixcat.net blog] format.

=== Some Categories to Check Out ===

[[:Category:Desktop Linux]]

Not just GNU/Linux. Tips, tricks, notes, etc. on using *nix systems on the desktop.