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
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.
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,
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.
This installs the SSH server and client,
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.
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.
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.
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= ,
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.
You private key is to never be shared. It's the equivalent of giving awa= y your password.
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.
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.
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,
ssh-cop= y-id username@remotehost=20
It accomplishes in one command,
(Roderick you should fill this in)
Since I happen to be using Mac OS X I do this manually,
scp .ss= h/id_rsa.pub bhitch@krypton.com:~=20
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,
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,
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,
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,
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).
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,
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
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>
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,
# 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,
sudo se= d -i 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/s= shd_config=20
Changes the following,
# Chang= e to no to disable tunnelled clear text passwords #PasswordAuthentication yes=20
Uncomment and change yes to no. It should look like this,
# Chang= e to no to disable tunnelled clear text passwords PasswordAuthentication no=20
Finally restart ssh for the change to take effect,
sudo se= rvice ssh restart=20
In older versions of Ubuntu (to determine) where Upstart is not availabl= e use,
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,
ssh tph= am@lemonbistro.com Permission denied (publickey).=20
The Permission denied indicates that password authentic= ation is now disabled.
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.
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.