Individual Entry

ssh-ecurity — Part 9: Confusion will be my Epitaph!

I have received myriad accolades for my series of blogs on ssh; especially, because it has covered the inter-operability issues with OpenVMS, Linux and Mac OS X. Despite the series, I am still being called upon to assist with ssh implementation on all three of the aforementioned environments. It is, of course, not a bad thing for one, like myself, who is in the computer consulting business but, in almost all of the cases, it was because of simple and stupid errors introduced when taking my blog examples and massaging them into one's own working environment.

One of the most egregious and pervasive errors I find myself repeatedly encountering concerns keeping the semantics straight. Public keys are the components of ssh which are distributed to the public. Private keys are the components of ssh which are to be kept private. This should not be rocket science as their names reflect upon their purpose and distribution; yet, I keep seeing both pairs being placed on both sides of the communication channel. In my examples in the ssh-ecutiry series of blogs, the public key component was always denoted with the filename extension of .PUB. This is the key, the only key, which should be distributed or disseminated. The other component is the private key and should be held in strict confidence on the system for which is was created. Distribution or dissemination of the private key defeats the whole purpose of ssh.

Another issue which seems to cause great vexation is one that can be classified as simple system and or file management. Confusion, especially in an environment where there are many systems with secure communications requirements, abounds when it comes to naming the files containing the keys. I suggest using the system's host name or its host IP when creating ssh key pairs. This, then, allows the remote host's management to enter the system's public key into its key repository with something meaningful to relate the key to the system to which it belongs. A recent, marathon, WEBEX session I was invited to attend dealt with this very issue. It is far too easy to become confused — Yes, even me — when the ssh key components maintain meaningless names or, worse, the same names. ssh does not know, nor does it care, what you call the key files, so why not make it simple and obvious, and give the key files meaningful names?

Follow all of the steps that have been outlined in my series on ssh and there should be no problems interconnecting using ssh. I make use of ssh and sftp extensively every day. I interface with OpenVMS — both my own systems and with remote client's systems — Linux and Mac OS X. One of the systems I use ssh to access — specifically, I use ssh tunnels — is even a Micro$oft box; however, it has had CygWin installed to provide a shell for command line access and control. I have no knowledge as to whether or not it's possible to directly ssh into Weendoze, so don't ask. I've even established ssh connectivity to my Cisco routers with public key encryption. While I have not detailed this, yet, in any of my ssh articles, it doesn't mean that there may not be another segment to this series to exposé how that too can be configured.

Stay tuned for more. In the mean time, keep it straight; keep it simple and, above all, keep it secure!


To thwart automated comment SPAM, you must answer this question to post.

Comment moderation is enabled. Your comment(s) will not be visisble until approved.
Remember personal info?
Hide email?
All html tags, with the exception of <b> and <i>, will be removed from your comment. You can make links by simply typing the url or email-address.


« May 2017 »
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Meta Information:

Title: ssh-ecurity — Part 9: Confusion will be my Epitaph!
Date: 16-May-2014 12:57
Size: 599 words
Next:   » MOVPSL — I've a feeli…
Prev:   « Apocalypse 32767




Powered by…