mm_answer_keyallowed: publickey authentication test: ED25519 key is not allowed

Debian 12.
After a long time I’ve installed Debian 12 in a VM again.
I used ssh-copy-id to copy the key files to the VM.
When I tried logging in, I still had to supply my password.
What was going on?

Well, I’ll spare you the mindfuck and give you the solution.

It wasn’t the encoding, it weren’t the permissions, it was…
My .ssh/id_ed25519 and .pub were dated older, from 2021, than a newer key I generated for github, id_ed25519_github.
So, I don’t know why all of a sudden this is happeneing, ssh-copy-id decides to take the most newly generated key in the .ssh directory, which is the github one and ignore all other keys.

In order to fix this

because ssh-copy-id since, who knows when, takes only 1 ed25519 key and it’s always the latest one.

I usually always did the copy/pasting by hand, until I stumbled on some smarty-pants blog-post which suggested ssh-copy-id. I’m going to fall back to doing it manually again.

Mastodon ohne Gendern und mit 5000 statt 500 Zeichenbeschränkung

Mich stört bei Mastodon diese Cancel Culture und auch und vor allem das Gendern.
Das ist einfach eine schreckliche, unleserliche, politisch motivierte Verunstaltung der Sprache.

Deshalb habe ich per Hand die Sprachdateien geändert.

Außerdem gefällt mir nicht das man nur auf 500 Zeichen beschränkt sein soll bei der Länge der Posts.
Darum habe ich die Länge auf 5000 Zeichen geändert.

Das ganze gibts als Patch für die Version 4.2.7, aber sie sollte auch für Nachfolgeversionen funktionieren, zum runterladen.
Oben auf “Raw” klicken und “speichern als”.

Anwenden kann man ihm mit

Funtioniert noch immer mit Version 4.2.19

sshd sftp chroot jail howto

Problem description:

You would like to jail users to their home directories and not allow shell access, only sftp access.

Solution:

SFTP chroot jail

1. Create a system group. Here I call it sftponly.

2. edit the sshd_config file, usually residing in /etc/ssh/sshd_config
(in weird opensuse it’s in /usr/etc/sshd/ )
and append (it needs to be appended at the end):

and restart sshd.

PasswordAuthentication No means, users can only login with their ssh key, no passwords allowed.

3. create the skeleton structure for each new user

we create .ssh htdocs and log dirs.

4. add a user and chown its home directory to root:root and set the login shell to nologin.
Also add this user to the sftponly group and set proper access octals.
On Rocky 9 it’s in /usr/sbin/nologin .

5. add the client’s ed25519 public key to /home/username/.ssh/authorized_keys

Where AAAA… is replaced by the actual public key from the client’s machine.
Check your /home/username/.ssh/id_ed25519.pub file or that of your customer/friend/etc.

And that’s it.
Yes, that’s all there is to it.

The user will be able to transfer files via SFTP in the sub directories you created in step 3, but not write or create directories in the root directory.

Today I learned about NATS, microservice API and security

Actual security, as in identity, is still a 3rd party thing, aka you still need a OIDC IDP (or oauth2 in the broadest sense or similar).
All NATS security does is validate that the credentials you pass the a client are valid and enforce limits, if configured.

The microservice API was necessary, since simple request/reply structure was lacking errors, logging and statistics.
micro.Request actually has a convenience req.RespondJSON() function.

A small example?

So right now I have, ent for the database stuff and nats over websocket for the service requests.
But I’m having big issues with NATS Jetstream.
The ws client is blocking, despite callbacks and async.

The micro package also has a long way to go.
Regular HTTP has middleware, micro doesn’t seem to have it, maybe I’m missing something. OTOH I could just pass the request to a next function, but it’s not very elegant.