Table of Contents for
Linux in a Windows World

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Linux in a Windows World by Roderick W Smith Published by O'Reilly Media, Inc., 2005
  1. Cover
  2. Linux in a Windows World
  3. Dedication
  4. Preface
  5. Contents of This Book
  6. Conventions Used in This Book
  7. Using Code Examples
  8. Comments and Questions
  9. Safari Enabled
  10. Acknowledgments
  11. I. Linux’s Place in a Windows Network
  12. 1. Linux’s Features
  13. Linux as a Server
  14. Linux on the Desktop
  15. Comparing Linux and Windows Features
  16. Summary
  17. 2. Linux Deployment Strategies
  18. Linux Desktop Migration
  19. Linux and Thin Clients
  20. Summary
  21. II. Sharing Files and Printers
  22. 3. Basic Samba Configuration
  23. The Samba Configuration File Format
  24. Identifying the Server
  25. Setting Master Browser Options
  26. Setting Password Options
  27. Summary
  28. 4. File and Printer Shares
  29. Printing with CUPS
  30. Creating a Printer Share
  31. Delivering Printer Drivers to Windows Clients
  32. Example Shares
  33. Summary
  34. 5. Managing a NetBIOS Network with Samba
  35. Enabling NBNS Functions
  36. Assuming Master Browser Duties
  37. Summary
  38. 6. Linux as an SMB/CIFS Client
  39. Accessing File Shares
  40. Printing to Printer Shares
  41. Configuring GUI Workgroup Browsers
  42. Summary
  43. III. Centralized Authentication Tools
  44. 7. Using NT Domains for Linux Authentication
  45. Samba Winbind Configuration
  46. PAM and NSS Winbind Options
  47. Winbind in Action
  48. Summary
  49. 8. Using LDAP
  50. Configuring an OpenLDAP Server
  51. Creating a User Directory
  52. Configuring Linux to Use LDAP for Login Authentication
  53. Configuring Windows to Use LDAPfor Login Authentication
  54. Summary
  55. 9. Kerberos Configuration and Use
  56. Linux Kerberos Server Configuration
  57. Kerberos Application Server Configuration
  58. Linux Kerberos Client Configuration
  59. Windows Kerberos Tools
  60. Summary
  61. IV. Remote Login Tools
  62. 10. Remote Text-Mode Administration and Use
  63. SSH Server Configuration
  64. Telnet Server Configuration
  65. Windows Remote-Login Tools
  66. Summary
  67. 11. Running GUI Programs Remotely
  68. Using Remote X Access
  69. Encrypting X by SSH Tunneling
  70. VNC Configuration and Use
  71. Running Windows Programs from Linux
  72. Summary
  73. 12. Linux Thin Client Configurations
  74. Hardware Requirements
  75. Linux as a Server for Thin Clients
  76. Linux as a Thin Client
  77. Summary
  78. V. Additional Server Programs
  79. 13. Configuring Mail Servers
  80. Configuring Sendmail
  81. Configuring Postfix
  82. Configuring POP and IMAP Servers
  83. Scanning for Spam, Worms, and Viruses
  84. Supplementing a Microsoft Exchange Server
  85. Using Fetchmail
  86. Summary
  87. 14. Network Backups
  88. Backing Up the Linux System
  89. Backing Up with Samba
  90. Backing Up with AMANDA
  91. Summary
  92. 15. Managing a Network with Linux
  93. Delivering Names with DNS
  94. Keeping Clocks Synchronized with NTP
  95. Summary
  96. VI. Appendixes
  97. A. Configuring PAM
  98. The PAM Configuration File Format
  99. PAM Modules
  100. Sample PAM Configurations
  101. Summary
  102. B. Linux on the Desktop
  103. Configuring Applications and Environments
  104. Running Windows Programs in Linux
  105. File and Filesystem Compatibility
  106. Font Handling
  107. Summary
  108. Index
  109. Colophon

SSH Server Configuration

In most cases, SSH is the preferred remote text-mode access method; this protocol implements security at its core, and it’s become almost as widely available as Telnet. SSH is, though, a much more complex protocol, and its server program implementations reflect this fact. Configuring and running an SSH server is therefore a more complex task than configuring and running a Telnet server, although the default SSH server configurations for most Linux distributions require little work to get running.

SSH Server Options for Linux

If you want to use SSH, you must first decide which of several SSH server packages to use:

SSH Tectia

SSH was developed by a company called SSH Communications Security (http://www.ssh.com), which sells its commercial SSH server under the name SSH Tectia. (Versions prior to 4.0 used the name SSH alone.)

OpenSSH

This may be the most popular SSH server in Linux. It was originally developed in association with OpenBSD, but most Linux distributions include it under the package name openssh or something similar. Its official web site is http://www.openssh.org, and it’s distributed under the BSD license.

FreSSH

This server, headquartered at http://www.fressh.org, is an independent SSH implementation that’s distributed under the BSD license.

lsh

For GPL fans, lsh is an SSH implementation under that license. You can learn more at http://www.lysator.liu.se/~nisse/lsh/.

Any of these servers should work well and interoperate with common SSH client programs, but their configuration details differ. This chapter describes OpenSSH configuration, which is similar to SSH Tectia in its configuration file locations and formats. If you elect to use FreSSH or lsh, you need to consult your server’s documentation. If you need more information on SSH than is in this chapter, consult the package’s manpages or a book on the subject, such as SSH, The Secure Shell: The Definitive Guide (O’Reilly).

Tip

SSH has seen protocol version changes over time. As I write, SSH Version 2 is the latest major protocol release in widespread use. Older systems may require use of SSH Version 1, but its use isn’t recommended. Major SSH servers should support both protocols, but configuration options are available to disable one or the other version.

Configuring an SSH Server

Once you’ve installed your SSH server package, you should look for its configuration file: /etc/ssh/sshd_config. Do not confuse this file with the configuration file for your SSH client program, /etc/ssh/ssh_config. This one-character difference in filenames can lead to a great deal of confusion if you don’t notice it.

The OpenSSH configuration file format is fairly straightforward: non-comment lines begin with a keyword and end with an argument. Comment lines are denoted by a leading hash mark (#). For the most part, the default SSH configuration should work reasonably well for most installations; however, you might want to look through the file to be sure everything’s set reasonably. Pay particular attention to these options:

AllowTcpForwarding

This option defaults to yes, which tells the server it may forward connections to ports specified by the client. This is a useful feature if you want to use SSH to tunnel other protocols. Disabling it might seem to be one way to improve security, but if users have shell access, they can install their own port forwarders, so disabling this feature isn’t likely to provide any significant security benefit.

AllowUsers

You can provide a list of users who are given access by using this option. This may be a handy security tool if only some users should have remote access. (A similar option for groups is called AllowGroups.)

Banner

If you pass a filename to this option, OpenSSH displays its contents to the client before authenticating the user.

Compression

This option takes a yes or no argument, which tells the server whether to accept a client request to compress data transfers. The default value is yes, which is usually desirable; however, if your server has a weak CPU, you might want to set this value to no.

DenyUsers

This option is the opposite of AllowUsers; you can blacklist specific users by listing them as arguments. A similar option for groups is DenyGroups.

GatewayPorts

This option defaults to no, which causes remote port forwardings to bind only to the loopback address (127.0.0.1). For some tunneling applications, though, these forwards should bind to all local network addresses, which requires this option to be set to yes.

KerberosAuthentication

If set to yes, this option tells SSH to try to validate a user’s password with the help of a Kerberos server. The default value is no.

ListenAddress

This option takes a hostname or IP address, optionally followed by a colon and a port number (as in 192.168.1.7 or 192.168.1.7:22) to specify the network hardware to which the server should bind. If this option is not specified, SSH binds to all network interfaces. To bind to multiple interfaces but not to all of them, you can provide multiple ListenAddress lines.

LogLevel

This option determines how much information the server logs. Possible values, in increasing log level, are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3, with the default being INFO.

PasswordAuthentication

This option, which defaults to yes, determines whether the system should accept passwords for authentication.

PermitRootLogin

This option tells SSH whether and under what circumstances to accept direct root logins. The default value is yes, but you may want to set this option to no to reduce the risk of abuse. (You can still log in as a normal user and run su, sudo, or other tools to administer a Linux system.) Intermediate values are without-password, which disables password-based authentication in favor of public key authentication, and forced-commands-only, which disables root logins but permits public key authentication only for running specific commands. That can be handy for enabling remote backups or other tasks that require running specific programs as root.

Protocol

You can tell SSH which protocol levels to support by passing their numbers. If you want to support both Versions 1 and 2, you must separate the numbers with a comma, as in 2,1. Order is unimportant; protocol preference is set by the client.

PubkeyAuthentication

This option takes a yes or no value and defaults to yes. It determines whether the server accepts public key authentication. This option affects SSH Version 2 only.

RSAAuthentication

This option is similar to PubkeyAuthentication, but if affects protocol Version 1 only. (SSH protocol Versions 1 and 2 require different public key file formats.)

UseDNS

If set to yes (the default), this option causes the server to look up a client’s hostname using its IP address and then look up the IP address from that hostname and check that it matches the IP address the client uses. This improves security because it makes it harder for an attacker to pretend to be an authorized client, however, this option can also cause problems if your DNS configuration is broken or slow.

UsePAM

This option defaults to no, but you may need to change it to yes if you want to use an NT domain controller, LDAP server, or other advanced authentication tools, as described in Appendix A. If you do this, the documentation recommends also setting PasswordAuthentication to no.

X11Forwarding

This option, which defaults to no, tells SSH not to forward X traffic. This configuration helps protect the client’s X server from attack; however, to use SSH as part of a remote X access method, as described in Chapter 11, you must change this option to yes.

SSH in general, and the OpenSSH server implementation in particular, is complex enough that this list is incomplete. If you need to perform more advanced tasks, you may need to consult the relevant documentation.

Launching an SSH Server

You can launch an SSH server using a super server, much as you launch a Telnet server; however, SSH is slower to start up than is Telnet, so the more common approach is to start SSH using a SysV or local startup script. Most Linux SSH packages include such a script, typically called ssh or sshd and stored in /etc/init.d or /etc/rc.d/init.d. To start or stop the SSH server on a one-time basis, pass the start or stop option to the SysV startup script, and most distributions respond with some sort of status report:

# /etc/init.d/sshd start
 * Starting sshd...                      [ ok ]

Most distributions provide a tool called chkconfig to manage which servers start in common runlevels; to tell your system to start the SSH server, type a command such as chkconfig --add sshd. Consult distribution-specific documentation if this command doesn’t work or if you need to perform other special tasks. Instead of chkconfig, Gentoo Linux uses rc-update; you’d type rc-update add sshd default to add the SSH server to the default runlevel.

Once the server is running, you should be able to access it from another computer:

$ ssh linnaeus@mandragora.pangaea.edu
Password:
Last login: Mon Dec 27 11:24:40 2004 from pointer.example.com
Have a lot of fun...
linnaeus@mandragora:~>

This example uses the username@hostname form of address to specify both the username and the server’s hostname. In many cases, you can omit the username@ part, though; Linux’s ssh clients use your current username if you don’t specify one. To execute a single command rather than log into the remote system, specify the command after the other options, as in ssh root@mandragora.pangaea.edu shutdown now -r to shut down and reboot the remote computer. (Note that this particular example requires that direct root access be enabled.)