Use gotify as 2FA with messages extras
mStirner opened this issue · comments
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.
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)