Securing SSH
-
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-keygento 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_ed25519When 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_ed25519May 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_ed25519May 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.
-
@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_ed25519May be a stupid question but, should we use passwords?
It's for protecting your private key.
-
@DustinB3403 said in Securing SSH:
@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_ed25519May 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.
Unless use ssh-agent.
-
@black3dynamite said in Securing SSH:
@DustinB3403 said in Securing SSH:
@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_ed25519May 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.
Unless use ssh-agent.
How is ssh-agent storing your keypair password? It would have to be plain-text, wouldn't it? Which kind of defeats the point of adding a password to the keypair if the password for the pair is in plain-text. . .
-
@DustinB3403 said in Securing SSH:
@black3dynamite said in Securing SSH:
@DustinB3403 said in Securing SSH:
@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_ed25519May 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.
Unless use ssh-agent.
How is ssh-agent storing your keypair password? It would have to be plain-text, wouldn't it? Which kind of defeats the point of adding a password to the keypair if the password for the pair is in plain-text. . .
It's not stored in plain-text.
