Securing SSH
-
@IRJ said in Securing SSH:
@Dashrender said in Securing SSH:
Is it normal to use the same key over many servers at a user level? or a different key for each server for each person?
Yes. You would use the same key per user (not sever) , but have some form of MFA.
You would store your key in an encrypted drive like druva or one drive
Just to make sure I get this right.
I create my pub/private keys, put my own private key in an encrypted drive, then copy my public key to serverA, serverB, serverC, etc., correct?
(its one of those foggy brained days)
-
@Dashrender said in Securing SSH:
Is it normal to use the same key over many servers at a user level? or a different key for each server for each person?
Yes, that is standard.
-
@pmoncho said in Securing SSH:
@IRJ said in Securing SSH:
@Dashrender said in Securing SSH:
Is it normal to use the same key over many servers at a user level? or a different key for each server for each person?
Yes. You would use the same key per user (not sever) , but have some form of MFA.
You would store your key in an encrypted drive like druva or one drive
Just to make sure I get this right.
I create my pub/private keys, put my own private key in an encrypted drive, then copy my public key to serverA, serverB, serverC, etc., correct?
(its one of those foggy brained days)
Correct. We put our public keys into scripts to deploy and have them listed on a wiki, too. So that it is easy to add users to a system.
-
@scottalanmiller said in Securing SSH:
@pmoncho said in Securing SSH:
@IRJ said in Securing SSH:
@Dashrender said in Securing SSH:
Is it normal to use the same key over many servers at a user level? or a different key for each server for each person?
Yes. You would use the same key per user (not sever) , but have some form of MFA.
You would store your key in an encrypted drive like druva or one drive
Just to make sure I get this right.
I create my pub/private keys, put my own private key in an encrypted drive, then copy my public key to serverA, serverB, serverC, etc., correct?
(its one of those foggy brained days)
Correct. We put our public keys into scripts to deploy and have them listed on a wiki, too. So that it is easy to add users to a system.
Interesting. I am starting to add more linux systems so I will look into doing the same.
-
Here's some ideas for you. https://mangolassi.it/topic/10391/fairly-hardened-jump-box
-
I used duo for MFA with push on my phone and yubikeys.
-
@stacksofplates said in Securing SSH:
Here's some ideas for you. https://mangolassi.it/topic/10391/fairly-hardened-jump-box
I would also look at CIS benchmarks when creating your images.
-
@hobbit666 said in Securing SSH:
I think the common things i've seen so far are -
PasswordLess access i.e. Public/Private Keys
Timeouts
Disallow root logon
Harden Firewall
White-list IP's that can access.That is a good quick list, but we can add use vpn and/bastion host for access to that list.
-
@IRJ said in Securing SSH:
You would store your key in an encrypted drive like druva or one drive
Umm WUT.
You don't store your key anywhere. Because that makes it useless.
Are you reusing the same key on different user devices?
-
@scottalanmiller said in Securing SSH:
@Dashrender said in Securing SSH:
Is it normal to use the same key over many servers at a user level? or a different key for each server for each person?
Yes, that is standard.
More clearly, each user generates a keypair on their device and then the pub part of that pair is copied to each server.
I have a laptop and a desktop. I have generated a keypair on each device and have those public keys copied to the servers I connect to.
-
@stacksofplates said in Securing SSH:
Here's some ideas for you. https://mangolassi.it/topic/10391/fairly-hardened-jump-box
And this one
https://www.mangolassi.it/topic/19858/ssh-hardening -
@JaredBusch said in Securing SSH:
@IRJ said in Securing SSH:
You would store your key in an encrypted drive like druva or one drive
Umm WUT.
You don't store your key anywhere. Because that makes it useless.
Are you reusing the same key on different user devices?
Little lost here.
If I use putty on windows to create my key pair and I put my public key on my linux machine (authorized_keys file).
So what do you do with the private key from the key pair?
-
@pmoncho said in Securing SSH:
@JaredBusch said in Securing SSH:
@IRJ said in Securing SSH:
You would store your key in an encrypted drive like druva or one drive
Umm WUT.
You don't store your key anywhere. Because that makes it useless.
Are you reusing the same key on different user devices?
Little lost here.
If I use putty on windows to create my key pair and I put my public key on my linux machine (authorized_keys file).
So what do you do with the private key from the key pair?
Nothing. it is only ever on your one machine.
Also WTF with putty? SSH is native to even Windows now.
-
@JaredBusch said in Securing SSH:
@pmoncho said in Securing SSH:
@JaredBusch said in Securing SSH:
@IRJ said in Securing SSH:
You would store your key in an encrypted drive like druva or one drive
Umm WUT.
You don't store your key anywhere. Because that makes it useless.
Are you reusing the same key on different user devices?
Little lost here.
If I use putty on windows to create my key pair and I put my public key on my linux machine (authorized_keys file).
So what do you do with the private key from the key pair?
Nothing. it is only ever on your one machine.
Ok. Got it.
Now if I have my work machine and home laptop (used for remote work), should I create multiple keys, one for each machine or just copy and use the same private key?
Also WTF with putty? SSH is native to even Windows now.
It is what I initially used so it was the first thing that popped in my head.
-
Open a terminal session and run
ssh-keygen
to properly generate a valid keypair.
I use the ed25519 algorithm because it creates a short public key and the comments are usefulssh-keygen -o -a 100 -t ed25519 -C "[email protected] Desktop"
-
@JaredBusch said in Securing SSH:
@IRJ said in Securing SSH:
You would store your key in an encrypted drive like druva or one drive
Umm WUT.
You don't store your key anywhere. Because that makes it useless.
Are you reusing the same key on different user devices?
Not your personal key of course. A break glass key for root access. You get a root key for all cloud servers that should be different from your user key. That was the key I was talking about storing.
-
On my Fedora laptop and desktop this is what I do.
# Generating a new ED25519 key with a password ssh-keygen -o -a 100 -t ed25519 -C "$(whoami)@$(hostname)_$(date +%Y-%m-%d_%H:%M:%S%z)" -f ~/.ssh/id_ed25519
# Generating a new ED25519 key without a password ssh-keygen -o -a 100 -t ed25519 -N '' -C "$(whoami)@$(hostname)_$(date +%Y-%m-%d_%H:%M:%S%z)" -f ~/.ssh/id_ed25519
When I use a key that requires a password, I use ssh-agent so I don't have to enter my password.
# Run ssh-agent and then use ssh-add eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
-
@IRJ said in Securing SSH:
@hobbit666 said in Securing SSH:
I think the common things i've seen so far are -
PasswordLess access i.e. Public/Private Keys
Timeouts
Disallow root logon
Harden Firewall
White-list IP's that can access.That is a good quick list, but we can add use vpn and/bastion host for access to that list.
Yeah this wasn't for a cloud deployment so it was the perimeter device. I incorrectly called it a jump box for some reason. It's really a bastion host.
-
@black3dynamite said in Securing SSH:
On my Fedora laptop and desktop this is what I do.
# Generating a new ED25519 key with a password ssh-keygen -o -a 100 -t ed25519 -C "$(whoami)@$(hostname)_$(date +%Y-%m-%d_%H:%M:%S%z)" -f ~/.ssh/id_ed25519
May be a stupid question but, should we use passwords?
-
@pmoncho said in Securing SSH:
@black3dynamite said in Securing SSH:
On my Fedora laptop and desktop this is what I do.
# Generating a new ED25519 key with a password ssh-keygen -o -a 100 -t ed25519 -C "$(whoami)@$(hostname)_$(date +%Y-%m-%d_%H:%M:%S%z)" -f ~/.ssh/id_ed25519
May be a stupid question but, should we use passwords?
You can, but you'd have to enter that password every time to connect using your SSH key.