Good idea on the Linux approach. I do that also to minimize attack surface.
On your latter point, whether you are using Lobstr solely to access only the Decaf wallet or have multiple accounts set up on Lobstr, that's not the point I was making. I was referring to your sentence as follows:
Then you input your public Decaf Stellar wallet address and also the private key for that address.
[emphasis added to the original]
You had to input the private key of the Decaf wallet onto the software interface manually for Lobstr to allow Lobstr to access that Decaf wallet, which as you say, is just giving two interfaces access to the same wallet. It's similar to how you can set up two hardware wallets to access the same set of addresses. I get why that is super convenient, and I do that myself with separate hardware wallets. But it does create an attack surface if entering private keys onto any device that is regularly connected to the internet with an operating system and which is not designed to mange private keys securely (like a separate hardware wallets). My bet is that the vast majority of people who might follow that approach are not even using Linux and are often using Windows or, more likely, a mobile phone. That was the point of my caution, as I think most people are far more exposed as to attack surface than what you have described.
Lobstr is a hot wallet that is exposed constantly to internet connections. If for some reason you have to "recover" a hot wallet, best practice is to set up a totally new account and set apart the private keys, and then recover the old account with the manual reentry of the private keys and transfer funds immediately into the new account from the recovered account, with the reason being that you generally never want to have long-term funds in any address for which a private key was manually entered into any interface other than a secure offline manager, like a hardware wallet. Thus, if I had to "recover" my Lobstr address, that is what I would do, and then I would never use the old one again.
What I was describing is that there is a way on Stellar that actually can give signing authority to another address on a wallet like Lobstr in a secure way that would allow the Lobstr interface to send and sign transactions on another wallet, like the Decaf wallet, without ever having to compromise the private key of the Decaf wallet or the Lobstr wallet, for example. This allows two separate addresses (i.e., two sets of private keys) to control a single address, but it does it in a way that never exposes private keys manually. But the problem is that the Decaf interface has to be sophisticated enough to allow interaction with the base protocol and set the proper commands to designate a second address to sign for it and issue commands. If it did allow that (and I don't know if it does, because I can't really use it for anything with the KYC fail), then you could authorize a separate account on Lobstr to interact on behalf of the Decaf wallet without ever exposing a private key through manual entry. With this approach, you would just set up a Lobstr account like usual (not a "recovery" of any existing account), securely save the private seed phrase generated, and then give signing authority to the Lobstr address, thus allowing Lobstr to see and transact on behalf of the Decaf address.
But even Lobstr would have to have a way to know that this was a delegation account, and even that is lacking in the software at present for Lobstr. In contrast, with Xaman (the Lobstr-like equivalent on the XRPL), those devs put in a feature that allows you to import a
public address into the Xaman app which you designate as an account for which the Xaman account has signing authority (which was delegated on the other address), and then you have the convenience of using the Xaman app to transact and sign for that other address.
Even that carries risks, because now you have to be sure that this mobile access point is kept secure, but at least that approach never had to manually input any private key on any surface connected regularly to the internet.