Doing It All with OpenSSH, Part 1

An introduction to doing it all with the secure shell.

Way back when, on this very corner, I did a series of articles on encryption and hiding your tracks, something I called the High Tech How Not to be Seen. In that series, I talked about the dangers of plain-text communications to security. Here's a quick recap for those who still might be connecting to remote systems using telnet. Anyone running a program like sniffit (reptile.rug.ac.be/~coder/sniffit/sniffit.html) can snoop on every packet sailing across your network. If you are logging in using telnet, that person can see your user name and password plain as day. Look at Figure 1, and see if you can guess the user nessie's password. This should dissuade you from using telnet for any kind of communication where security is even remotely important.

Figure 1. Can you guess nessie's password from this screenshot?

One way around this dilemma is to use the secure shell. OpenSSH is an open-source implementation of the secure shell protocol that comes with almost every major Linux distribution. You can run out to www.openssh.org to get the latest and greatest, but you probably already have it on your system. That said, keeping up to date with the latest version of OpenSSH is essential if you want to maintain security. So, if your version of OpenSSH is more than a few months old, you may want to consider checking for an update.

The secure shell is more than a simple way to keep your passwords to yourself. In this series, I take you from the basics through some nifty features that should make you wonder why you use anything else to communicate (well, almost).

Ssh has several components: a client and server, utilities for generating public and private encrypted keys for strong authentication and a secure FTP server. Before we log in using a secure shell, we need to start a secure server, which usually happens at boot time through a script in /sbin/init.d or /etc/rc.d/init.d, depending on your system. Look there for a script called simply sshd. You also can start the sshd dæmon by typing sshd at the shell.

To log in to the remote system named speedy, I then would use this command, ssh speedy.

By default, the sshd dæmon (or server) runs on TCP port 22--check it out by doing a more or less on your /etc/services file--but you can specify a different port with the -p option. Let's say you wanted to run the server on port 2222, to make it a little more difficult for unwanted guests to probe your system. To change this, simply type sshd -p 2222.

By the way, you can run multiple sshd dæmons on however many ports you like, but that's probably not necessary. Because your server is now running on port 2222, you also would use the -p option to connect to speedy, the same as you did for the server.

     ssh -p 2222 -l natika speedy

Okay, so I added another option. The -l option tells the system to log in using the user name natika. By default, an ssh login uses whatever your current logged-in user name happens to be.

     Warning: Permanently added 'speedy,192.168.22.3' (RSA) to the list of known hosts.
     mgagne@speedy's password:

Simple enough. At this point, you would enter your password, log in and start your work session, much as you would have done with telnet, only safer. The message above, though, is not the only one you could receive, and I'll cover some others in a moment. For now, I want you to look at the words list of known hosts. In your home directory ($HOME), you should find a directory called .ssh that should contain a file called known_hosts. This is where the key information is stored; in the above case, it stored the RSA key. It looks something like this.

speedy,192.168.22.3 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAw4MQ4ubLTHuQCW9rlksXLME9wnYYege1z/
K3J3caMpzkFy7DpJ1VQjIspf03wyHgdAbg3jaV6NBbN7y35UOLy2oqJ/vk3QISdgKca/OqH/
UpeesyXB0kMb0HMCX8LD8tJVaCzEtoi2BZNSAOZNheHx7znz80uTWUTA2cQkk7gs0=

Nice, huh? Don't worry. I don't expect you do sit there and read it with anything other than curiosity. Remember this file, though, because from time to time, on connect, you may receive a message like this:

   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
   Someone could be eavesdropping on you right now (man-in-the-middle attack)!
   It is also possible that the RSA host key has just been changed.
   The fingerprint for the RSA key sent by the remote host is
   76:3f:54:71:22:48:36:5b:c8:8c:42:e5:e7:db:60:60.
   Please contact your system administrator.
   Add correct host key in /home/mgagne/.ssh/known_hosts to get rid of this message.
   Offending key in /home/mgagne/.ssh/known_hosts:119
   Password authentication is disabled to avoid man-in-the-middle attacks.
   X11 forwarding is disabled to avoid man-in-the-middle attacks.
   Permission denied (publickey,password,keyboard-interactive).

Yes, it does sound nasty, but it may in fact be harmless. As the message says, it is also possible that the RSA host key has just been changed. If you know and trust the system, you can edit your ~/.ssh/known_hosts file and delete the line containing the offending key. The connect error message conveniently lets you know which line number you can jump to, in this case, it's line 119. If, like me, you tend to use vi, here's a cool trick for getting there quickly.

     vi +119 ~/.ssh/known_hosts

The +119 takes you right to line 119. Once there, a quick dd gets rid of the offending line for you. But I digress.

I mentioned that on connect, you might see different messages. To refresh your memory, here's the message I received when connecting to the host speedy:

    Warning: Permanently added 'speedy,192.168.22.3' (RSA) to the list of known hosts.
     mgagne@speedy's password:

Another common message I could have received is:

     The authenticity of host 'speedy (192.168.22.3)' can't be established.
     RSA key fingerprint is 83:9f:6b:3f:69:02:2a:94:c5:ef:5f:35:f9:42:71:17.
     Are you sure you want to continue connecting (yes/no)?

The difference has to do with yet another configuration file. Both the sshd dæmon and the ssh command itself have global configuration options that can be found in the /etc/ssh directory. If you built OpenSSH from source, you may find it in /usr/local/etc/ssh instead. The sshd dæmon's configuration file is named sshd_config, while the ssh client's configuration file is named ssh_config. For the moment, I'm going to concentrate on the ssh_config file:

     Host *
       ForwardX11 yes

As you might guess from the asterisk at the end of the Host paragraph, you can set up different parameters for different hosts. This is a global setting. I'll talk about X forwarding later, but if this is all you have in your ssh_config file, you can expect messages asking you to verify the authenticity of any new system into which you connect. Let's delete the key entry from known_hosts and try again. This time, we add one line to the global ssh_config file:

     StrictHostKeyChecking no

Connecting to my host now results in a simple acceptance of the host's RSA key. But what, you may be asking, would happen if you set StrictHostKeyChecking to Yes?

     Host *
     ForwardX11 yes
     StrictHostKeyChecking yes

When I try to connect to speedy now, this message is returned instead:

     $ ssh -l mgagne speedy
     No RSA host key is known for speedy and you have requested strict checking.
     Host key verification failed.

And that, my friends, is where I am going to leave things today. Keys, key generation and key management will be the subjects of my next column.

Marcel Gagné is Linux Journal's Chef Français and a Linux true believer. His new book, Moving to Linux: Kiss the Blue Screen of Death Goodbye! will be out in August. You can find out more from his web site.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Plaintext passwords in a switched network

Anonymous's picture

I assume most internal corporate networks use switches, which don't allow *most* non-priviledged users to see any packets but the ones destined for their machine. Still, IS/IT in those networks will not usually allow .rhosts or any of that foolishness, and ssh/scp is the best way to ftp, imho. There is a lot of reluctance to moving to SSH in a larger corporate environment, and I just don't understand it.

Bien sur, Marcel, you have not painted the darker side of SSH the correct color, hmm? Why would someone not want to use it? Windows and ssh could be a problem for windowzy users?

-- Jay

Re: Plaintext passwords in a switched network

Anonymous's picture

PuTTY fixes windows. ;>

Flibble

Re: Plaintext passwords in a switched network

Anonymous's picture

Putty makes a good *client*, but what is there for running a windows server? I'm running OpenSSH on windows and its having plenty of issues (dropping connections all the time - including local ones, significant delays, will randomly stop forwarding any ports, doesnt show any output from some programs such as netstat, and I don't have SCP working on it yet though I suspect there is a way to get it to work..)

Re: Re: Plaintext passwords in a switched network

Anonymous's picture

There is a native windows OpenSSH installer, and it doesn't even depend on cygwin, mingw, etc.

Just install it, run it's 'mkpasswd -l \etc\passwd', then 'mkgroup -l \etc\group' and you're good to go

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

(yet another user too lazy to register)

Thanks for dropping the French schtick. Even as a Canadian I found it annoying.

Great article as always :)

Re: Doing It All with OpenSSH, Part 1

wilkushka's picture

Marcel's articles are excellent and always crystal clear compared to some obscure articles as one reader mentions. System administration is not always obvious but Marcel has a gift to make it fascinating and understandable even to the layman, and always with a good sense of humor. I don't understand why so many people are complaining about the mixture of French and English in his articles. As a French I may not be neutral but I find it very funny. Why everything should be so serious in this world? People forget how to smile and joke. Is being happy and joyful a crime now? Keep on the good work Marcel. Je l

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

i'm french and i think any bit of humour we get in IT is great. Marcel, you're fun and being an almost-newbie with Linux, this is your style.

Merci bocups

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I'm afraid I must disagree regarding the French "schtick" - I find it makes an otherwise "heavy" read at times more enjoyable and, dare I say, easier to understand.

Being brought up on British humor (Monty Python, The Goons, The Goodies, etc) does help, I guess.

Even my wife, who is not yet a Linux convert (YET !!! BWhaaaaa) likes the light-hearted and easy-to-read style he has, as opposed to the more technical and dry styles of some other authors.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I agree. I think some of these respondents have no sense of humor.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

All in all the article is a good introduction.

What I want to add:

If you ever get the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message please DO NOT TAKE THIS EASY!!!

I think that the author does not emphasize enough that this is really often a sign for a man-in-the-middle.

Please only delete the "old" hostkey if you are absolutely sure, that the server's host key changed by allowed administrative task.

Thanks
Volker

Volker Kindermann
http://nextstep-security.de/

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

This message also happens when you do ssh to a system of several computers (comp1.my.net, comp2.my.net) that you can refer to as comp.

ssh comp1 puts one key into known_hosts file,
ssh comp2 puts another key.

But ssh comp will give you this message every time you are connected to the different host than you were last time. Solution: add 'comp' in each line of known_hosts:

comp1.my.net,comp ssh 34c11oVMtwReXWmWU...
comp2.my.net,comp ssh UvWnSzmZeOmYO0oTy...

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Does this apply to both SSH v1 and v2 or has all of the man-in-the-middle problems gone away with v2?

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

It's not something that can be done away with. It's the saving of the public key that prevents man-in-the-middle attacks (although you are vulnerable the first time you connect) The first time you connect, and every time the key changes, you should verifly the key by telephone, and/or in person)... That is the only way to be 100% sure there is no man-in-the-middle attack taking place.

Of course, you have to balance your need for security, with the hassle that security causes. You should also NEVER connect from any machine unless you know for a fact that no-one else has ever had physical access to it (and you are sure that it is not vulnerable to security exploits).

So, now that you know what you should do, are you going to strictly do it, or are you just going to be reasonably secure? If you are an Administrator for very important systems, I hope you will be very secure. If you just have a non-privlidged user account on a small webserver somewhere, I think you can be slightly relaxed about security.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Your OpenSSH article succeeds in demonstrating the problem, providing a solutions and anticipating the initial troubles I encountered when first using OpenSSH. Learning OpenSSH is required for security, but can be a difficult to master. I have now installed OpenSSH on AIX and Linux. I have converted my scripts from using .netrc files and other unsafe practices to using scp (secure copy). I look forward to future articles involving scp.

BTW: When I want to learn from somebody who is one of the best article writers for opensource technology, I search for articles written by Marcel Gagn

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I have to say, if you think SSH is difficult, I can't imagine how you'll do in the genuinely difficult parts of Unix.

SSH is simple enough that an amature can master it, just by spending 30 minutes to read the man pages for ssh, sshd, sshd_config, and ssh_config...

Pay close attention to the ssh-agent, and all the wonderful things it can do for you.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Firstly I don't want to remain anonymous but I am too lazy to register... anyway My name is Serge Arnaud and I am French.
The comment I want to make is that I enjoyed reading Marcel's article especially since he paid attention not to use French expressions as he used to. I did not enjoy this style and I think this is a lot more pleasant to read now..

That's my opinion and I share it! as one of our finance minister (Raymond Barre) said a while ago. I guess he also wanted to be humoristic..

Cordialement - Serge

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Well, Marcel is no Jerry Lewis, I grant you.

;-P

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I started to write this posting to say "I wish vendors that provide applications were as concerned with security as the people who install the applications." I ended up writing a positive note on the authors writing style. Oh well, I have learned never to fight the writing gods for fear of not being able to put to paper what is intrinsic.

Reading has been a key tool in my development of knowledge. Praxis brings the understanding. In order to want to read, I must find something in the material that attracts me. I find technical documents extremely hard to read. I read them because experience tells me what I am looking for is in the document. For some unknown reason, I must a pay a penance to extract the knowledge.

Before starting any reading I scan. Reading jackets, counting pages, how many scrolls to the bottom and do I recognize the author are all included in a scan. The well develop scan is a survival technique for any person that wishes to remain in IT. It is an effective solution if you every hope to get through the reams of informational material. The scan answers the question " does this subject matter to me?" Sometimes my rolodex of a mind miss files the cards. That subject is the makings of an article itself.

I have discovered in Marcel's writing style two key components that keep me coming back and putting it on a priority for a scan. The subject material can be technical but the delivery technique is casual. Hey wait a minute causal is enjoyable reading.

Starting with small concepts as a foundation and building on the foundation with expanded knowledge are a few corner stones in Marcel's writing style. Slipping off topic for a humorous tidbit or whimsical note are hallmarks. For some reason I seem to get from reading Marcel's articles the epiphany " it can't be that simple". This leads to the confidence that I can research the subject if I wish a deeper understanding. TCP Wrappers, inetd daemon, packet sniffing and securing services by just knowing, are a few of the subjects I credit Marcel with laying a foundation. If I every return to teaching I surely will need to get special permission from Linux Journal, so I can include the article in the course material.

I respect Marcel's decision to morphs his writing. It has grown and developed since I read, "Thwarting the System Cracker, Part 1" in 1999. As a writer it troubles me to hear someone say, if you don't write this way then I won't read you. Maybe the writing gods never commissioned the article for you to read. Spiritually forbid, the writer chooses to take lead from the reader! Hummm

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I agree also, Marcel always has interesting articles that are more often then not useful. But the Chef thing is tiresome. Please continue to write, leaving the Chef in the kitchen.

Dan M.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

I am in agreement on this. I have given up on reading Marcel's 'Cooking with Linux' articles because the French Restaurant shtick is too tedius and ceased being quaint some time ago. Marcel is a good writer, and I wish he would stick to conveying information, as he has in this article.

great site)dsfgsd

Anonymous's picture

great site)
!!!!!!!!!!!!!!!!!!!

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Yeah, just the facts Marcel. Less individuality, less personal style, less anything that might distinguish your writing from anyone else's writing. Just "convey information", I am much more comfortable that way. I've got tv to stimulate my senses and imagination. And frankly, I much prefer the ambience at 'Cheers' to a pseudo-french restaurant.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Actually I rather enjoy reading Marcels' column in LJ every month. Not finding it in there in the June issue is a BIG DISAPPOINTMENT.

keep up the good work Marcel

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Agreed. Difficult to fathom why LJ would omit it's voted most popular column.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

Agreed - I enjoy the French Chef. Please, keep it going Marcel and ignore the detractors

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

While I wouldn't necessarily miss the shtick, I will say that I often found myself chuckling as I read it. Maybe I'm just easy to please....

Anyway, just wanted to say it's not *all* bad.

Thanks for the great articles, Marcel....shtick or no shtick.

Re: Doing It All with OpenSSH, Part 1

Anonymous's picture

The comment associated to Raymond Barre was in fact from The mayor of Champignac in Spirou, probably in "le voyageur du mesozoique".
Anyway the expression didn't translate - several people tend to Share an opinion in English. However, the French expression implies "this is my opinion, and I agreed of its fragmented options" which doesn't translate without a long explanation.

Communication between French and English isn't easy....

Fellow Frenchman who could understand...

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState