npub19lagad90ncl2ryqvgctg84wal4mus8wznx950a0trhw85lnflucquphm4g (npub19la…hm4g) npub1cpmamsweqfv259w54mkpgvfzrwgt64tx2wnue5rgvnwx3tx68nssuxuycf (npub1cpm…uycf) I agree that setuid executables are really troublesome and that sudo is far from the best approach to root privileges on a host.
The SSH approach is interesting, but at the same time using encryption over a local unix socket feels like a bit of not really needed overhead. But to base it on the the authentication aspect sounds good. And the possibility to require a hardware token to do privileged operations is a really good idea.
I'm just wondering how hardware tokens will work on a remote host configured like this. That is, you ssh into a remote host and use the "ssh-based-sudo" ... can that be prepared to also make use of hardware tokens as well?
And how could the management of "ssh-based-sudo" access be centrally managed? On hosts enrolled in FreeIPA, you can define sudo policies centrally. How could this be made to work with FreeIPA? I suspect it would be some extension to sss_ssh_authorizedkeys, which could add the needed public keys lines with the additional restrictions. But at the same time, this can end up being quite a lot of data needed to be processed on more detailed restrictions.
🔗 David Sommerseth /
npub1pu…ew2fu
2024-01-09 10:47:17
in reply to nevent1q…x8pw
Author Public Key
npub1puft30cctn4uhy2gufu4ynaa7vfzqx3lj4hkg545usdggtv8e9psdew2fuSeen on
wss://relay.nostr.bandPublished at
2024-01-09 10:47:17Event JSON
{
"id": "298764f011e53e5c52514d132c5ad1e153c95c0903ecd24476fa74ad39836512",
"pubkey": "0f12b8bf185cebcb9148e279524fbdf312201a3f956f6452b4e41a842d87c943",
"created_at": 1704797237,
"kind": 1,
"tags": [
[
"p",
"2ffa8eb4af9e3ea1900c461683d5ddfd77c81dc2998b47f5eb1ddc7a7e69ff30",
"wss://relay.mostr.pub"
],
[
"p",
"c077ddc1d90258aa15d4aeec1431221b90bd556653a7ccd06864dc68acda3ce1",
"wss://relay.mostr.pub"
],
[
"p",
"1d95c32d9a9d95a54f98eb2eaa156f3d3a71dc49eca2c960b2b89962758f1cc0",
"wss://relay.mostr.pub"
],
[
"p",
"9882e5d2fce57afcf5768551235168e8f0ed3fe3785c61c328aefc838daae465",
"wss://relay.mostr.pub"
],
[
"e",
"2c4ff751b75e7c2395c015e3acf60c7453b1e283ec3284bb20776771e5b43130",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://infosec.exchange/users/dazo/statuses/111725591726849936",
"activitypub"
]
],
"content": "nostr:npub19lagad90ncl2ryqvgctg84wal4mus8wznx950a0trhw85lnflucquphm4g nostr:npub1cpmamsweqfv259w54mkpgvfzrwgt64tx2wnue5rgvnwx3tx68nssuxuycf I agree that setuid executables are really troublesome and that sudo is far from the best approach to root privileges on a host.\n\nThe SSH approach is interesting, but at the same time using encryption over a local unix socket feels like a bit of not really needed overhead. But to base it on the the authentication aspect sounds good. And the possibility to require a hardware token to do privileged operations is a really good idea.\n\nI'm just wondering how hardware tokens will work on a remote host configured like this. That is, you ssh into a remote host and use the \"ssh-based-sudo\" ... can that be prepared to also make use of hardware tokens as well?\n\nAnd how could the management of \"ssh-based-sudo\" access be centrally managed? On hosts enrolled in FreeIPA, you can define sudo policies centrally. How could this be made to work with FreeIPA? I suspect it would be some extension to sss_ssh_authorizedkeys, which could add the needed public keys lines with the additional restrictions. But at the same time, this can end up being quite a lot of data needed to be processed on more detailed restrictions.",
"sig": "d9f17601496d57a4f09b0425c3c0527a2ea2b77ffce5c59a94ab5efba80cc805338e4c0fd0b344ebd4ccc326d6861a281508d496f6e5edeaf54cf6c10e66cd26"
}