Scribd
Upload
5 views

ssh-keys

The document discusses the security advantages of using SSH with cryptographic keys instead of passwords, highlighting the vulnerabilities associated with passwords. It outlines the process of generating a key pair, the importance of keeping the private key secure, and how to disable password authentication for enhanced security. Additionally, it introduces the SSH Agent for convenience and explains multi-hop authentication and agent forwarding for efficient access to multiple hosts.

Uploaded by

HamayunKahout
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views

ssh-keys

The document discusses the security advantages of using SSH with cryptographic keys instead of passwords, highlighting the vulnerabilities associated with passwords. It outlines the process of generating a key pair, the importance of keeping the private key secure, and how to disable password authentication for enhanced security. Additionally, it introduces the SSH Agent for convenience and explains multi-hop authentication and agent forwarding for efficient access to multiple hosts.

Uploaded by

HamayunKahout
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

SSH and keys

Network Startup Resource Center


www.nsrc.org

These materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International license
(http://creativecommons.org/licenses/by-nc/4.0/)
Passwords are bad!
●
A large proportion of security failures are due to
passwords
– Users choose poor passwords
– Users write them down or share them
– Passwords can be guessed or brute-forced
– Passwords can be sniffed or key-logged
– People hate forced password changes and
password complexity tests, and will work around
them
SSH and system administration
●
SSH gives you remote command-line access to
systems
●
Therefore a very attractive target for attackers
●
Traffic is encrypted, which at least makes it
hard to sniff passwords off the network
– Much better than telnet
●
But in addition, SSH allows you to use
cryptographic keys instead of passwords
Using crypto keys with SSH
1. Generate a Private/Public key pair
2. Copy the public key onto each of the systems
you want to be able to log into
– It goes into $HOME/.ssh/authorized_keys
3. Log in with ssh, using your private key to prove
your identity to the other system, instead of a
password
User authentication with keys

Connect

/home/xxx/.ssh/
Out User proves they possess authorized_keys

of
Private the matching private key
Public
Band
Public
Generating a key pair
●
This is a one-time operation
● For Windows/putty: use puttygen.exe
● For Linux and OSX: use ssh-keygen
●
There are three different key types currently: rsa,
ecdsa, ed25519
– ecdsa and ed25519 are newest and fastest, rsa is more
widely compatible
– If you need to use RSA, choose a key length of 2048 or
3072 bits (e.g. -t rsa -b 2048)
●
You get a private key and a related public key
OpenSSH public key looks like this
●
One very long line of text
ssh-rsa AAAAB3NzaC1..... you@yourmachine

Key type Key data Label


(identifier)

●
Safe for copy-paste (but beware line wrap)
●
puttygen has a different native format but can
also export the above format
Understand the difference!
●
Your private key is like the Crown Jewels
●
Your public key is like a photograph of the
Crown Jewels
●
Which of these would you be happy to send via
the postal service? :-)
●
Never give your private key to anyone else
●
Never send your private key via E-mail
– Should you need to transfer it, do so via a secure
channel like scp or sftp
Keeping your private key safe
●
Keep it on the machine where it was generated
– usually your laptop
– plus a secure backup, e.g. USB key in a safe
●
Protect it with a strong passphrase
●
The key is actually stored encrypted on your
hard disk; the passphrase decrypts it
●
So an attacker would need both to steal the key
file and know your passphrase
– "2-factor authentication": something you have, and
something you know
Disabling passwords over SSH
●
Once you have key authentication working, you
can disable fallback to password auth
# editor /etc/ssh/sshd_config

PasswordAuthentication no
ChallengeResponseAuthentication no

PermitRootLogin without-password
–- or --
PermitRootLogin no

# service ssh restart


Man-in-the-middle attacks
●
How do you know you did not actually connect
to someone else, who is decrypting your traffic
and re-encrypting it to the remote host?

xehlhxn j;ijf ure hq ;qfhhlqwcwiefxweix iw


ewioihbyugi’owef;glgu xfenowixfuewg2384
Host keys
●
Solution: the host you are connecting to, also
has its own key
●
The host proves its own identity to you each
time you connect
●
The first time you connect, you will be shown
the host's "fingerprint" (hash of public key)
– If you've ever used SSH, even with passwords, you
will have seen this prompt
●
Future connections will check that the same
host key is seen
Host key verification
●
If later there is a man-in-the-middle, on
connection your ssh client will see the MITM's
key instead of the host's key
●
It won't match, you will get an error and the
connection is dropped
●
Questions:
– What happens if you reinstall the host's OS?
– What effect might this have on your users?
– How are you going to deal with it?
Questions?
●
Now do the exercise: SSH with public key
authentication
SSH Agent
●
Having to enter your passphrase every time you
log in is tedious
●
However there is a simple solution to this: the
SSH Agent
●
Once you have decrypted your private key once
with your passphrase, the Agent keeps the
decrypted key in RAM
●
Subsequent logins don't prompt you at all
●
This makes SSH + keys very convenient!
Installing SSH agent
● For Windows/putty: download pageant.exe
– Start it
– Select your private key file
– Enter your passphrase
●
OSX: already has it
●
Linux with Unity/Gnome/KDE: already has it
Multi-hop authentication
●
Sometimes it is necessary to ssh into host X,
and then ssh from host X to host Y
– e.g. due to network ACLs
– or because host Y is on a private IP address
– or because you are running some sysadmin tool on
host X which needs to log in to host Y

ssh ssh

host X host Y
Agent forwarding
●
You may be tempted to copy your private key
from your laptop to host X, but DON'T!
●
There is a better way: turn on Agent Forwarding
when you connect to host X
●
Host Y will try to authenticate from host X, and
host X will relay the request back to the origin
ssh ssh

Private
Summary
●
SSH + key is very secure
– Disable password authentication to get max benefit
●
SSH + key + agent is very convenient
– Type passphrase just once at start of day
– No need to type passwords each time you login
– No need to regularly change passwords across
many hosts
– Agent forwarding permits multi-hop logins
●
You need to deploy this!
Questions?
●
Now do the exercise: SSH with agent

You might also like