Join Jon Peck for an in-depth discussion in this video Logging in using Secure Shell (SSH), part of Learning Linux for PHP Developers (2014).
When managing servers, it's important to be able to securely perform work without risking your credentials or data. One of the most common methods is to use a secure shell. SSH is an encrypted network protocol between two computers across a network. The encryption provides secure data communication to allow work from potentially unsecure or untrusted networks. Even if you're feeling safe at home or your office, there's a lot of steps across many networks between you and whatever server you're communicating with.
I'm not trying to scare you. Just teach you to mitigate the risk. One of the things SSH is used for, is a remote command line login with text interactions. So no graphics, and the remote command line is most commonly used to manage servers. Another purpose for SSH is remote command execution, which is useful for quickly executing one-off commands, such as starting or stopping a process. SSH uses a secure algorithm known as public key cryptography to encrypt communication. The way it works is by generating two linked keys. A public key, which is shared and copied freely with servers that you want to interact with, and a private key that is kept secret and secure, such as only on your computer.
Practically speaking, the public on a remote server is used to encrypt communication and only someone with a private key can encrypt and read the result. What's interesting about this technique is that the key that encrypts the data is not the key that decrypts it. So even if you have a copy of the public key, you won't be able to decrypt the data. There's a couple different ways to authenticate over SSH. The first and easiest to use way automatically generates public and private key pairs. This is handled transparently by your SSH client and the server, so your local machine will have a private key.
And the remote server will have a public key. A username and password are required to login to the remote machine so that authentication doesn't change. The second way uses a manually generated public-private key pair. This is a little bit more involved but the end result is that authentication does not require a password to log in to the target system. Instead the local private key must match a remote public key. Without it, the connection attempt will be rejected. This matching is done on a list called authorized keys, which contains all the public keys allowed to access a users account on a server.
I'm going to demonstrate authentication using both methods in a moment. While it may seem a bit extreme in the context of a local development environment, there are a few practical reasons to use SSH to manage local servers. First of all, it's extremely convenient especially in the context of better clients than the VirtualBox terminal, which we use to configure Ubuntu. It's not that VirtualBox is bad it's just limited in this particular application and it's a single purpose. Especially if you're trying to do things like copying and pasting, or trying to record your session history. Think of the VirtualBox screen like a computer monitor, it presents information but doesn't allow you to interact with it.
SSH is also compatible with a number of development tools including integrated development environments like PhpStorm, or utilities like the drupal command line shell Drush. Getting in the habit of using SSH is also a best practice for connecting to remote servers. When we connect to the Sandbox via SSH, there are a couple of configurations to keep in mind. The first is the port, which we've set to 2222. Earlier we forwarded the port from 2222 on the host to port, just plain 22 on the guest using Virtual Box to prevent potential conflicts.
Next is the host name, which you probably guessed is sandbox.dev. Finally, the username and password will be the same as what was specified during the Ubuntu installation. When it comes to SSH clients, Mac users already have one built in. Just go to Applications, Utilities, and select the Terminal app. The SSH program is available from the command line. Windows, on the other hand, is unique in that it's the only major operating system that does not have a built-in SSH client. Instead, you can use the open source program PuTTY, which hopefully you downloaded as you watched the introduction.
I'm going to demonstrate using both the Mac and Windows clients in separate videos, as the techniques are a little different. After that point, all the commands will be the same. So, there won't be any need to have operating system specific instructions.
The demonstrations are performed with the Ubuntu LTS distribution of Linux, but the skills taught here are also applicable to other Linux distributions. Every command is described in detail in context, and a comprehensive quick reference is provided for convenience.
- What is Linux, and why should I use it?
- What's a LAMP, and why does it matter?
- Creating and configuring a virtual machine
- Working with the Linux command line
- Configuring the servers, including Apache virtual hosts
- Building a development server dashboard
- Using PHP package managers like Composer and PEAR
- Installing Drupal, WordPress, and more on the server
- Self-hosting Git repositories, including a web interface
- Enhancing the server with debugging and profiling
- Exporting a virtual appliance to use on another machine
- Server troubleshooting techniques
Skill Level Beginner
Q: The pecl installation of uploadprogress fails, saying it is not a valid package archive. How can I install uploadprogress?
A: There is a bug in Ubuntu's pecl that was introduced after the course was recorded; the workaround command is "sudo pecl install -Z uploadprogress"
Q: Where can I get the exact versions of the software used in this course?
Q: In Windows, git operations ask for a password. Why?
A: Make sure that pagent (PuTTY agent) is running and has the private key loaded. See Chapter 3, movie 4 for details.