Use gotify as 2FA with messages extras

[mStirner]

Have you read the documentation?

• Yes, but it does not include related information regarding my question.
• Yes, but the steps described in the documentation do not work on my machine.
• Yes, but I am having difficulty understanding it and wants clarification.

You are setting up gotify in

• Docker
• Linux native platform
• Windows native platform

I had the idea to use gotify as a second factory for SSH logins.
Already use it to notify me on login/logouts.

I thought about sending a notification with a message extra action click action to "Allow SSH connection".

The notification script is very simple:

#!/bin/sh

# Installation: https://github.com/mStirner/linux-administration-docs?tab=readme-ov-file#notify-on-ssh-loginlogout-via-gotify

message="Something happend via ssh" 
timestamp=$(date +"%d.%m.%Y - %k:%M")

# logout happend
if [ "$PAM_TYPE" == "close_session" ]; then
        message="Logout: $PAM_USER from $PAM_RHOST"
fi

# login happend
if [ "$PAM_TYPE" == "open_session" ]; then
	message="Login: $PAM_USER from $PAM_RHOST"
fi

# do api request to gotfiy server
curl "http://example.com/message?token=xxxx" -F "title=SSH Session" -F "message=$message - $timestamp" -F "priority=5"

# allways exit sucessfully
exit 0;

Is it somehow possible to let the curl command wait and check the http response body for something like "accepted" / "denied" based on gotify action?

Example:

curl -X POST "http://example.com/message/..." -H "content-type: application/json" -d "<json below>" | grep -q "accepted" || exit 1;

{
  "message": "...",
  "title": "...",
  "extras": {
    "client::notification": {
      "click": [{
      	"title": "Accept", 
      	"body:": "accepted" 
      },{
      	"title": "Deny", 
      	"body": "deny" 
      }]
    }
  }
}

In the example there should be 2 buttons displayed under the notification, which are labeled as "Accept" & "Deny".
A click on "accept" would return for the curl command as body "accepted" and deny, "deny".

I know that a post to /messages do not wait for any notification to be shown or user interaction and need some changes which would probably break other clients. But a option could be that if a "extras.client::notification[] " is present in the body, no http response is send till the users does a interaction. Otherwise proceed with message publishing/body response as until now.

Note: I dont eve know if its possible to define more than one action/buttons on a (android) notification.

This was just something that came in my mind while playing around.
Would love to discuss this further.

[jmattheis]

Similar #482. This could be implemented on the user side after #494 is implemented, I don't want to natively support this see reasoning in #482 (comment)