Command line access, non console. But what if you just want to log into the Linux operating system. Well, there are options, but generally that's going to happen over a network and you will most likely initiate an SSH session. So we've covered that fairly well in the past. Now, if you're on a Linux or on a Unix system, you could just straight away SSH right to the other Linux instance. If you're on Windows, then you're most likely going to use a utility called PuTTY. If you don't know what PuTTY is, check it out at the URL that's on the screen. I clipped it, Ibm.biz/putty-download for more details and for the download. Now, I'll close out the command line access lessons by going into more detail about a popular utility called Sudo, that's spelled out as S-U-D-O. Some folks may call it pseudo. Generally it's Sudo, it stands for superuser do, or more recently switch user do. Now, remember that the most powerful ID in Linux is root, and in some instances the Linux variance that don't allow login for the root user, this is going to be something that's really important for you to know. In general and all Linux systems, it's not recommended that user login as root anyway. So how do you get access to root to perform administrative tasks that require root authority? Well, Sudo is the utility that gives users temporary authority to perform a task that otherwise is outside their authority. Basically, you temporarily gain root authority. The Sudo authority or the Sudo utility rather is controlled via a configuration file. That configuration file is called /etc/sudoers, S-U-D-O-E-R-S. The people who will be Sudoing. This file is only to be edited using the Vi Sudo command. So you notice there are a lot of specifics around using Sudo, but it's a security feature. Now, within that file there are various directives that identify users commands and other aliases that control who can run what commands. Now, to use Sudo, the syntax is very straightforward. It's Sudo and then whatever the command is that you want to do. The user is expected to enter their password, not root's password. So you're never compromising the root password here all you're doing is allowing the Sudo facility to verify against the Sudoers file if the person who is attempting to run this command is authorized to run that command. Actually, it might be easier to just have a look at an example where a non-root user is granted authority to add, say, other users to Linux system. In this example, what I'm going to show is how you would grant a non-root user, like bmiller4 in this case, the authority to do something that that user does not have the authority to do. In the example, I'm going to specifically choose user add and user delete capabilities. I want to useradd Fred. Comes back and says, no, you don't have authority as bmiller4 to do that. Remember though, Sudo is a way that I can perform tasks that require root authority but it comes back and says, hey, sorry, you're not in the Sudoers file. So let me switch over to a root session, let me VI Sudo. I'm going to look at the Sudoers file, and I've already primed up the command that's needed or the entry that's needed. I'm going to allow bmiller4 on all systems, all groups, the ability to add and delete users. So I'll save that, switch back to my bmiller4 session and redo my user add. It asks my password again, I enter it and now the user Fred is there. If I grip Fred out of etc password, you'll see that the user is there. Now, if I decide, you know what, I really don't want Fred to have access to this system, I user down and the user's gone. Now as you saw in the example, specific commands were authorized for specific user. The etc Sudoers file allows for a more general assignment of authorization, where a user or a group of users are granted authority to a subset of commands, or maybe all commands.
