This post is part 30 of 39 in the series Taming the Terminal

In the previous instalment we saw how we can use SSH to execute a single command on a remote computer, or, to get a command shell on a remote computer. We also saw how SSH uses host keys to protect us from man-in-the-middle (MITM) attacks.

In this instalment we’re going to look at how we can improve both SSH security and convenience with SSH keys.

Read more

Tagged with:

This post is part 29 of 39 in the series Taming the Terminal

In the previous six instalments we looked in detail at how TCP/IP networks tick. In these instalments we worked our way up from the bottom of the four-layer TCP/IP network model to the top, finishing off with a look at two protocols in the Application Layer at the top of the stack. Those two protocols, DHCP & DNS exist in the top layer, but are different to most other top layer protools in that they can reasonably be described as forming part of the infrastructure of the internet. The email and web protocols may site within the same network layer, but they still rely on DNS to function.

For the remainder of the networking section in this series we’ve moving away from infrastructure-like protocols, and focusing on the user-facing Application Layer protocols. The first of these we’ll be looking at is the Secure Shell, or SSH. This protocol is one of the absolute work-horses of the internet, and a vital tool for all Linux, Unix, and OS X sysadmins.

At it’s simplest level SSH allows you to execute commands on a remote computer, but because it was designed around the concept of a secure tunnel between two systems, SSH has expanded to allow all kinds of advanced features. The least-generous description of this could be that SSH has become a kind of sysadmins fridgeoven. But I don’t buy that, I prefer the alternative interpretation – it simply makes sense not to re-invent the wheel, and to allow as much information as possible to flow throw the secure connection SSH provides between the two end-points.

Today we’re just going to start with the basics, but in future instalments we’ll move on to the more advanced features.

Read more

Tagged with:

This post is part 28 of 39 in the series Taming the Terminal

In part 23 of n we took a big-picture look at how TCP/IP networking works. As a quick reminder, the most important points were:

  • Our computer networks use a stack of protocols known as TCP/IP
  • We think of the stack of protocols as being broken into four layers:
  • The Link Layer – lets computers that are on the same network send single packets of data to each other
  • The Internet Layer – Lets computers on different networks send single packets of data to each other
  • The Transport Layer – lets computers send meaningful streams of data between each other
  • The Application Layer – where all the networked apps we use live
  • Logically, data travels across the layers – HTTP to HTTP, TCP to TCP, IP to IP, ethernet to ethernet, but physically, data travels up and down the stack, one layer to another, only moving from one device to another when it gets to the Link Layer at the very bottom of the stack.
  • Since that big-picture introduction we’ve looked at the first three layers in detail, and we’ve also looked at two layer-4 protocols that function as part of the network infrastructure – DHCP for the automatic discovery of network settings, and DNS for mapping domain names to IP addresses. Later in the series we will move on to look at some more layer 4 protocols, but before we do I want to consolidate what we’ve learned so-far into a strategy for debugging network problems. In short – how to get from a vague complaint like “the internet is broken” to a specific problem that can be addressed.

    Read more

    Tagged with:

    This post is part 26 of 39 in the series Taming the Terminal

    In part 23 of n we took a big-picture look at how TCP/IP networking works. As a quick reminder, the most important points were:

    • Our computer networks use a stack of protocols known as TCP/IP
    • We think of the stack of protocols as being broken into four layers:
    • The Link Layer – lets computers that are on the same network send single packets of data to each other
    • The Internet Layer – Lets computers on different networks send single packets of data to each other
    • The Transport Layer – lets computers send meaningful streams of data between each other
    • The Application Layer – where all the networked apps we use live
  • Logically, data travels across the layers – HTTP to HTTP, TCP to TCP, IP to IP, ethernet to ethernet, but physically, data travels up and down the stack, one layer to another, only moving from one device to another when it gets to the Link Layer at the very bottom of the stack.
  • In the previous instalment we looked at how IP subnet works. The key takeaway was that a computer needs a minimum of three settings correctly configured to be able to participate in an IP network: an IP address, a subnet mask, and a default gateway (the IP address of the router providing access outside the subnet). We also looked at how to read those three settings from your Mac using the GUI and the Terminal. Finally, we noted that historically, those settings had to manually configured, but that today, almost all computers acquire those settings automatically. In this instalment we’ll look at the protocol that makes that possible, the Dynamic Host Configuration Protocol, or DHCP.

    Read more

    Tagged with:

    This post is part 25 of 39 in the series Taming the Terminal

    In part 23 of n we took a big-picture look at how TCP/IP networking works. As a quick reminder, the most important points were:

    • Our computer networks use a stack of protocols known as TCP/IP
    • We think of the stack of protocols as being broken into four layers:
    • The Link Layer – lets computers that are on the same network send single packets of data to each other
    • The Internet Layer – Lets computers on different networks send single packets of data to each other
    • The Transport Layer – lets computers send meaningful streams of data between each other
    • The Application Layer – where all the networked apps we use live
  • Logically, data travels across the layers – HTTP to HTTP, TCP to TCP, IP to IP, ethernet to ethernet, but physically, data travels up and down the stack, one layer to another, only moving from one device to another when it gets to the Link Layer at the very bottom of the stack.
  • In the previous instalment we focused on the lowest of the four layers, the link layer, and looked at how ethernet and ARP work. In this instalment we’ll move one layer up the stack and take a closer look at the IP protocol. A concept absolutely central to IP’s operation is that of related groups of IP addresses known as IP Subnetworks or just subnets. This is the concept we’ll be focusing on in this instalment.

    Read more

    Tagged with:

    This post is part 24 of 39 in the series Taming the Terminal

    In the previous instalment we took a big-picture look at how TCP/IP networking works. As a quick reminder, the most important points were:

    • Networking is complicated!
    • Our computer networks use a stack of protocols known as TCP/IP
    • We think of the stack of protocols as being broken into four layers:
    • The Link Layer – lets computers that are on the same network send single packets of data to each other
    • The Internet Layer – Lets computers on different networks send single packets of data to each other
    • The Transport Layer – lets computers send meaningful streams of data between each other
    • The Application Layer – where all the networked apps we use live
  • Logically, data travels across the layers – HTTP to HTTP, TCP to TCP, IP to IP, ethernet to ethernet, but physically, data travels up and down the stack, one layer to another, only moving from one device to another when it gets to the Link Layer at the very bottom of the stack.
  • In this instalment we’ll take a quick look at the lowest of these four layers – the Link Layer. Specifically, we’ll look at MAC addresses, the difference between hubs, switches, and routers, and the ARP protocol.

    Read more

    Tagged with:

    This post is part 23 of 39 in the series Taming the Terminal

    This instalment is the first in what will probably be quite a long mini-series on computer networking. Before we can look at the terminal commands that allow us to interact with the network, we need to gain an understanding of how computer networking works. This is a complex topic, ad there’s a lot to take in. The individual pieces don’t make sense without keeping the big-picture in mind, and yet the big picture doesn’t gel together until you start to understand the detail. Bearing that in mind, this instalment starts the series with a big-picture overview. We’ll flesh this overview out over the instalments that follow, adding in the detail that will hopefully make the whole thing click for you. Ultimately, it’s actually a very elegant design, but that elegance may not be immediately obvious!

    Read more

    Tagged with:

    This post is part 22 of 39 in the series Taming the Terminal

    This instalment is a little breather between the fairly heavy instalments on searching, and the upcoming set of instalments on networking. We’ll start with a look at some tips and tricks for getting the most out of BASH, and then transition to some tips and tricks for getting the most out of the OS X Terminal app.

    Read more

    Tagged with:

    This post is part 21 of 39 in the series Taming the Terminal

    This is the third and final instalment on searching. In the first instalment we learned how to search for text within files and streams using egrep. In the second we learned to search for files based on all sorts of criteria with the find command. In this final instalment we’ll start by looking at one last feature of find, its a ability to execute commands on the files it finds. Then we’ll end by looking at an OS X-only alternative to find that makes use of the Spotlight search index to really speed up searches.

    Read more

    Tagged with:

    This post is part 20 of 39 in the series Taming the Terminal

    In the previous previous instalment we looked at using egrep to search for a particular piece of text in a stream or file. egrep is often a great tool for finding a file you are looking for, but only if the file is a plain text file, and only if you are searching for that file based on its content. What if you want to search for files based on other criteria, like the last time the file was edited, or the name of the file, or the size of the file, or the type of the file etc.? For that you need a different command, for that you need find.

    Read more

    Tagged with:

    « go backkeep looking »