Even more SSH – Great Article on /dev/random

Quick update to Part 2 of the AoIS Secure Your Linux Host Series on SSH.

I noticed a great article today on  Xavier Mertens/dev/random blog (which by the way has several great posts that have caught my eye…), on SSH tunneling -> “Keep an Eye on SSH Forwarding“.

In addition to providing a solid introudction to SSH Port Forwarding Xavier also discusses:

  • Using SSH as a SOCKS Proxy via the SSH Server
  • Logging port forwarding
  • Restricting  ports that can be forwarded

Check it out.

Cheers, Erik

AoIS Interviews Michael Rash, Part 2

Michael Rash Headshot

The Art of Information Security continues our interview with Michael Rash, Network Security expert and the driving force behind several open source security tools including PSAD, FWSnort, and FWKnop.

In Part 1 of the interview Michael discussed how he came to be involved in Network Security and Intrusion Detection system design. Here in Part 2 we get a little deeper into Michael’s philosophy on Network Intrusion Protection and discuss more open source tools that he is involved with the develop and support of.

Erik: How do you see network based attacks changing ?

 Michael: Over time, I think network based attacks will continue to be more automated and therefore accessible and deployable by more people. When it comes to educating oneself on the details of network insecurity, excellent projects such as Metasploit, Nessus, and Nmap point the way – and this is essential also for people trying to defend networks too. We will see more attacks delivered over IPv6, and we will see ever more clever ways to exploit the natural tendency of people to trust data in ways they shouldn’t. For me as a person trying to protect networks, the later is the most worrisome. A good example of a new and clever attack is “in-session phishing” as described here (Arstechnica link).

Erik: The firewalls that I run are utilized as host based protection. As you see network security becoming increasingly important, do you see the firewall “concept” become a hybrid of network protection layered over host based network controls?

Michael: With good firewall implementations (such as iptables) that do not place undue burdens on network processing that takes place on hosts, I do believe that firewalls will be viewed more and more as an essential protection mechanism for the host. The network perimeter will also continue to be an important deployment point for large firewalls to enforce global policy, but limiting the damage a successful exploit against an internal system is a problem that such an external firewall is not well-suited to address. Having a hardened network security stance on each host can provide an important benefit in this area. Further, as firewalls offer more application layer processing features, hosts can deploy customized policies that define sets of application layer data (derived from Snort rules) that are unfit for communicating with local sockets.

There are challenges though regarding managing all of those host-level firewall policies, and this is where some patience and scripting ability can play a roll.

Erik: And then came FWSnort? What were the principles that drove the development of FWSnort ?

Michael: The fwsnort project was inspired originally by the snort2iptables script written by William Stearns. This was back in the Linux 2.4 days when the string match extension was still distributed within the patch-o-matic system from the Netfilter project. Being interested in intrusion detection and firewalls at the same time, it was a goal of mine to see how far iptables could be taken in the direction of detecting (and blocking) malicious traffic. The snort IDS had a well-developed signature language, and at that time the signatures were still free and released under the GPL. So, it was natural to try and extend the snort2iptables code, and fwsnort was created.

The main goal of fwsnort is to use facilities provided by iptables to recast Snort signature sets within iptables policies. A clean translation is not always possible particularly with complex Snort signatures that use regular expression matching (because no regex engine is available to the iptables code running in the kernel), but many Snort signatures can faithfully be translated.

 Erik: Was your vision that PSAD and fwsnort teamed up as host IDS dynamic duo, or more as services that strengthen network firewalls?

Michael: Ideally I would say both here. The difference between the two types of deployments is negligible from psad and fwsnort’s perspectives – both can be deployed just as effectively against the iptables INPUT chain (for packets directed at the local system) as the FORWARD chain (for packets directed through a network firewall). The effect of not deploying host firewalls is that the outside of the network may be protected by a crunchy shell, but the inside is a chewy center. If any system can be compromised internally on such a network, an attacker is presented with few barriers to additional actions once the perimeter is breached.

 Erik: But wait – there’s more ! You are also the driving force behind FWKnop !

Michael: Thanks for mentioning fwknop. This project has received a large percentage of my attention in the last year or so. It was started originally in 2004 as the first port knocking system that added passive OS fingerprinting as an authentication parameter, but in 2005 Single Packet Authorization was added. SPA solves many of the protocol limitations that are built into port knocking (ease of replay attacks, lack of decent data transmission, and difficulty of scaling to many users), and takes the idea of “default-drop” to a new level. That is, a service such as SSH is itself made completely inaccessible before the lightweight SPA packet is passively sniffed and the firewall is reconfigured to allow access only if the SPA packet is valid. This essentially combines techniques from the IDS world (passive packet sniffing) with techniques from the authentication and authorization world (encryption and the like).

Erik: And how did the book come to be ?

Michael: I have generally tried to capture my thoughts on computer security by writing them down. In 2001 I started writing articles, and wrote a few for the Linux Journal after working with Jay Beale on the Bastille Linux project. From there, I joined Jay with writing material for Snort books for Syngress. My open source development interest has always remained in IDS and firewall technologies, so I eventually decided to write a book about the two together. The result was the No Starch book. Let me just mention here that if any of your readers is interested in writing a book, I can wholeheartedly recommend No Starch as an absolutely fantastic publisher to work with.

Stay Tuned for Part 3

Part 3 of this series is coming soon, with more discussion about network security as well as the impact that contributing to open source tools has had on Michael professional opportunities.

Cheers, Erik

 

Secure Your Linux Host – Part 3: Why A Host Firewall ?

This post is going to focus on building and applying a Host Firewall using the IPTables functionality that is built into Linux. (If you are already lost, try googling “securing linux with IPTables”, and check out the resources section below.)

Please note: This Secure Your Linux Host series is very hands-on.  The tools and tips that will enable you to use a Host Firewall are coming, but let’s lay the foundation for using them first…

What is a Host Firewall?

When the concept of Firewall is mentioned, the most common meaning that comes to mind is a network services control between networks. Over 90% of the information that you can find on Firewalls is targeted at people who want to protect systems on one network (such as their corporate or home LAN) from systems on another network (generally the internet), while permitting a list of known services to be accessed by one network from the other. There are in fact several effective strategies for using Network Firewalls as boundaries between networks, or network segments.  For a detailed introduction (or tune up) on this subject, please refer to the NIST document in the resources section below, or click here for a great SANS introduction.

A Host Firewall is different in that it exists to protect and control access to a single system from all others. Common scenarios a Host Firewall is well suited to address:

  • Host is in direct contact with the Internet (or other hostile network)
  • Host is located in a DMZ
  • Host cannot trust systems on its network segment
  • Host has high control expectations due to legal, regulatory, audit, or risk requirements

If you have servers that are hosted in a data center or directly connected to a broadband/DSL connection and, as a result, are in direct contact with the internet, then I highly recommend configuring a Host Firewall. Systems that are in this situation will be attacked from other systems all over the globe all of the time. There are so many attackers who are running probing scans across the entire network space of the Internet that you will get scanned. The recent log information that I supplied on http scans and ssh password attempts is an example of how any host (no matter how insignificant) will be regularly attacked.

dmz_conceptual OK –  so what if the host is behind a firewall in a DMZ with other hosts (such as the www and SMTP, hosts in this illustration)? Most DMZ networks do not provide protection against attacks from other “peer” hosts in the DMZ. The problem that this presents is that, in the event that one host in the DMZ becomes exploited, then it can be used to probe and attack all of the hosts in the DMZ. Even worse, if a single host in the DMZ falls prey to a Worm or other self-propagating threat, then all similar hosts in the DMZ can be rapidly infected.

The “Host cannot trust systems on its network segment” argument for a Host Firewall is almost identical to the DMZ argument. Why provide access to services on the box to systems that do not need them?

The last point is about high-risk or highly-regulated systems. The rules on a Host Firewall are much simpler to review and understand (but perhaps not manage) than the rule set on a network boundary Firewall. This can have two major  advantages. First, it can make it much easier to provide complete and frequent reviews of the Firewall rule set. Second, it can remove confusion, limit scope, and simplify formal audits of the network access that the given Host has.

Isn’t Linux Secure by Default?

Many Linux distributions and commercial operating systems advertise that they ship in a “fail safe” or at least “start safe” mode; let’s assume that to be the case. When you install any operating system, the first thing you do is start installing software and applications. With each application that you install, you may be exposing services to the network.

With a Host Firewall, you will know precisely what services you are and are not exposing. As you know from Part 1, I run a Mail Transfer Agent so that email to root, events, etc. is in fact delivered to an email account I actually use. Running a Host Firewall dramatically raises my confidence that I am not a SPAM relay – sure, I think I configured the MTA properly… But with the Host Firewall I know that only services on my host (via 127.0.0.1) can send email. Running a LAMP server provides a very similar situation. With the Host Firewall in place, I know that MySQL isn’t accessible on its native ports to the world.

So, What is the Downside?

The reason that more systems are not running a Host Firewall is a lack of management tools. If you have a small number of hosts that you are administrating, then adding and managing a Host Firewall is not much work at all. But, if you have a hundred servers with a mix of operating systems, split into several data centers, suddenly managing Host Firewalls is not only a nightmare but may be causing more operational risk than is acceptable.

Every modern operating system (Linux, Unix-*, Windows, System/Z, openBSD, etc.) comes with a built in Host Firewall capability. What is needed is tooling that enables both centralized management and harmonization with network boundary Firewalls. (Unfortunately, I won’t be able to provide that in this series!)  The vendors with the best management of the network boundary Firewalls tend to be the manufacturers of those Firewalls, and they would be the most logical group to expand their existing management capabilities into the Host Firewall space. But, I do not think that anyone has developed a revenue model to justify that as worth the investment. (Hope springs eternal!)

What’s Next?

In the next installment, I am going to walk through the actual artofinfosec.com Firewall. (No B.S. “Security Through Obscurity” here!) And then in the following segment, I am going to discuss tools for monitoring and adding countermeasures to the Host Firewall.

Resources

  • Securing Linux Systems With Host-Based Firewalls Implemented With Linux iptables (htmlpdf)

This is a great introduction to building a Host Firewall. (The html site version seems like a paraphrase of the Sun Blueprint document pdf.) It is a resource that I return to time and again. The firewall example provided here includes full egress control, and the article walks the reader through the firewall step-by-step. The description is for a very controlled Host Firewall, so controlled that I in fact found myself moving to a simpler implementation.

  • NIST: Guidelines on Firewalls and Firewall Policy (pdf)

The NIST documentation (as usual) provides a great 360-degree medium-depth introduction to the topic. If you currently, or are about to, manage firewalls as part of your network security function, then read this guide!

Cheers, Erik

AoIS Interviews Michael Rash, Part 1

Michael Rash Headshot

The Art of Information Security has the great pleasure of interviewing Michael Rash. Michael holds a Master’s Degree in applied mathematics with a concentration in computer security from the University of Maryland.  He is the founder of cipherdyne.org, a website dedicated to open source security software for Linux systems, and works professionally as a Security Architect on the Dragon IDS/IPS for Enterasys Networks. He also is the author of “Linux Firewalls: Attack Detection and Response with  iptables, psad, and fwsnort”  (Sample chapter and more information here) published by No Starch Press.

When I started the Art of Information Security blog, I felt that it was important to appropriately lock down the host. It would be an unfortunate irony to have the server hosting a security blog “owned” by some script kiddy. So, of course AoIS runs a firewall. I had been using iptables firewalls on Linux for a while, and there were a few things that I felt were lacking from the set-ups that I had in the past. One was the ability to understand that the firewall is working. A solid firewall generates logs – but what do you do with those? And, what do they tell you? Second, I knew that I should be able to detect certain types of automated attacks and block those IPs. There are so many improperly configured hosts to attack that a few simple countermeasures go a long way. Third, I have also been very interested in running host IDS/IPS, but all the requirements to run Snort for a single host seemed a bit too much. Alas, I ran to cipherdyne.org and the great tools sponsored (and authored) by Michael.

Erik: So, Michael, Network Security is obviously more than just a job for you. How did you come to be involved so deeply in Network Security and Intrusion Countermeasures?

Michael: During the late 1990’s I was introduced to intrusion detection on a large ISP’s network, and that experience coupled with learning networking protocols sparked a deep and abiding interest in network security. This interest eventually led me to systems programming on Linux, and to the internals of systems that need to be protected. The constant game of cat and mouse played by attackers and defenders in the network security world never ceases to provide new directions for security research, and thanks to the open source development model, many of the techniques to defend systems can be investigated and contributed to by anyone.

Erik:  So when did you get the idea for PSAD?

Michael: In 1999 I started working with Jay Beale on the Bastille Linux project. At the time, both portsentry and Snort were around and were designed to detect network attacks (with the former only focused on port scans). Because Bastille was designed to harden the security stance of the host, a strong iptables policy was built in by Peter Watkins. With the strategy implemented by portsentry of listening on sockets in order to detect port scans (see the this link for why this is less than ideal from many perspectives), we needed a way to detect port scans in a manner compatible with Bastille’s iptables policy. The result was a portion of Bastille initially called “Bastille-NIDS”, but I eventually split it off as a dedicated project, and called it “PSAD”. An option would also have been to just write a configuration utility for Snort, but there would still have been a void since no tool really analyzed iptables log messages for suspicious activity. I made it my goal to try and fill this void mostly because the data source provided by iptables log is quite rich and has a lot to say.

Erik:  On your website you identify three principles around which PSAD was developed. Why are these important? How does PSAD accomplish them?

  1. Good network security starts with a properly configured firewall
  2. A significant amount of intrusion detection data can be gleaned from firewalls logs
  3. Suspicious traffic should not be detected at the expense of trying to also block such traffic

Michael: Network security is more relevant for more people today than at any other point in Internet history. Important infrastructure is increasingly being put online (such as online banking access), and the threats are evolving to compromise this infrastructure. The default stance of many operating systems is to listen on several services to make things easier for users, and while many OS’s (particularly mainstream Linux distributions) offer to configure firewall policies, many users elect not to go through with this step. Sometimes people are too busy to maintain a properly configured firewall, or they reason that the local border firewall is sufficient. Firewalls should always be configured in a default-drop stance in order to provide an additional layer of protection for any vulnerable services that may be listening. For Linux systems, psad helps to verify that the local iptables policy is configured in this manner.

Firewall logs are also an important area to pay some attention. Although firewall logs cannot replace the full packet capture and logging capability of many intrusion detection systems, they can still be a valuable source of data to highlight efforts to break into systems. With a logging format that is as complete as provided by the iptables logging infrastructure, it is possible to detect and differentiate most types of nmap scans, passively fingerprint remote operating systems, detect probes for back doors, and more. The process of parsing iptables logs to look for these kinds of activities is automated by psad.

Finally, just detecting malicious traffic will always play second fiddle to an effective mechanism for also blocking such traffic. The iptables firewall is a well-tested piece of code that runs inline to the packet data path. Hence, it is a strong weapon to block suspicious traffic with a default drop stance before such traffic is allowed to target internal systems. By using the iptables string match extension, iptables blocking actions can even be tied to the inspection of application layer data.

Stay Tuned for Part 2

Part 2 of this series is coming soon, with more discussion about network security and open source security tools. More information is available on PSAD at http://www.cipherdyne.com/psad/. (Oh, and PSAD will be featured in an upcoming installment of the AoIS Secure Your Linux Host series !)

Cheers, Erik

More SSH Anyone ?

Two Quick updates to Part 2 of the AoIS Secure Your Linux Host Series on SSH.

Interesting Series by ISS X-Force on SSH

Just this morning I ran across a three part series on SSH published last year in IBM’s Internet Security Systems X-Force Threat Insight in the following issues:

X-Force expresses a slightly different set of concerns, and solutions. One topic that I did not touch on was the use of ssh agents for the management of sessions. Part 3 (June) is almost entirely focused on that.

Logwatch Samples

One of the great things about the script kiddies is they are keep testing your security for you ! 😉 Below is a mash-up and edit-down of the last few days of ssh related itms from my logwatch logs. Logwatch really has become one of my favorite tools. I don’t have tons of attacks on my servers, but there is always enough activity in the logs to let me know that the controls and countermeasures are up and running. After installing fail2ban, I always have some activity in 24 hour period of time. 

And a tip for the paranoid – if you have Failed logins and Illegal users but no fail2ban activity – then fail2ban has stopped running (or worse…).

——————— fail2ban-messages Begin ————————
Banned services with Fail2Ban:
Bans:Unbans  
ssh: [ 6:6 ]  
ssh: [ 4:7 ]  
ssh: [ 6:5 ]
ssh: [ 5:3 ]
———————- fail2ban-messages End ————————-

——————— SSHD Begin ————————
Failed logins from:
75.xxx.109.82 (75-xxx-109-82-Indianapolis.hfc.comcastbusiness.net): 1 time
79.xxx.248.27 (host27-xxx-static.38-79-b.business.telecomitalia.it): 1 time
200.xxx.209.156 (dedint-200-xx-209-156.mexdf.axtel.net): 3 times
59.xxx.92.26: 6 times
88.xxx.16.23 (…): 7 times
119.xxx.154.57: 6 times
203.xxx.198.3 (…): 6 times

Illegal users from:
60.xxx.249.90 (…): 3 times
75.xxx.109.82 (…): 3 times
79.xxx.248.27 (…): 3 times
200.xxx.209.156 (…): 2 times
202.xxx.28.244 (…): 3 times
85.xxx.133.177: 4 times
193.xxx.161.136: 4 times
———————- SSHD End ————————-

Cheers, Erik

Lie Detector Libel

I noticed a posting on Slashdot (link) this morning regarding a gag order on an article that was to be published in a peer reviewed scientific journal but has been suppressed. The article was critical of lie detector technology, and evidently provided information debunking it.

More information is available her:  Stockholm University article.

The thing I find most interesting about this is that the US Supreme Cort has already determined that Lie Detectors are unreliable. From Wikipedia article on the polygraph:

In the 1998 Supreme Court case, United States v. Scheffer, the majority stated that “There is simply no consensus that polygraph evidence is reliable” and “Unlike other expert witnesses who testify about factual matters outside the jurors’ knowledge, such as the analysis of fingerprints, ballistics, or DNA found at a crime scene, a polygraph expert can supply the jury only with another opinion…”.

One of the things I find most interesting about the challenge of “testing” lie detectors is that no testing, such as the tests performed my Emily Rosa to debunk Therapeutic Touch, have ever been offered with can objectivity demonstrate the that they even work.

Cheers, Erik

Secure Your Linux Host – Part 2: Secure SSH

SSH is the preferred (perhaps de facto) remote login service for all things UNIX. The old-school remote login was telnet. But telnet was completely insecure.  Not only was the confidentiality of the session not protected, but the password wasn’t protected at all – not weak protection – no protection.

Trinity hacking ssh with nmap in ReloadedAnd so SSH (aka Secure Shell was developed)… But it has not been without its failings. There are two “flavors” for SSH: Protocol 1 and 2.  Protocol 1 turned out to have pretty serious design flaws. The hack of SSH using the Protocol 1 weaknesses was featured in the movie Matrix Reloaded. So, by 2003, the flaws and the script kiddie attack were understood well enough to have the Wachowski Brothers immortalize them.

Another concern to watch out for is that SSH has port-forwarding capabilities built into it. So, it can be used to circumvent web proxies and pierce firewalls.

All in all though, SSH is very powerful and can be a very secure way to remotely access either the shell or (via port forwarding) the services on your host.

For additional information on SSH’s port-forwarding capabilities:

Be aware that SSH is part of a family of related utilities; check out SCP, too.

Configuration

After installing the SSH server (perhaps: apt-get install openssh-server), you will want to turn your attention to the configuration file /etc/ssh/sshd_config

Here are a few settings to consider:

Protocol 2
PermitRootLogin no
Compression yes
PermitTunnel yes
Ciphers aes256-cbc,aes256-ctr,aes128-cbc,aes192-cbc,aes128-ctr
MACS hmac-sha1,hmac-sha1-96
Banner /etc/issue.net

  1. The “Protocol” setting should not include “Protocol 1”. It’s broken; don’t use it.
  2. PermitRootLogin should never be “yes” (so, of course that is the default !). The best option here is “no”, but if you need or want to have direct remote root access (perhaps as a rescue account), then the “nopwd” option is better than “yes”. The nopwd option will force you to set up and use a certificate to authenticate access.
  3. Unless your host’s CPU is straining to keep up, turn on compression. Turn it on especially if you are ever using a slow network connection (and who isn’t).
  4. If you are not going to access services remotely using SSH as sort of a micro-VPN, then set this to “off”.  Because I use the tunneling feature, I have it turned on.
  5. OK; I work and consult on cryptographic controls, so I restrict SSH to the FIPS 140-2 acceptable encryption algorithms.
  6. Likewise, I restrict the Message Authentication Codes (MACS) to stronger hashes.
  7. Some jurisdictions seem to not consider hacking a crime unless you explicitly forbid unauthorized access, so I use a banner.

Sample Banner

It seems that (at least at one point in the history of law & the internet) systems which did not have a login banner prohibiting unauthorized use may have had difficulty punishing those that abused their systems. (Of course, it is pretty hard to do so anyway, but…) Here is the login banner that I use:
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *
*                                                                             *
* The use of this system is restricted to authorized users. All information   *
* and communications on this system are subject to review, monitoring and     *
* recording at any time, without notice or permission.                        *
*                                                                             *
* Unauthorized access or use shall be subject to prosecution.                 *
*                                                                             *
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *

Account Penetration Countermeasures

Within hours of establishing an internet accessible host running SSH, your logs will start to show failed attempts to log into root and other accounts. Here is a sample from a recent Log Watch report:

--------------------- SSHD Begin ------------------------
Failed logins from:
58.222.11.2: 6 times
211.156.193.131: 1 time
Illegal users from:
60.31.195.66: 3 times
203.188.159.61: 1 time
211.156.193.131: 3 times
Users logging in through sshd:
myaccount name:
xx.xx.xxx.xx: 3 times
---------------------- SSHD End -------------------------

One of the most effective controls against password guessing attacks is locking out accounts after a predetermined and limited number of password attempts. This has a tendency to turn out to be a “three strikes and you’re out” rule.

The problem with applying such a policy with a remote service, like SSH, as opposed to your desktop login/password, is that blocking the password guessing attack becomes a Denial of Service attack. Any known (or guessed) login ID on the remote machine will end up being locked out due to the remote attacks.

Enter Fail2ban: Rather than lock out the account, Fail2ban blocks the IP address. Fail2ban will monitor your logs, and when it detects login or password failures that are coming from a particular host, it blocks future access (to either that service or your entire machine) from that host for a period of time. (Oh, and you may notice I said blocks access to the “service”, and not “SSH” – that’s because Fail2ban can detect and block Brute Force Password attacks against SSH, apache, mail servers, and so on…)

How to Forge has a great article on setting up Fail2ban – Preventing Brute Force Attacks With Fail2ban – check it out.

One tweak for now. As I tend to use certificate authentication with SSH (next topic), I rarely am logging in with a password. As a result, I tend to use a bantime that is long, ranging from a few hours on up. Three guesses every few hours really slows down a Brute Force Attack! Also, check out the ignoreip option, which can be used to make sure that at least one host doesn’t get locked out. (You can lock yourself out with Fail2ban… I have done it…)

SSH Certificate Based Authentication Considerations

Secure Shell offers the ability to use certificate based authentication with a self-signed certificate. There are two ways you might consider using this:

  1. With a password protecting the private key
  2. With no password required

Please note: When you establish certificate based authentication with SSH, you will generate a public/private key pair on your local computer. The public key will only be copied up to the server which you wish to access. The private key always stays on your local computer.

During the process of generating the private and public key pair, you will be asked if you want to password protect the private key. Some things to consider:

  • Will this ID be used for automated functional access ?

If you are creating the certificate based authentication so that a service can access data or run commands on the remote machine, then you will not want to password protect the local file. (If you do, you will end up including the password in the scripts anyway, so what would be the point?)

Personally, I have backup scripts which either pull data or snapshots on a regular basis. Google “rsync via ssh” for tips on this, or “remote commands with ssh” for tips and ideas. (Also, I may cover my obsessive compulsive backups in a later post.)

  • This ID will be used for a rescue account

In this case the certificate is usually created to avoid password expiration requirements. If it is a rescue account, it often logs into root. Any time you use certificate access for root, the private key should be password protected. Rescue accounts are often stored on centralized “jump boxes” and are expected to only be used during a declared emergency of some kind (such as full system lockout due to a password miss-synchronization.)

These private keys should always be password protected.

If someone has access to backups or disk images of the jump box, or otherwise gets access to your .ssh directory, and you have not password protected the private key, then they own the account (e.g., they can use the public/private key pair from any box).

  • Convenient remote logons…

The most common use of certificate based authentication for SSH is in fact to log you into the remote box without having to type passwords. (I do this, too…) But there are a few things to think about (these are all good general recommendations, but I consider them requirements when using an automated login…)

  1. Automatic login should never be used on a high-privilege account (e.g., root)
  2. If those accounts have sudo privileges, sudo should require a password
  3. A new certificate (public and private key pair) should be created for each machine you want to access the remote server from (e.g., desktop, laptop, etc.).  Do not reuse the same files.
  4. The certificate should be replaced occasionally (perhaps every 6 months).
  5. Use a large key and use the RSA algorithm option (e.g., ssh-keygen -b 3608 -t rsa)

SSH Certificate Based Authentication Instructions

So, without further ado… Let’s set up a Certificate for authentication.

Part 1 – From the client (e.g. your workstation, etc…)

First, confirm that you can generate a key.

$ ssh-keygen --help

The options that are going to be of interest are:

  • -b bits  Number of bits in the key to create
  • -t type  Specify type of key to create

DSA type keys, you will note, have a key length of exactly 1024. As a result, I choose RSA with a long key. My recommendation is that you take 2048 as a minimum length. I am pretty paranoid, and I have a strong background in cryptography, but I have never used a key longer than 4096.

The longer the key, the more math the computer must perform while establishing the session. After the session is established, then one of the block-ciphers discussed above performs all of the crypto. If you are making a key for a slow device (like a PDA) or a microcontroller based device, then use a shorter key length. Regardless, actually changing the keys regularly is a more secure practice than making a large one that is never changed.

$ ssh-keygen -b 3608 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/erikheidt/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/erikheidt/.ssh/id_rsa.
Your public key has been saved in /Users/erikheidt/.ssh/id_rsa.pub.
The key fingerprint is:
43:69:d8:8e:c4:af:f8:8b:5a:2d:db:75:91:fd:06:be erikheidt@Trinity.local
The key's randomart image is:
+--[ RSA 3608]----+
|                 |
|     . o .       |
|      + =        |
|     . *   o     |
|      . S o o    |
|     o . . o o   |
|    + o . . . o  |
|   . * . .   o   |
|  ..o +.    E    |
+-----------------+

Now, make sure your .ssh directory is secured properly…

$ chmod 700 ~/.ssh

Next, you need to copy the public key (only) to the server or remote host you wish to login to.

$ cd ~/.ssh

$ scp id_rsa.pub YourUser@Hostname

Now we have copied the file up to the server….

Part 2 – On the Server or remote host….

Logon to the target system (probably using a password) and then set things up on that end…

$ ssh YourUser@Hostname

$ mkdir .ssh
$ chmod 700 .ssh
$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Done ! Your next login should use certificate based authentication !

I hope this posting on SSH was useful.

Cheers, Erik