Message-ID: <15686721.477.1711659338855.JavaMail.serveradmin@t01app> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_476_18116119.1711659338852" ------=_Part_476_18116119.1711659338852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html 1.2 SSH RSA Key Based Authentication

1.2 SSH RSA Key Based Authentication

This article is in draft. The tone of the article does not fall in line = with the rest of the site. The examples are not yet made clear.

This also needs a followup article about how to use keys across multiple= systems and moving keys across systems.

=20 =20

Introduction

If your system is available through ssh on the Internet key based authen= tication must be used.

Even with preventative software such as fail2ban we have observed honeyp= ot system being compromised within 3 days of being set up.

For the choice of keys to use, RSA is often selected over DSA because it= has a stronger key length of 2048 and 4096. DSA can only be 1024.

It is unlikely you will run into issues if the versions of OpenSSH are d= ifferent from client and server. However, just in case, you might want to d= etermine the version of Open SSH installed,

=20
ssh -V =
# Determine SSH client version
OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009

sshd -v #Determine SSH Server version (ignore the error message)
sshd: illegal option -- v
OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-f config_file]
            [-g login_grace_time] [-h host_key_file] [-k key_gen_time]
            [-o option] [-p port] [-u len]
=20

As long as the major number (the first digit) is close you should have n= o issues.

Installing SSH<= /h1>

This installs the SSH server and client,

=20
sudo ap=
t-get install ssh
=20

At this point we have installed ssh, and it is time to create the keys f= or the users who require SSH access.

Note if you find that connecting via SSH is slow you might want to disable DNS l= ookup.

Generate Public and Private Keys on Client Machine

In principle, the generation of the Public and Private keys are done by = user themselves on their own machine. This is because even the Unix Adminis= trator should not have the user's private key.

Scratching your head on why keys should be generated by users? Think pas= swords. Any enterprise grade environment will ask you to d= efine your own password. Your password is then hashed and = never revealed to the Administrator. In the case where an Administrator set= s your initial password, the password will be "one time" where the system w= ill prompt you to set a new password upon successful authentication.

There are many variations of keys you can generate but currently industr= y standard is below,

Encryption Key Type =3D RSA
Key Length =3D 2048 

With a Unix based system, this can be accomplished with the command line= (below). Windows does not have a native way of doing this, but most Window= s ssh client programs will provide a means of key generation.

Windows Client<= /h2>

If you are on a Windows machine, make sure to store your private key on = a protected location. Usually this would be your Windows desktop or home di= rectory.

Putty is one of the most popular Windows SSH Clients and your keys can b= e setup using puttyGen. However, Putty also has not been updated in years a= nd I've found the generated keys to be problematic (for example will not wo= rk on my Mac). Instead, I recommend Bi= tVise SSH Client Tunnelier for the key generation.

For console work, I still use Putty (actually Kitty) for normal con= sole work, but still keep BitVise for its superior interface for file uploa= ds and port tunnelling.

Unix Client

On Ubuntu it's super easy and your generated private key also work with = Windows SSH clients.

ssh-keygen without parameters generates 2048 RSA public and private keys= ,


=20
ssh-key=
gen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/tinpham/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/tinpham/.ssh/id_rsa.
Your public key has been saved in /Users/tinpham/.ssh/id_rsa.pub.
The key fingerprint is:
c7:6c:3e:87:4a:09:90:ef:6d:a9:88:f8:f0:89:d2:13 tinpham@Tin-Phams-iMac.loca=
l
The key's randomart image is:
+--[ RSA 2048]----+
|        . oo.    |
|         s ..  . |
|          ...++ .|
|       T . +.=3D...|
|        F o + *. |
|         + o + . |
|          C .    |
|         . +     |
|                 |
+-----------------+
=20

On a Unix system file permissions should automatically be set to protect= your key files from other accounts.

Storing= Your Private Key

You private key is to never be shared. It's the equivalent of giving awa= y your password.

Windows Clien= t

If you are on a Windows machine, make sure to store your private key on = a protected location. Be default, usually the safest place is your Windows = desktop or home directory.

Unix Client

If you used the commands provides, your keys will be generated in your p= rotected home folder with further restrictions placed on your directory and= files.

Place = Public Key on Server

Ubuntu Shortcu= t

If you happen to using a Linux client and your Linux server still allows= username password authentication, there is a shortcut to getting everythin= g up and running on the server,

=20
ssh-cop=
y-id username@remotehost
=20

It accomplishes in one command,

(Roderick you should fill this in)

Manually Copy Over Public Key to the Target Server

Transfe= r Over Public Key

Since I happen to be using Mac OS X I do this manually,

=20
scp .ss=
h/id_rsa.pub bhitch@krypton.com:~
=20

Setup .ssh= Directory

Log into the server using your existing authentication = method.

First check in your home folder that you have a .ssh directory and an au= thorized_keys file. The folder and file are generated if you had ever run t= he ssh client command,

=20
ls -al =
# which will show hidden directories
ls -al .ssh # given the .ssh directory exists
=20

If the directory did not exist, no problem, we can create ourselves,

=20
mkdir ~=
/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
=20

Add the Public key added to the authorized_keys file,

=20
cd ~/.s=
sh
cat ~/id_rsa.pub >> authorized_keys # appends the contents of the you=
r public key to the authorized_keys file

cd ~
rm id_rsa.pub # no need to keep this file around
=20

Here is how everything should look in terms of permissions,

=20
ls -al
drwx------ 2 tin.pham staff 4096 Jan 23 19:35 .
drwxr-xr-x 5 tin.pham staff 4096 Jan 15 20:41 ..
-rw------- 1 tin.pham staff  410 Jan 15 20:41 authorized_keys
-rw------- 1 tin.pham staff 1671 Jan 23 19:35 id_rsa 
=20

If you have been using SSH before, you might also see a file called know= n_hosts (will link and explain to this later).

TroubleShoot and Test Key Based Authentication

In the very first attempt, I like to trouble-shoot with a Unix or Linux = command line client using the -v verbose option. Here's what a proper conne= ction looks like coming form my Mac to the bonsaiframework,

=20
=20 Working ssh with verbose command.=20  Expand source=20 =20
=20
=20
ssh -v www.bonsaiframework.com
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/tin.pham/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to www.bonsaiframework.com [52.184.187.123] port 22.
debug1: Connection established.
debug1: identity file /Users/tin.pham/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tin.pham/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 =
Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x040000=
00
debug1: Authenticating to www.bonsaiframework.com:22 as 'tin.pham'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: &=
lt;implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: &=
lt;implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:8MQQ0Cd0AG3WEQdOhnOalK0=
z7XmGW6PE6s+1sa7Gb0Y
debug1: Host 'www.bonsaiframework.com' is known and matches the ECDSA host =
key.
debug1: Found key in /Users/tin.pham/.ssh/known_hosts:20
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=3D<rsa-sha2-256,rsa-sha2-512=
>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tin.pham/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 277
debug1: Authentication succeeded (publickey).
Authenticated to www.bonsaiframework.com ([52.184.187.123]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_rep=
ly 0
=20
=20

The key values to notice are the loading of the proper key files, that R= SA is being used and the "offering" of the key completes successfully. You = should not need to type in your account password if your keys are working.<= /p>

Disable Password Authentication

Just Enabling Key Based Authentication is not enough to secure your syst= em. If you do not have a key, you will still be prompted for a password whi= ch will still work. The final step is to disable password authentication al= together.

Modify the sshd_config file to disable password authentication,

=20
# Since=
 this is a critical file, back it up first.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.2011-02-12.v0.0.tinpham_a=
bout_to_disable_password_auth.bck
# Load the file in your favourite editor.
sudo vi /etc/ssh/sshd_config
=20

We can modify sshd_config quickly using sed,

=20
sudo se=
d -i 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/s=
shd_config
=20

Changes the following,

=20
# Chang=
e to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
=20

Uncomment and change yes to no. It should look like this,

=20
# Chang=
e to no to disable tunnelled clear text passwords
PasswordAuthentication no
=20

Finally restart ssh for the change to take effect,

=20
sudo se=
rvice ssh restart
=20

In older versions of Ubuntu (to determine) where Upstart is not availabl= e use,

=20
sudo /e=
tc/init.d/ssh reload
 * Reloading OpenBSD Secure Shell server's configuration sshd
   ...done.
=20

Now go to another machine other than the server and try to authenticate = using ssh,

=20
ssh tph=
am@lemonbistro.com
Permission denied (publickey).
=20

The Permission denied indicates that password authentic= ation is now disabled.

Reusing Public Keys Across Machines

You can actually reuse public keys across machines. With this approach, = you only need to keep track of one private key per user. Of course, this al= so means if your private key is compromised all your systems are accessible= with the one key.

Key Compromise<= /h1>
  • ... revoking keys
  • ... strategies for centralizing key management and then also pitfalls
  • ... is it possible to force password protected private keys

Resources

http://www.ibm.com/developerworks/librar= y/l-keyc.html - pretty good article, I think I can improve it, shorter,= clearly show when running on client or server.

http://serverfault.co= m/questions/40071/ssh-keypair-generation-rsa-or-dsa - talks about key l= ength.

https://help.ubuntu.com/10.10/= serverguide/C/openssh-server.html - Ubuntu version of docs.

http://www.howtoforge.com/ssh_key_based_l= ogins_putty - instructions on using Putty, found the Auto-login tip use= ful.

http://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ss= h-private-keys-on-one-client - how to use multiple ssh keys using the c= onfig file.

http://www.f= reetutorialssubmit.com/convert-ssh-private-key-with-putty-keygen/1400 -= sometimes you need to use different formats of keys.


------=_Part_476_18116119.1711659338852--