Posted in 
/etc/ssh/sshd_config
The configuration of SSH client is stored in the text file /etc/ssh/ssh_config
The configuration of the SSH server daemon is stored in the text file /etc/ssh/sshd_config. An important setting in this file is PermitRootLogin=No. This is the default setting in ESX 3.x and it is recommended that you keep the setting at “No”. This way you have an audit trail and see exactly who is logging in, rather than just “root”. You can quickly what the setting is by using a grep operation on the file as shown:
# grep Permit /etc/ssh/sshd_config
If you do edit the file to change this setting to Yes, then make sure you restart the daemon for the changes to take effect using the command:
# service sshd restart
It is also possible to explicitly allow or deny specific users to the SSH daemon. The headings in the ssh_config file are DenyUsers and AllowUsers.
su
This command is the switch user utility. Think of it as the command line equivalent of Windows Fast User Switching!
When it used without parameters, we are specifying to switch to the user root. However, we can use the su command to switch shell to any user account that we know the password of. In the first example, we are logged in as the user kevin and we are switching to user ali.
[kevin@esx1host kevin]$ su ali
Password:
[ali@esx1host kevin]
In this second example, we are switching from being logged on as a user called sara to being logged on as root. Notice to switch to root, we don’t need to specify a username.
[sara@esx1host sara]$ su -
Password:
[root@esx1host root]#
If we restrict the built-in user account root from logging in over the SSH protocol, then we are forcing remote users to authenticate as themselves and then su to run privileged commands if need be, thus leaving a decent audit trail. The downside being that those users would still know the root account password.
If you would like to restrict the use of the su command, then we can limit it to the members of a specific group called wheel. This group is defined in the /etc/group file by default and it’s membership can be modified by root. In order to limit su to the wheel group members we need to modify a configuration file called /etc/pam.d/su
There is a single line in this file that needs to be uncommented to limit the use of su. The line is shown below as it appears it that file, all that is required is the removal of the # symbol at the start of the line.
#auth required /lib/security/$ISA/pam_wheel.so user_uid
The attempts to switch to the root account are logged in /var/log/messages.
sudo
The downside of the su command is that the operators who elevate their privilege to root are now root. They have full privilege, they know the root password, there is no granularity of delegation of privilege.
Allows delegation of administration in terms of certain commands that normally only a particular user can execute (usually root). So if the user ali had been given the authority to run vmkfstools, then sudo would be used like:
[ali@esx1 ali]$ sudo vmkfstools
The vmkfstools command would then run under the security context of the root user. The superb feature of this tool is that the user ali does not need to know or supply the root password to be able to run the delegated command. Further, we keep an audit trail of when sudo was invoked in /var/log/secure.
The sudo tool uses the lookup file /etc/sudoers to determine which users can perform which commands. We do not edit this file with a regular text editor like vi or nano, instead we use the tool visudo.
visudo
This is the vi text editor with extras. When launched, it automatically opens and locks for exclusive edit, the /etc/sudoers file. The point of visudo is to ensure we always edit the right file as the location of the sudoers file differs between nix distributions, but this command is constant and will utilise the right sudoers file for the distribution being used.
A great benefit of using visudo over regular vi, is that it performs some basic syntax checking for us!
w
Great for viewing logged on console users.
[root@esx1host firewall]# w
12:07:45 up 4 days, 2:16, 3 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root tty1 - Fri10am 4days 0.02s 0.02s -bash
root tty2 - Fri 9am 4days 0.06s 0.06s -bash
root pts/0 remote7.lab.vmwa 9:29am 0.00s 0.06s 0.00s w
who
This command allows use to view who is logged onto the service console either interactively at the console or via an SSH session. The who command without parameters gives us the basics.
[root@esx1host firewall]# who
root tty1 Jul 25 10:30
root tty2 Jul 25 09:56
root pts/0 Jul 29 09:29 (remote7.lab.b2v.net)
If we want to see all the details of users we can use the -a switch to show all data. We tend to combine -a with -H (i.e. -aH) to display column headers making it easier to read and interpret.
[root@esx1host firewall]# who -aH
vmkload_mod
This command will load and unload VMkernel modules on the fly. The results of this load/unload will happen as you type it and will only be valid for the current booted session. So this command is superb for troubleshooting as we can load and unload modules, e.g. network drivers.
In the following example, we are examining the options for the Intel network driver (e1000) with the -s (show parameters) switch and then unloading it using -u (thereby interrupting network operations on that physical interface temporarily) and then loading it again with a new option. Notice to load a VMkernel parameter, we just supply the module name to the vmkload_mod command as a parameter listing any module-specific options as further parameters.
[root@esx1host]# vmkload_mod -s e1000
Using /usr/lib/vmware/vmkmod/e1000.o
heap_initial int, description “Initial heap size allocated for the driver.”
heap_max int, description “Maximum attainable heap size for the driver.”
reset_wait_ms int array (min = 1, max = 32)
[root@esx1host]# vmkload_mod -u e1000
[root@esx1host firewall]# vmkload_mod e1000 RxIntDelay=32
Using /usr/lib/vmware/vmkmod/e1000.o
Module load of e1000 succeeded.
If you were experimenting with a driver setting to determine the right setting for the environment, then you may be loading and unloading a module a number of times. Once we were happy we had found the correct setting, it is likely we would want to make this change persistent, i.e. we would want it to take effect for each time the kernel module is loaded at server boot time. For that, we should use esxcfg-module command.
minicom
This is a great utility for talking to serial attached devices; we think of it as HyperTerminal for Linux. Where we have found this particularly useful is for command line administration of your storage array. For example, if you had an HP MSA1000 attached to you ESX host and attached the serial cable to the unit and your host, then you could manage LUN presentation from the service console command line.
Minicom uses a configuration file to determine bit rates etc. This configuration file is placed in the /etc directory. We normally create the file with a meaningful name e.g. minirc.com1, so to launch the tool we enter
# ./minicom com1
The contents of the minirc.com1 file would typically be:
pr port /dev/ttyS0
pu baudrate 19200
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
http://www.cisl.ucar.edu/nets/intro/staff/siemsen/tools/minicom.html
vi
We can’t talk about the command line without talking about vi. This is the simple but powerful text editor in Linux and UNIX. People tend to love it or hate it. Either way, it’s nearly always there in any *nix implementation and just by memorising a few commands you can be up and running with it. If you can use Windows Notepad, you can use vi!
vi filename
The first thing that throws you is that to enter text into your file, you need to press “i” for Insert mode. You can then enter your text just as any other text editor. When you are done with text entering, just press the Escape (Esc) key to come out of insert mode. If you are happy with your file, then we need to Write & Quit (wq). To enter commands in this command line editor, rather than having menus, we have a command prompt in the application. To reach the vi command prompt, simply enter “:” – the colon character which will automatically place your cursor at the bottom of the session. Here you can enter the “wq” command to write and quit the editor. That’s it!
Here is a summary of the vi commands
i Changes to insert mode where you can edit the text
:wq Write the file and quit the editor
:q! Quit the editor without saving changes
SHIFT ZZ Quit the editor and save any changes made – just a fast way of doing “:wq”
Esc key Exits the current mode, e.g. out of insert mode back to view mode.
These commands are just extra if you have the inclination to learn!
/ search – if you entered /failed then the cursor would move to the first instance of “failed in the text
$ jumps to the end of the opened file
yy copy – it’s y for yank!
dd delete a line (cut) if you precede this with a number e.g. 8dd, then it would delete 8 lines
p paste
%s/old/new/g substitute any occurrences of the world “old” with the world “new”
http://staff.washington.edu/rells/R110/
nano
Another text editor, more friendly than vi but you should use –w to avoid word wrap.
ntpdate
If you want to synchronise your service console clock with the defined time server, you can use this command with the -u switch.
ntpdate -u timeserver.local
ntpq
This queries the state of the ntp service. Watch for the back ticks used in the parameters, they are not single quotes!
date
If we are checking the time and date of our ESX Service Console, then the date command is very useful. Just entering the “date” command returns what the service console thinks the current date is.
If the date is incorrect and you wish to reset it you would enter the command with the -s switch and specify date in mm/dd/yyyy format.
# date -s “12/29/2007 23:48″
Once you have set the date, you will want to ensure that the hardware clock matches your newly entered date. We can do this with the hwclock command described below.
hwclock
We can use this command to synchronise the server hardware clock with the date we set in the service console. If you enter the command with no parameters then the value of the hardware clock is displayed.
# hwclock
If we want to synchronise the hardware clock with the service console date and time, we use the following:
# hwclock -systohc
