This post is intended for those who are using Linux/BSD/Unix servers and those who did use Linux/BSD/Unix to read.
Normal computer users will not know what it is.

So if you never use any Linux/BSD/Unix before, don’t even bother to continue read, coz you won’t understand this post and you won’t know what it this thing, unless you are interested with what it running inside your router or managed network devices in your office.

Simple introduction to those who interested to know what is OpenSSH and have no idea what is OpenSSH:

OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt The project’s development is funded via donations.

Quoted from Wikipedia.

Then what is SSH?
Answer: find in the Internet yourself lah, this article is only about OpenSSH, not about what is SSH protocol!

Anyway SSH (A.K.A Secure Shell) protocol has been very useful for a lot of sysadmin to administrate Linux/BSD/Unix. SSH has been serve as replacement to Telnet and other remote shell protocols due to they are not secure enough where they only send the password during the session login by just sending the password in plaintext. So SSH protocol has been designed to replace these insecurity where it send passwords during login session with encryption. Encryption is very important especially when a sysadmin is logging in to a server via the Internet.

The SSH protocol has evolved since version 1.0, then 1.3, 1.5 and then now 2.0. But I will not talk much details about the SSH protocol versions, since I am going to be more focus on introducing the usage of SSH and OpenSSH 5.4.
Also, I am lazy to talk about its DSA or RSA keypair things. Cos there is too many things to talk about if include the encryption things.

Anyway, sysadmins like me who are administrating Linux/BSD/Unix, we do all the work my using SSH to configure the whole server. In other words, it is just the same like we are sitting in front of the server itself to do what we need to do for the server. Therefore, it have advantages over Telnet which do not have such flexibility since Telnet do have a lot limitations.

When I said that when sysadmins is using SSH to control the server, those who do not know what it is will thought that we will see the “Desktop” of the server.
You are wrong actually. Linux/BSD/Unix servers usually do not have desktop environment installed by default, unless some moron install the Xserver/Xorg and the whole desktop environment into that server. Then these moron will use tools like VNC to connect into the server(coz these morons don’t know how to use Linux/BSD/Unix commands).

In short, a well deployed server will only have shell, where there will be only using commands. This will be saving a lot of the server’s resources such as CPU cycles and RAM. And of course, less apps is installed(the whole desktop environment), less possible exploit.

Currently, only Windows servers is still using Telnet. And most of the things in Windows servers, are not able to configure via commands, and the “syisadmin”(A.K.A sister admin/baby sitter, lol) will have to login using RDP to login into its Desktop to point and click like using normal PC to do work. So pathetic… Using a desktop as a server and payed so much for the OS license.

Ok, stop being sarcastic already.
Back to the topic.

Aside from using SSH as remote shell connection protocol with commands, it is also useful for file transfer if you want the transaction is secured. Some people use SCP(Secure Copy) on top of SSH protocol. But usually people who uses SCP is sysadmins who wanted to transfer files from a server to another server.

By the way, Windows servers have no SCP. You are expected to plugin in a pendrive into your Windows server and copy out the data you want, just like using a Desktop. Or use FTP to upload to another server when you logged into its desktop via RDP. Useless you have so much time to use the command line FTP after Telnet into the Windows server, then cd(change directory) to the folder and find the file you want to upload to upload then 1 by 1 using the ftp command.

Anyway, besides SCP, you can also use your FTP client to login into a Linux/BSD/Unix server to download or upload files from your desktop via SFTP. SFTP is the same protocol as SSH which usually on port 22. It takes all advantage of the SSH security and you may using it just the same like you use FTP. The only different is, it is much more secure.

Ok, the introduction part is end.

Here is the geeky part.
Version 5.4 is released to public at 8th March 2010.
Here is the added features as listed at

* After a transition period of about 10 years, this release disables
SSH protocol 1 by default. Clients and servers that need to use the
legacy protocol must explicitly enable it in ssh_config / sshd_config
or on the command-line.

* Remove the libsectok/OpenSC-based smartcard code and add support for
PKCS#11 tokens. This support is automatically enabled on all
platforms that support dlopen(3) and was inspired by patches written
by Alon Bar-Lev. Details in the ssh(1) and ssh-add(1) manpages.

* Add support for certificate authentication of users and hosts using a
new, minimal OpenSSH certificate format (not X.509). Certificates
contain a public key, identity information and some validity
constraints and are signed with a standard SSH public key using
ssh-keygen(1). CA keys may be marked as trusted in authorized_keys
or via a TrustedUserCAKeys option in sshd_config(5) (for user
authentication), or in known_hosts (for host authentication).

Documentation for certificate support may be found in ssh-keygen(1),
sshd(8) and ssh(1) and a description of the protocol extensions in

* Added a ‘netcat mode’ to ssh(1): “ssh -W host:port …” This connects
stdio on the client to a single port forward on the server. This
allows, for example, using ssh as a ProxyCommand to route connections
via intermediate servers. bz#1618

* Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
be revoked using a new sshd_config(5) option “RevokedKeys”. Host keys
are revoked through known_hosts (details in the sshd(8) man page).
Revoked keys cannot be used for user or host authentication and will
trigger a warning if used.

* Rewrite the ssh(1) multiplexing support to support non-blocking
operation of the mux master, improve the resilience of the master to
malformed messages sent to it by the slave and add support for
requesting port- forwardings via the multiplex protocol. The new
stdio-to-local forward mode (“ssh -W host:port …”) is also
supported. The revised multiplexing protocol is documented in the
file PROTOCOL.mux in the source distribution.

* Add a ‘read-only’ mode to sftp-server(8) that disables open in write
mode and all other fs-modifying protocol methods. bz#430

* Allow setting an explicit umask on the sftp-server(8) commandline to
override whatever default the user has. bz#1229

* Many improvements to the sftp(1) client, many of which were
implemented by Carlos Silva through the Google Summer of Code
– Support the “-h” (human-readable units) flag for ls
– Implement tab-completion of commands, local and remote filenames
– Support most of scp(1)’s commandline arguments in sftp(1), as a
first step towards making sftp(1) a drop-in replacement for scp(1).
Note that the rarely-used “-P sftp_server_path” option has been
moved to “-D sftp_server_path” to make way for “-P port” to match
– Add recursive transfer support for get/put and on the commandline

* New RSA keys will be generated with a public exponent of RSA_F4 ==
(2**16)+1 == 65537 instead of the previous value 35.

* Passphrase-protected SSH protocol 2 private keys are now protected
with AES-128 instead of 3DES. This applied to newly-generated keys
as well as keys that are reencrypted (e.g. by changing their

In the same release note, it is also stated that 46 known bugs is fixed, including the bugs in Portable OpenSSH. This is a major release with so many new features added.
And the nice part is, we can now do ssh proxy/tunneling much more easier with the netcat mode.
So now we can do more fun things with it! Hahahahah(I’m not asking you to use for for something that offending the cyberlaw ar!)

Soon it will be available for upgrade from your distro’s repo.
Although it might not be available in your distro repo, but you can always download the source files and compile it yourself. Don’t be so lazy, patch it!!!
Anyway, no need me to tell you this, you should already know this.

For those who do not familiar with Linux/BSD/Unix stuff, OpenSSH is not the only apps for SSH protocol. There is another one called DropBear which is also able to do the same thing. DropBear is lighter and uses less RAM, the only disadvantage it have is DropBear do not have as much features as OpenSSH. This is why it is lighter.

DropBear is often used on those lower cost routers/modems which usually those models which is for home use. Since it uses less resources and lighter, it is often chosen to be the SSHD for these lower grade routers/modems since they usually have lower RAM and MIPS processor.

Anyway, this whole article I only mention about the server side SSH(SSHD) only.
Sorry that I didn’t mention anything much about client side. Too Lazy to write already.

Anyway, hope you like this picture.

got root?