As long as you’re using a standard modern cipher, it shouldn’t matter at all how related (or unrelated) the key and message are. As a practical matter, you should perhaps be hashing the inputs to the key, both to produce a fixed-length key regardless of the number and length of inputs, and (if you use a slow hash, rather than a fast one) to make attempting to brute-force the key much more computationally expensive. That would make the key and the message superficially quite different (though this isn’t why you would do it, exactly). In theory you don’t need the same data as duplicated inputs to generating the “password”, but it doesn’t hurt.
The actual security of this scheme, in terms of ability to prevent something that is not one of your terminals from logging in, or prevent terminal A’s user/owner from logging in as terminal B, is questionable. You haven’t provided enough info about that to be sure, but what you have provided is concerning (there’s very little entropy in MAC addresses or in serial numbers). But that’s not what you asked about.