Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


(Serious) key management
New on LowEndTalk? Please Register and read our Community Rules.

(Serious) key management

I need some help... I have been the care(less) user who still uses passwords to login to the idling vps to check on their health... i would like to switch to ssh keys... but my worry is I'll end up screwing up badly sooner or later and will loose access to my service and data....

  • how to safeguard the private keys...
  • how many keys should I create for each idling service
  • should each idling service has its unique set of keys
  • let's say a key is compromised, then how to remediate the same
  • just like passwords are forced to be reset periodically how can I rotate or reset keys
  • is there some service which is recommended for key management... if reasonably priced I do not mind paying for it...
  • any vaults or similar?
  • I understand it's always best practice to have a passphrase for a key... but what happens when we need to automate some tasks where key is needed?
  • should root account have a key... Guess not...
  • apart from root how many user acc ou units does one need to create assuming it's only a one person team here...

Thanks in advance!

Thanked by 1imok
«1

Comments

  • yoursunnyyoursunny Member, IPv6 Advocate

    A truly idle service shall not have a key.

    ping 64.112.125.58
    That's my server, but I lost access to both Virtualizor and SSH, and I'm ineligible for opening tickets.
    It will idle until expiration.


    A working server should have your public key installed in a user account, but not the root account.
    The user account shall have sudo privilege so that you can run commands as root when needed.

    Ideally, you have a unique private key on each client device (laptop or phone), then install the corresponding public key to the servers.
    You don't need a separate private key for each server.
    Don't copy your laptop's private key to the server.

    Thanked by 2Ouji plumberg
  • @yoursunny said:
    A truly idle service shall not have a key.

    ping 64.112.125.58
    That's my server, but I lost access to both Virtualizor and SSH, and I'm ineligible for opening tickets.
    It will idle until expiration.


    A working server should have your public key installed in a user account, but not the root account.
    The user account shall have sudo privilege so that you can run commands as root when needed.

    Ideally, you have a unique private key on each client device (laptop or phone), then install the corresponding public key to the servers.
    You don't need a separate private key for each server.
    Don't copy your laptop's private key to the server.

    This makes sense... a new key per client device.... this makes sense.

    What should be the ideal bit length of a key pair? What algo it should use? I use windows as my primary system so need something which can generate a secure key

  • Just a few more ideas, I usually I do the following:

    Thanked by 2skorous plumberg
  • @TerokNor said:
    Just a few more ideas, I usually I do the following:

    Thanks for sharing...

    In windows, do you know how to setup an encrypted partition? What about mobiles (android mainly)?

    Interesting point about passwords and MFA... I think it may work even for keys... depending on use case...

    Unfortunately I do not have static ip... but i am considering an idling service to be used as a jump server...

    Fail2ban is nice. I plan to implement it sooner

    Thnx again

  • I use Krypton for MFA and Tailscale as a mesh VPN and I only allow ssh connections from the Tailscale interface

    Thanked by 1plumberg
  • TerokNorTerokNor Member
    edited November 2021

    @plumberg said: In windows, do you know how to setup an encrypted partition? What about mobiles (android mainly)?

    No unfortunately I dont have experience with windows/android on this.

    @plumberg said: Interesting point about passwords and MFA... I think it may work even for keys... depending on use case...

    Well, 2fa is in fact a form of private key (something you have), so theoretically I wouldn't bother to enable 2fa on private key. But it depends on the use case. For example you cannot use 2fa when you want to run automated remote scripts

    Thanked by 1plumberg
  • @Ouji said:
    I use Krypton for MFA and Tailscale as a mesh VPN and I only allow ssh connections from the Tailscale interface

    interesting, will check! Thanks for sharing

  • @plumberg said:

    @TerokNor said:
    Just a few more ideas, I usually I do the following:

    Thanks for sharing...

    In windows, do you know how to setup an encrypted partition? What about mobiles (android mainly)?

    For Windows, Google BitLocker.

    For Android, I'm pretty sure filesystem is encrypted by default and protected by password and/or finger/face.

    For Windows, I'd also suggest Remote Desktop Manager from Devolutions.

  • jmgcaguiclajmgcaguicla Member
    edited November 2021

    @plumberg said:

    how many keys should I create for each idling service

    should each idling service has its unique set of keys

    Idling services do not need keys, turn them off or better yet cancel them

    let's say a key is compromised, then how to remediate the same

    just like passwords are forced to be reset periodically how can I rotate or reset keys

    Welcome to the wonderful world of SSH certificates. If you're familiar with X.509 certificates you'd already know what benefits this brings to the table.

    Thanked by 2Kassem plumberg
  • @TimboJones said:

    @plumberg said:

    @TerokNor said:
    Just a few more ideas, I usually I do the following:

    Thanks for sharing...

    In windows, do you know how to setup an encrypted partition? What about mobiles (android mainly)?

    For Windows, Google BitLocker.

    For Android, I'm pretty sure filesystem is encrypted by default and protected by password and/or finger/face.

    For Windows, I'd also suggest Remote Desktop Manager from Devolutions.

    Will check Rdm!

  • @jmgcaguicla said:

    @plumberg said:

    how many keys should I create for each idling service

    should each idling service has its unique set of keys

    Idling services do not need keys, turn them off or better yet cancel them

    let's say a key is compromised, then how to remediate the same

    just like passwords are forced to be reset periodically how can I rotate or reset keys

    Welcome to the wonderful world of SSH certificates. If you're familiar with X.509 certificates you'd already know what benefits this brings to the table.

    Wow. Thank you. X509 certificate looks interesting!

  • vimalwarevimalware Member
    edited December 2021

    One key pair per user (client) device.

    Use passphrase protection on each private key, if the client/OS's helper/keystore allows it.

    You need a minimum of 2 private keys (aka devices) permitted per configured remote ssh host. If one device gets stoled/compromised, comment out the compromised public key in authorized_keys.

    Simple. I'd use 3 devices for extra paranoia.

    Just typing it out because i didn't have time to read what others have already posted. Busy day ahead. Good luck. Good decisions.

    Thanked by 2plumberg ehab
  • @vimalware said:
    One key pair per user (client) device.

    Use passphrase protection on each private key, if the client/OS's helper/keystore allows it.

    You need a minimum of 2 private keys (aka devices) permitted per configured remote ssh host. If one device gets stoled/compromised, comment out the compromised public key in authorized_keys.

    Simple. I'd use 3 devices for extra paranoia.

    Just typing it out because i didn't have time to read what others have already posted. Busy day ahead. Good luck. Good decisions.

    Thanks for sharing your thoughts! Definitely n+2 keys and devices needed

  • The "disable password login" mantra has been repeated so many times only because many people are unable to set strong, not reused passwords.
    The "disable root account" mantra is for reducing the consequences of weak passwords, because that account can not be renamed.

    There is nothing wrong with using passwords. If done well, using password is probably more secure, because you are not a bot, and you will have much less room for error than with key management.

    @plumberg said: I'll end up screwing up badly sooner or later

    You have already forgot to include the backup. Your first point should've really been "how to backup and safeguard the private keys..."

    Thanked by 1plumberg
  • @ceter said:
    The "disable root account" mantra is for reducing the consequences of weak passwords, because that account can not be renamed.

    That is one very good reason, though the main reason is to stop one account having such wide control at all. Best practise is to avoid using the root account directly where practical, and you also then protect against some local attacks as well as brute-force/common-auth based remote logins.

    @plumberg said:
    to login to the idling vps to check on their health...

    For instance this task could be done by a locked-down user that has access via sudo only to the specific things it needs to perform these health checks. Though see my ramblings below about if SSH is the best tool for this job at all.

    @plumberg said:
    how many keys should I create for each idling service

    If a service is truly idling, perhaps turn it off. Then you don't need to worry at all, not even about the admin of making sure it is patched up-to-date.

    @plumberg said:
    should each idling service has its unique set of keys

    For a monitoring process, if the account has appropriately limited access, then maybe the same identity on each, but that identity only used by a specific account on the monitoring service.

    For accounts with wider access then multiple identities might be more the way to go.

    @plumberg said:
    let's say a key is compromised, then how to remediate the same

    Why multiple identifies might be a waste of effort: if the monitoring service has access to all the keys, then one getting compromised probably means they all do at the same time so having multiple offers no extra protection.

    In fact a safer approach is for the servers to call in to a central place to log status data instead of that central place being able to call out to all of them. Then even if your state checks require a lot of root access, you aren't giving root control to an external login at all as a local process collects the data and submits it, and submitting it doesn't require any privs at all. You just need an extra check centrally to report if any services haven't reported in recently.

    To be even safer, don't even use SSH for the reporting: have a HTTPS API that can only accept the logging/state information instead of offering shell access at all. In fact, that would work the other way around too: present the state information via an API call instead of gathering it via a SSH login.

    @plumberg said:
    just like passwords are forced to be reset periodically how can I rotate or reset keys

    You can't force private keys to be refreshed, though the “best practise” of limiting what each account can do (whether authenticated by key or by password) protects against any given key being compromised giving full access anywhere. I think the choice of nomenclature is significant here: the key pair is referred to as an identity not an account or other.

    In DayJob one of the reasons we give for strongly recommending keys to our clients is that it gives them control of passphrase cycling policies which is a win for both of us: them because they can enforce their own policy rather than fitting in with ours and for us because we don't have the responsibility for that at all.

    @plumberg said:
    what happens when we need to automate some tasks where key is needed?

    Then you have to have a passphraseless key, or some sort of agent arrangement but that ultimately needs to be auth-less for automation anyway. Again, protection here comes from limiting what each account the identity can access can do, and not that a passphraseless private key is no less safe from local attacks than the task having a stored password (it is more safe in other ways because keys are usually more securely generated - relatively large and properly random).

    @plumberg said:
    should root account have a key... Guess not...

    Usually very much not.

    Thanked by 1plumberg
  • @MeAtExampleDotCom said:

    @ceter said:
    The "disable root account" mantra is for reducing the consequences of weak passwords, because that account can not be renamed.

    That is one very good reason, though the main reason is to stop one account having such wide control at all. Best practise is to avoid using the root account directly where practical, and you also then protect against some local attacks as well as brute-force/common-auth based remote logins.

    @plumberg said:
    to login to the idling vps to check on their health...

    For instance this task could be done by a locked-down user that has access via sudo only to the specific things it needs to perform these health checks. Though see my ramblings below about if SSH is the best tool for this job at all.

    @plumberg said:
    how many keys should I create for each idling service

    If a service is truly idling, perhaps turn it off. Then you don't need to worry at all, not even about the admin of making sure it is patched up-to-date.

    @plumberg said:
    should each idling service has its unique set of keys

    For a monitoring process, if the account has appropriately limited access, then maybe the same identity on each, but that identity only used by a specific account on the monitoring service.

    For accounts with wider access then multiple identities might be more the way to go.

    @plumberg said:
    let's say a key is compromised, then how to remediate the same

    Why multiple identifies might be a waste of effort: if the monitoring service has access to all the keys, then one getting compromised probably means they all do at the same time so having multiple offers no extra protection.

    In fact a safer approach is for the servers to call in to a central place to log status data instead of that central place being able to call out to all of them. Then even if your state checks require a lot of root access, you aren't giving root control to an external login at all as a local process collects the data and submits it, and submitting it doesn't require any privs at all. You just need an extra check centrally to report if any services haven't reported in recently.

    To be even safer, don't even use SSH for the reporting: have a HTTPS API that can only accept the logging/state information instead of offering shell access at all. In fact, that would work the other way around too: present the state information via an API call instead of gathering it via a SSH login.

    @plumberg said:
    just like passwords are forced to be reset periodically how can I rotate or reset keys

    You can't force private keys to be refreshed, though the “best practise” of limiting what each account can do (whether authenticated by key or by password) protects against any given key being compromised giving full access anywhere. I think the choice of nomenclature is significant here: the key pair is referred to as an identity not an account or other.

    In DayJob one of the reasons we give for strongly recommending keys to our clients is that it gives them control of passphrase cycling policies which is a win for both of us: them because they can enforce their own policy rather than fitting in with ours and for us because we don't have the responsibility for that at all.

    @plumberg said:
    what happens when we need to automate some tasks where key is needed?

    Then you have to have a passphraseless key, or some sort of agent arrangement but that ultimately needs to be auth-less for automation anyway. Again, protection here comes from limiting what each account the identity can access can do, and not that a passphraseless private key is no less safe from local attacks than the task having a stored password (it is more safe in other ways because keys are usually more securely generated - relatively large and properly random).

    @plumberg said:
    should root account have a key... Guess not...

    Usually very much not.

    Thanks so much! Lot to digest!

  • @ceter said:
    The "disable password login" mantra has been repeated so many times only because many people are unable to set strong, not reused passwords.
    The "disable root account" mantra is for reducing the consequences of weak passwords, because that account can not be renamed.

    There is nothing wrong with using passwords. If done well, using password is probably more secure, because you are not a bot, and you will have much less room for error than with key management.

    @plumberg said: I'll end up screwing up badly sooner or later

    You have already forgot to include the backup. Your first point should've really been "how to backup and safeguard the private keys..."

    Yup. Backup and safeguard keys... that's important and makes sense. Any suggestions? Thanks

  • @plumberg said:

    @ceter said:

    @plumberg said: I'll end up screwing up badly sooner or later

    You have already forgot to include the backup. Your first point should've really been "how to backup and safeguard the private keys..."

    Yup. Backup and safeguard keys... that's important and makes sense. Any suggestions?

    Be careful where you backup your keys if a targetted attack is in your threat surface (which it increasingly is for everyone as a successful automated exploit might trigger a follow-up human response to finish the job). My most important couple of passwords/passphrases are not backed up anywhere near other data, nor stored unprotected. They are on a USB key (Yubikey devices in my case, there are a few other good options on the market, and a poor-mans version is just a normal USB drive would do for static tokens (at least it is air-gapped, only accessible when actually plugged in so safe from remote snooping unless you leave it on the computer's clipboard)). Backup options away from your normal stores could include printing them (directly or as a QR code) and storing in a physically hidden location (my desk draw at work for instance, someone wanting access to some things would have to both steal my home machine and break into my employer).

    Of course all this adds admin. How much hassle you can “afford” to spend time on depends on the worth of the data/services you are protecting and the threat level, so what might be suitable for me could be either overkill or far too lax for you.

    And as with all backups: make sure you know what your likely disaster scenarios are and that what you've arranged allows a recovery path (and that it is tested - the worst time to test a backup is when you need to restore something from it!).

    Thanked by 1plumberg
  • @MeAtExampleDotCom said:

    @plumberg said:

    @ceter said:

    @plumberg said: I'll end up screwing up badly sooner or later

    You have already forgot to include the backup. Your first point should've really been "how to backup and safeguard the private keys..."

    Yup. Backup and safeguard keys... that's important and makes sense. Any suggestions?

    Be careful where you backup your keys if a targetted attack is in your threat surface (which it increasingly is for everyone as a successful automated exploit might trigger a follow-up human response to finish the job). My most important couple of passwords/passphrases are not backed up anywhere near other data, nor stored unprotected. They are on a USB key (Yubikey devices in my case, there are a few other good options on the market, and a poor-mans version is just a normal USB drive would do for static tokens (at least it is air-gapped, only accessible when actually plugged in so safe from remote snooping unless you leave it on the computer's clipboard)). Backup options away from your normal stores could include printing them (directly or as a QR code) and storing in a physically hidden location (my desk draw at work for instance, someone wanting access to some things would have to both steal my home machine and break into my employer).

    Of course all this adds admin. How much hassle you can “afford” to spend time on depends on the worth of the data/services you are protecting and the threat level, so what might be suitable for me could be either overkill or far too lax for you.

    And as with all backups: make sure you know what your likely disaster scenarios are and that what you've arranged allows a recovery path (and that it is tested - the worst time to test a backup is when you need to restore something from it!).

    Hmm. I have a couple yubikey and google titan keys somewhere. Now is a good time to get them to use!

    Thanks

  • @plumberg said:
    Hmm. I have a couple yubikey and google titan keys somewhere. Now is a good time to get them to use!

    Also while considering plug-in tokens, give a thought to 2FA for at least your most vital stuff. Though again, make sure you have a recovery plan (like the local physical copy of keys idea for example) should your chosen 2FA loop fail at a time of critical need.

    Thanked by 1plumberg
  • jsgjsg Member, Resident Benchmarker
    edited December 2021

    Rather than throwing smart "expert" advice at you or joining the discussion I'll try to answer your questions, as well as ones behind those.

    Like Q: Are passphrases unacceptable and one MUST use keys?
    A: No, proper passphrases are fine but keys meet reasonable security standards.
    E.g. SSH keys never are as bad as (too) short and bad pass phrases, hence keys if only for peace of mind.

    @plumberg said:

    • how to safeguard the private keys...

    How to safeguard pass phrases? Both are pieces of data that (a) should stay under your control, (b) should never be lost.
    The answer to (a) is that 'ssh-keygen' (at key pair creation) by default asks for a (not obligatory, can be empty) pass phrase. And the answer to (b) is "make backups", preferably multiple ones stored on multiple devices.

    • how many keys should I create for each idling service

    One

    • should each idling service has its unique set of keys

    Depends on perspective. Some will say that each and every one "must" have, other will say "nuh, one key pair for all of them is fine". I personally am in between. Idlers and systems that have little importance (e.g. name server slave number 4) and hold no confidential or sensitive data can share one key, while others definitely should have each their own key pair.

    • let's say a key is compromised, then how to remediate the same

    (a) largely theory, unless your OpSec is abominable, (b) depends. Just keep your private keys safe and always have backups and you are extremely unlikely to find yourself in that situation in the first place.

    • just like passwords are forced to be reset periodically how can I rotate or reset keys

    By creating new ones and replacing the old ones. But usually, except maybe for key pairs used for multiple machines (like the idlers), there is no need to reset the keys.

    • is there some service which is recommended for key management... if reasonably priced I do not mind paying for it...

    Are you insane? Private keys are exactly that, private. Using a 3rd party service is about as smart as sending your wife/girl friend drunk and nude into a bad neighbourhood.
    You can and should however use a backup service and store your keys properly encrypted there.

    • I understand it's always best practice to have a passphrase for a key... but what happens when we need to automate some tasks where key is needed?

    Then you put that private key, probably an extra one created for that purpose, into your .ssh/config (private one) and into .ssh/authorized_keys of the remote system. For automated/unattended job the key might have no pass-phrase but be sure to use it with a remote user account with only the rights necessary for the task.

    • should root account have a key... Guess not...

    Highly likely not.

    (Windows related stuff: me not qualified to /advisehelp there)

    Thanked by 1plumberg
  • @vimalware said: Simple. I'd use 3 devices for extra paranoia.

    Why not, but private keys can be backed up...

    @MeAtExampleDotCom said: If a service is truly idling, perhaps turn it off. Then you don't need to worry at all, not even about the admin of making sure it is patched up-to-date.

    This. Switched of is the best idle: you don't waste RAM/electricity, and your VPS is as secure as it can be. You are free to enable unattended-upgrades so that it upgrades when/if it starts...

  • @jsg said:
    Rather than throwing smart "expert" advice at you or joining the discussion I'll try to answer your questions, as well as ones behind those.

    • should each idling service has its unique set of keys

    Depends on perspective. Some will say that each and every one "must" have, other will say "nuh, one key pair for all of them is fine". I personally am in between. Idlers and systems that have little importance (e.g. name server slave number 4) and hold no confidential or sensitive data can share one key, while others definitely should have each their own key pair.

    I know it's said, but have never really understood the logic of this. It comes down only to the security of your local private keys, the services regardless of importance have nothing compromisable. Unless you plan to treat some private keys less securely than others, which would seem perverse, then one key pair for all services seems ideal and easier to manage for key expiry/rotation. Indeed if you move to the next level of security and use hardware devices for your private key (OpenPGP cards, Yubikeys) having multiple keys becomes impractical.

    • should root account have a key... Guess not...

    Highly likely not.

    Sometimes people need remote root access (e.g. rsync or ansible) as well as logging into regular accounts. Nothing to stop you using the same key pair for both accounts, especially if you're using a hardware security device, though obviously you need the horrendously named 'PermitRootLogin without-password'

    Thanked by 1plumberg
  • jsgjsg Member, Resident Benchmarker

    @cochon said:

    @jsg said:
    Rather than throwing smart "expert" advice at you or joining the discussion I'll try to answer your questions, as well as ones behind those.

    • should each idling service has its unique set of keys

    Depends on perspective. Some will say that each and every one "must" have, other will say "nuh, one key pair for all of them is fine". I personally am in between. Idlers and systems that have little importance (e.g. name server slave number 4) and hold no confidential or sensitive data can share one key, while others definitely should have each their own key pair.

    I know it's said, but have never really understood the logic of this. It comes down only to the security of your local private keys, the services regardless of importance have nothing compromisable. Unless you plan to treat some private keys less securely than others, which would seem perverse, then one key pair for all services seems ideal and easier to manage for key expiry/rotation. Indeed if you move to the next level of security and use hardware devices for your private key (OpenPGP cards, Yubikeys) having multiple keys becomes impractical.

    One point is that, assumed some day the keys most used can be cracked in say 100 core-years and 1 already has been cracked the difference between 1 key or 10 keys for 10 VMs highly likely is that you can save at least the other 9 VMs.

    There are of course more points one could discuss, like e.g. small keys (e.g. RSA512) for idlers and stronger (than average) keys (e.g. RSA4k) for sensitive VMs, but I took this thread to be more of a "keep it simple for beginners" thread.
    (Yes, I know that RSA512 is ridiculous but hey it's still much better than 'password123').

    • should root account have a key... Guess not...

    Highly likely not.

    Sometimes people need remote root access (e.g. rsync or ansible) as well as logging into regular accounts. Nothing to stop you using the same key pair for both accounts, especially if you're using a hardware security device, though obviously you need the horrendously named 'PermitRootLogin without-password'

    No, well named, in fact not horrifiying enough IMO.

    As for "sometimes people need ..." ... sure, and there are virtually always decent solutions available, at least far more sensible than allowing root login.

    Thanked by 1plumberg
  • ezethezeth Member, Host Rep
    edited December 2021

    @yoursunny said:
    A truly idle service shall not have a key.

    ping 64.112.125.58
    That's my server, but I lost access to both Virtualizor and SSH, and I'm ineligible for opening tickets.
    It will idle until expiration.


    A working server should have your public key installed in a user account, but not the root account.
    The user account shall have sudo privilege so that you can run commands as root when needed.

    Ideally, you have a unique private key on each client device (laptop or phone), then install the corresponding public key to the servers.
    You don't need a separate private key for each server.
    Don't copy your laptop's private key to the server.

    Oh well. I restocked some 30 VMs after processing cancellation requests from recent data ideas fiber cut. You can get another one if you want https://my.boomer.host/order.php?step=1&productGroup=4 Ironically these are better deals than Black Friday

    Btw all boomer.host customers will soon get their own fully whitelabled (no powered by..) uptime monitoring logins. It will also have multi language support so you can have your status page in your local language.

    though you need to pay if you want sms notifications lol but I'm sure it can be something like 1 usd a month. Why not take this chance to get a boomer vm that you can access together with a uptime monitoring software so you can keep track of your inaccessible boomer vm

  • Daniel15Daniel15 Member
    edited December 2021

    @plumberg said: should root account have a key... Guess not...

    The only time I do this is when transferring data between servers (some of which may be only readable for root), and I did that with a temporary key that I deleted afterwards.

    I understand it's always best practice to have a passphrase for a key... but what happens when we need to automate some tasks where key is needed?

    If you're running a script manually that then does some automation (eg. using Ansible), one option is to add it to your SSH agent. eval $(ssh-agent) then ssh-add ~/.ssh/id_ed25519 and enter the password, and it won't prompt you again during the session. I use a passworded SSH key for Ansible, but load it into the agent so I don't have to keep entering the password over and over.

    @plumberg said: What algo it should use?

    As far as I know, Ed25519 is still the best.

    Thanked by 2plumberg vimalware
  • @ceter said: There is nothing wrong with using passwords. If done well, using password is probably more secure

    How can a password be more secure, if a password-protected SSH key is essentially a password and a key? 🤔

  • @ezeth said: Oh well. I restocked some 30 VMs after processing cancellation requests from recent data ideas fiber cut. You can get another one if you want https://my.boomer.host/order.php?step=1&productGroup=4 Ironically these are better deals than Black Friday

    Boomer is unavailable. What location are these packages? Is there a LG?

  • ezethezeth Member, Host Rep

    @Ouji said:

    @ezeth said: Oh well. I restocked some 30 VMs after processing cancellation requests from recent data ideas fiber cut. You can get another one if you want https://my.boomer.host/order.php?step=1&productGroup=4 Ironically these are better deals than Black Friday

    Boomer is unavailable. What location are these packages? Is there a LG?

    USA Texas

    Thanked by 1Ouji
  • @ezeth said: USA Texas

    Nice. These are actually very good looking prices. Any chance boomer will be back on stock?

Sign In or Register to comment.