What a coincidence!! I found the same tutorial but was pulling my hair until I found your post. I just have one problem, I'm on EC2 amazon, so I have a PEM file (key pair)You can also harden your SSH login even further by using Multiple Authentication Methods!
I just added this to my Masternode myself.
If you already have Keypair Auth you just need to:
1. follow this guide (posted on the Bitcointalkthread by hartvercoint) http://www.howtogeek.com/121650/how...gle-authenticators-two-factor-authentication/
2. Add this to your sshd_config: "AuthenticationMethods publickey,keyboard-interactive"
3. restart ssh service (keep a ssh connection open to prevent locking yourself out while you test this!!!)
If you now try to login via SSH you will need:
3. 2FA code
1. login to your server via sshWhat a coincidence!! I found the same tutorial but was pulling my hair until I found your post. I just have one problem, I'm on EC2 amazon, so I have a PEM file (key pair)
I... ssh -i xxx.PEM [email protected]... google authenticator ask for token, then asks for password. I dont have one! I thought that was the whole idea behind encrypted PEM files. I dont get it. I have no clue what to put in password, tried the PEM file, but obviously its not that.
I'm currently not running it as a non-privileged user, but have locked all ports except 9999 (sshport is restricted only to my ip). Key Pair + Pass + Time-based OTP is needed for ssh login. Bruteforce protection for the TOTP is enabled. fail2ban installed.All software has its flaws and we are always applying security updates to fix them, however, this is after the event of someone having something bad happen to them and reporting it and a security update being issued.
We need to prepare for the event of darkcoind having a security flaw and someone gaining access to the server as the user running darkcoind. To prepare for this possibility we need to:
At the moment each Master Node has a red flag and banner shouting out to the Net 1,000 coins here come and get them if you can. Making it compulsory to remotely start the Master Node is a MUST so that Master Node operators are protected as much as possible. I can see from many posts that not many are remotely starting the Master Node and just risking it. This is bad for the darkcoin image if too many people lose coins through poor configurations.
- Run darkcoind as a non-privileged user
- Disable sudo access for this non-privileged user
- Remotely start the Master Node from another server so that coins are never on the MN server
- Ability to detect and alert that the server has been compromised
- Harden the server
Sounds like a good config, but if darkcoind was compromised then the attacker would have root access and own your server. Your coins should be safe as long as you have not introduced pathways to your other server with the coins on. By this I mean you have not put your other server in /etc/hosts and not done any silly ssh keys to jump from one box to the other.I'm currently not running it as a non-privileged user, but have locked all ports except 9999 (sshport is restricted only to my ip). Key Pair + Pass + Time-based OTP is needed for ssh login. Bruteforce protection for the TOTP is enabled. fail2ban installed.
AND most importantly I would say, my 1000 DRK are not on this server but on another one.
So I guess I'm good to go, but will look into the non-privileged user just to make sure