Read the script in execution order and the cost turns up somewhere the write-up does not flag. It checks PAM_TYPE and returns immediately unless the value is open_session [9]. It sources the config, applies the rate limit, calls hostname, then calls curl against ifconfig.me with a three-second cap to learn its own public address [6]. Only after that does it fork the detached subshell that posts to Telegram under a five-second cap [5]. The post is right that the send never blocks a login, but the address lookup is a separate synchronous call sitting on the same path [15]. On a host with clean egress that costs milliseconds. On a host where outbound 443 is filtered or DNS is limping, every successful login waits up to three seconds before the message is even queued, and scripted rsync sessions wait with it [15]. It asks a website on the internet what its own IP address is, once per login [6].
The exit-0 rule is the part I would copy verbatim. The stated justification is that a non-zero exit from a pam_exec hook can be configured to block the login it was installed to report [4]. The words doing the work there are "can be configured." Whether a broken script locks you out of your own server depends on the control flag on the pam_exec line in /etc/pam.d/sshd, and that line is the one piece of the build the walkthrough renders as a diagram rather than printing as a listing [3]. So the discipline is right for the author's reason, and also for one he does not give: a reader cannot size the blast radius of the hook from the article alone.
The rate limiter is careful work. Keyed on user plus source host with a sixty-second window [7], it turns the three or four sessions that VS Code Remote SSH or rsync open per connection into a single message, suppressing three of every four [8][16]. It also drops a timestamp file per distinct user and source address into /var/lib/ssh-notify [7]. That directory grows, but only on success, because open_session never fires for an attempt that failed [1]. The brute-force traffic that starts arriving within minutes of a fresh VPS going public [13] costs this rig nothing, since none of it reaches the hook [17]. That is the correct coverage choice. It also means the tool answers exactly one question, which is whether anybody got in, and reports who and from where with a UTC timestamp [14].
For the behaviour to transfer to your fleet, two things have to hold: the host can reach api.telegram.org at the moment of login, and somebody is watching for expected traffic that stops. The script fails silently under all circumstances by design [4], and the listing carries no retry and no queue [5], so a dropped send looks exactly like a quiet night. Treat it as a doorbell. In my context that is a fair trade on a box I already watch other ways, and the whole adoption bill is two files and one PAM line [11][12][2]. If it is the only thing watching the box, the silence is the part to engineer around.
