![]() | ![]() |
For example, password authentication is controlled by the keyword Password-Authentication, RSA public-key authentication by RSA-Authentication, and so forth, one keyword per technique. Values may be yes or no:Name_Of_TechniqueAuthentication
Early versions of SSH2 also used one keyword per authentication technique, but keywords were a bit more generic. Instead of RSAAuthentication, which mentions the algorithm RSA, the keyword was changed to PubKeyAuthentication without naming a specific algorithm.# SSH1, OpenSSH; deprecated for SSH2 RSAAuthentication yes
This left the door open for the support of other public key algorithms. The older keywords such as RSAAuthentication were still usable as synonyms for the more generic keywords. SSH2 today uses an entirely different syntax. Instead of creating a new keyword for each technique, it uses only two keywords, AllowedAuthentications and RequiredAuthentications. Each is followed by the names of one or more authentication techniques, for example:# SSH2 only, but deprecated PubKeyAuthentication yes
AllowedAuthentications specifies which techniques can be used to connect to this SSH server.[60] In contrast, RequiredAuthentications specifies which ones must be used.[61] A configuration line like:# SSH2 only; recommended technique AllowedAuthentications password,hostbased,publickey
[60]The order is not significant, since the client drives the authentication process.
[61]RequiredAuthentications was broken in SSH2 2.0.13, causing authentication to always fail. The problem was fixed in 2.1.0.
means that the server requires both public-key and password authentication before allowing a connection. The RequiredAuthentications list must be a subset of AllowedAuthentications: a required technique must also be allowed. By default, sshd2 allows only password and public-key authentication. If you think about it, these keywords are a little confusing, or at least not well-chosen. In practice, if you use RequiredAuthentications at all, it always has exactly the same value as AllowedAuthentications: there's no point in having a method allowed but not in the "required" set, since that method doesn't get you a connection. It would be more useful to be able to specify multiple subsets of the allowed methods, which are the combinations acceptable for authenticating a client. Table 5-1 displays the authentication-related keywords.# SSH2 only; recommended technique AllowedAuthentications publickey,password RequiredAuthentications publickey,password
Type | SSH1 | OpenSSH | New SSH2 | Old SSH2 |
---|---|---|---|---|
AllowedAuthentications |
No | No | Yes | No |
DSAAuthentication |
No | Yes [62] | No | No |
KerberosAuthentication |
Yes | Yes | No | No |
PasswordAuthentication |
Yes | Yes | Deprecated | Yes |
PubKeyAuthentication |
No | No | Deprecated | Yes |
RequiredAuthentications |
No | No | Yes | No |
RhostsAuthentication |
Yes | Yes | No | Yes |
RhostsPubKeyAuthentication |
No | No | No | Yes |
RhostsRSAAuthentication |
Yes | Yes | No | Yes |
RSAAuthentication |
Yes | Yes | Deprecated | Yes |
SKeyAuthentication |
No | Yes | No | No |
TISAuthentication |
Yes | Yes[63] | No | No |
[63]Actually means S/Key authentication, not TIS.We now describe how to enable and disable each type of authentication.
PasswordAuthentication works for SSH2, but this keyword is discouraged. Instead, use the keyword AllowedAuthentications with a value of password:# SSH1, OpenSSH; deprecated for SSH2 PasswordAuthentication yes
Normally, password authentication requires your ordinary login password. However, this may be changed by compile-time configuration. For SSH1, if Kerberos or SecurID support has been compiled into the server, password authentication changes to support Kerberos [Section 5.5.1.7, "Kerberos authentication"] or SecurID. [Section 5.5.1.9, "SecurID authentication"]# SSH2 only AllowedAuthentications password
The keyword RSAAuthentication works for SSH2, as does the more general-sounding keyword PubKeyAuthentication, which has the same function, but both are no longer recommended. Instead, use the keyword Allowed-Authentications with a value of publickey:# SSH1, OpenSSH; deprecated for SSH2 RSAAuthentication yes
OpenSSH provides public-key authentication for SSH-2 connections with the DSAAuthentication keyword:# SSH2 only AllowedAuthentications publickey
Public-key authentication is marvelously configurable for most Unix SSH implementations. See Chapter 8, "Per-Account Server Configuration" for details on tailoring authentication for individual accounts.# OpenSSH/2 only DSAAuthentication yes
Rhosts authentication can be useful, but unfortunately it also enables connections via the insecure r-commands, since it uses the same permission files. To eliminate this potential security risk, use the SSH-specific files /etc/shosts.equiv and ~/.shosts instead, deleting /etc/hosts.equiv and ~/.rhosts. You can also tell the SSH server to ignore all users' .rhosts and .shosts files with the keyword IgnoreRhosts. Permissible values are yes (to ignore them) or no (the default):# SSH1, OpenSSH RhostsAuthentication yes
Some subtleties: although the keyword name contains "Rhosts," remember that it applies to .shosts files as well. Also, although user files are ignored by Ignore-Rhosts, /etc/hosts.equiv and /etc/shosts.equiv remain in force. SSH1 and SSH2 also permit separate control over Rhosts authentication for root. The keyword IgnoreRootRhosts permits or prevents use of the superuser's .rhosts and .shosts files, overriding IgnoreRhosts:# SSH1, SSH2, OpenSSH IgnoreRhosts yes
Values of yes (ignore the files) or no (don't ignore) are permitted. If not specified, the value of IgnoreRootRhosts defaults to that of IgnoreRhosts. For example, you can permit all .rhosts files except root's:# SSH1, SSH2 IgnoreRootRhosts yes
You can also ignore all .rhosts files except root's:# SSH1 only IgnoreRhosts no IgnoreRootRhosts yes
Again, IgnoreRootRhosts doesn't stop the server from considering /etc/hosts.equiv and /etc/shosts.equiv. For stronger security, it's best to disable .rhosts access entirely. Rhosts authentication can be complicated by other aspects of your server machine's environment, such as DNS, NIS, and the ordering of entries in static host files. It may also open new avenues for attack on a system. [Section 3.4.2.3, "Trusted-host authentication (Rhosts and RhostsRSA)"]# SSH1 only IgnoreRhosts yes IgnoreRootRhosts no
[64]OpenSSH 2.3.0 doesn't yet support hostbased authentication for SSH-2 connections.SSH1 and OpenSSH use the keyword RhostsRSAAuthentication (surprise!) to enable or disable this type of authentication:
The keyword RhostsRSAAuthentication is accepted by sshd2, as is the more general-sounding keyword RhostsPubKeyAuthentication, which has the same function; however, both keywords are considered obsolete. Instead, use the keyword AllowedAuthentications with the value hostbased:# SSH1, OpenSSH; deprecated for SSH2 RhostsRSAAuthentication yes
# SSH2 only AllowedAuthentications hostbased
OpenSSH supports the same functionality, but reversed, with the IgnoreUser-KnownHosts keyword. The value yes causes the user's known hosts database to be ignored; the default is no:# SSH2 only UserKnownHosts no
Having sshd consult the user's known hosts database might be unacceptable in a security-conscious environment. Since hostbased authentication relies on the integrity and correct administration of the client host, the system administrator usually grants hostbased authentication privileges to only a limited set of audited hosts. If the user's file is respected, however, a user can extend this trust to a possibly insecure remote host. An attacker can then:# OpenSSH only IgnoreUserKnownHosts yes
# SSH2 only PgpSecretKeyFile secring.pgp
# SSH2 only IdPgpKeyName mykey
# SSH2 only IdPgpKeyFingerprint 48 B5 EA 28 80 5E 29 4D 03 33 7D 17 5E 2E CD 20
# SSH2 only IdPgpKeyId 0xD914738D
# SSH2 only PgpPublicKeyFile pubring.pgp
# SSH2 only: use any ONE of these PgpKeyName mykey PgpKeyFingerprint 48 B5 EA 28 80 5E 29 4D 03 33 7D 17 5E 2E CD 20 PgpKeyId 0xD914738D
If everything is set up properly, you are prompted for your PGP passphrase:$ ssh2 -i idpgp server.example.com
Enter your PGP passphrase, and authentication should succeed.Passphrase for pgp key "mykey":
[65]They use different versions of Kerberos: Kerberos-5 for SSH1, and Kerberos-4 for OpenSSH.First, note that Kerberos authentication is supported only if it is enabled at compile time. Unless the configuration option -- with-kerberos5 (SSH1) or -- with-kerberos4 (OpenSSH) is used, Kerberos support isn't present in sshd. Assuming the server supports it, Kerberos authentication is enabled or disabled by the keyword KerberosAuthentication with the value yes or no:
The default is yes if Kerberos support has been compiled into the server; otherwise, the default is no. Connections may be authenticated by Kerberos ticket or by password (authenticated by the Kerberos server) if password authentication is also enabled:# SSH1, OpenSSH KerberosAuthentication yes
Instead of checking against the local login password, sshd instead requests a Kerberos TGT for the user and allows login if the ticket matches the password.[66] It also stores that TGT in the user's credentials cache, eliminating the need to do a separate kinit.# SSH1, OpenSSH KerberosAuthentication yes PasswordAuthentication yes
[66]It also requires a successful granting of a host ticket for the local host as an antispoofing measure.If Kerberos fails to validate a password, the server optionally validates the same password by ordinary password authentication. This is useful in an environment where Kerberos is in use, but not by everyone. To enable this option, use the keyword KerberosOrLocalPasswd with a value of yes; the default is no:
Finally, the keyword KerberosTgtPassing controls whether the SSH server does Kerberos ticket-granting-ticket (TGT) forwarding:# SSH1, OpenSSH KerberosOrLocalPasswd yes
Its default value follows the same rule as KerberosAuthentication: if Kerberos support is compiled into the server, the default is yes, otherwise no. OpenSSH adds the keyword KerberosTicketCleanup, which deletes the user's Kerberos ticket cache on logout. Values are yes and no, and the default is yes, to perform the deletion:# SSH1, OpenSSH KerberosTgtPassing yes
# OpenSSH only KerberosTicketCleanup yes
See the file README.TIS in the SSH1 distribution for further details about TIS authentication. Additional information on Trusted Information Systems and authsrv can be found at:# SSH1 only TISAuthentication yes
http://www.tis.com/ http://www.msg.net/utility/FWTK/ http://www.fwtk.org/
More information on one-time passwords is found at:# OpenSSH only SkeyAuthentication no
http://www.ietf.cnri.reston.va.us/html.charters/otp-charter.html
http://www.sun.com/solaris/pam/OpenSSH includes support for PAM. SSH1 1.2.27 has been integrated with PAM by a third party, but the combination requires changes to the SSH1 source code. Details are found at:
http://diamond.rug.ac.be/sshd_PAM/
AFSTokenPassing causes OpenSSH to establish Kerberos/AFS credentials on the remote host, based on your existing credentials on the client (which you must have previously obtained using klog or kinit). This can be a necessity for using OpenSSH at all in an AFS environment, not just a convenience: if your remote home directory is on AFS, sshd needs AFS credentials to access your remote ~/.ssh directory in order to perform public-key authentication, for example. In that case, you may also need to use AFS tools to adjust the permissions on the remote ~/.ssh directory, to allow sshd to read what it needs to. Just make sure that others cannot read your sensitive files (~/.ssh/identity, any other private key files, and ~/.ssh/random_seed ). For more information on AFS, visit:# OpenSSH only KerberosAuthentication yes KerberosTGTPassing yes AFSTokenPassing yes
http://www.alw.nih.gov/Docs/AFS/AFS_toc.html http://www.faqs.org/faqs/afs-faq/
[67]This concept is true for the configuration keywords discussed in this section but not for trusted-host control files, e.g., ~/.rhosts and /etc/hosts.equiv. Each of these may in fact override the other. [Section 3.4.2.3, "Trusted-host authentication (Rhosts and RhostsRSA)"]
permits the local smith account and only the smith account, to receive SSH connections. The configuration file may have multiple AllowUsers lines:# SSH1, SSH2, OpenSSH AllowUsers smith
in which case the results are cumulative: the local accounts smith, jones, and oreilly, and only those accounts, may receive SSH connections. The SSH server maintains a list of all AllowUsers values, and when a connection request arrives, it does a string comparison (really a pattern match, as we'll see in a moment) against the list. If a match occurs, the connection is permitted; otherwise, it is rejected.# SSH1, SSH2, OpenSSH AllowUsers smith AllowUsers jones AllowUsers oreilly
WARNING: A single AllowUsers keyword in the configuration file cuts off SSH access for all other accounts not mentioned. If the configuration file has no AllowUsers keywords, the server's AllowUsers list is empty, and connections are permissible to all accounts.DenyUsers is the opposite of AllowUsers: it shuts off SSH access to particular accounts. For example:
states that the smith account may not receive SSH connections. DenyUsers keywords may appear multiple times, just like AllowUsers, and the effects are again cumulative. As for AllowUsers, the server maintains a list of all DenyUsers values and compares incoming connection requests against them. Both AllowUsers and DenyUsers can accept more complicated values than simple account names. An interesting but potentially confusing syntax supported by sshd1 and sshd2 is to specify both an account name and a hostname (or numeric IP address), separated by an @ symbol:# SSH1, SSH2, OpenSSH DenyUsers smith
Despite its appearance, this string isn't an email address, and it doesn't mean "the user jones on the machine example.com." Rather, it describes a relationship between a local account, jones, and a remote client machine, example.com. The meaning is: "clients on example.com may connect to the server's jones account." Although this meaning is surprising, it would be even stranger if jones were a remote account, since the SSH server has no way to verify account names on remote client machines (except when using hostbased authentication). For SSH1 and OpenSSH, wildcard characters are acceptable in the user and host portions of AllowUsers and DenyUsers arguments. The ? symbol represents any single character except @, and the * represents any sequence of characters, again not including @. For SSH2, you may use full regular expressions, although the syntax is a little different from usual to accommodate "fileglob" syntax as well; see Appendix A, "SSH2 Manpage for sshregex".# SSH1, SSH2 AllowUsers jones@example.com
WARNING: The SSH2 regular-expression language includes keywords with a colon character in them, such as [:digit:]. Using a colon in an SSH2 access-control pattern can cause a nasty, difficult-to-track-down problem: it is ignored, along with the rest of your configuration file! The problem is that the parser is a bit dumb and interprets the colon as introducing a labelled section of the file. The label doesn't match anything, and so the rest of the file, now included in the section, is silently ignored. You can avoid this problem simply by placing the pattern inside quotation marks:Here are some examples. SSH connections are permitted only to accounts with five-character names ending in "mith":Though undocumented, this quoting syntax works.AllowHosts "10.1.1.[:digit:]##"
SSH connections are permitted only to accounts with names beginning with the letter "s", coming from hosts whose names end in ".edu":# SSH1, SSH2, OpenSSH AllowUsers ?mith
SSH2 connections are permitted only to account names of the form "testN " where N is a number, e.g., "test123".# SSH1, SSH2, OpenSSH AllowUsers s*@*.edu
One unfortunate, glaring omission is that you can't specify IP networks with traditional "address/masklength" syntax, e.g., 10.1.1.0/28 to mean the addresses 10.1.1.0 through 10.1.1.15.[68] To restrict connections to come from this range of addresses with AllowHosts [Section 5.5.2.3, "Hostname access control"] is rather more verbose:# SSH2 only AllowUsers test[0-9]##
[68]In this notation, the mask specifies the number of 1 bits in the most-significant portion of the netmask. You might be more familiar with the older, equivalent notation giving the entire mask, e.g., 10.1.1.0/255.255.255.240.
or complicated:# SSH1 AllowHosts *@10.1.1.? *@10.1.1.10 *@10.1.1.11 *@10.1.1.12 *@10.1.1.13 AllowHosts *@10.1.1.14 *@10.1.1.15
Restricting to a network that falls on an octet boundary, of course, is easier:# SSH2 AllowHosts *@10.1.1.(?|(1[0-5]))
Note, though, that this can be easily circumvented; an attacker need only control a domain server somewhere and connect from a machine named 10.1.1.evil.org. A more effective statement is:# SSH1, SSH2 # Allow connections only from 10.1.1.0/24 AllowHosts *@10.1.1.*
Even this isn't foolproof. Address and hostname-based restrictions are weak restrictions at best; they should be used only as an adjunct to a strong authentication method. Multiple strings may appear on a single AllowUsers line. SSH1 and OpenSSH separate strings with whitespace; however, the syntax differs between SSH1/OpenSSH and SSH2:# SSH2 only AllowUsers "*@10.1.1.[:isdigit:]##"
and SSH2 separates them with commas, no whitespace permitted:# SSH1, OpenSSH AllowUsers smith jones cs*
AllowUsers and DenyUsers may be combined effectively. Suppose you're teaching a course and want your students to be the only users with SSH access to your server. It happens that only student usernames begin with "stu", so you specify:# SSH2 only AllowUsers smith,jones,cs*
Later, one of your students, stu563, drops the course so you want to disable her SSH access. Simply change the configuration to:# SSH1, SSH2, OpenSSH AllowUsers stu*
Hmm... this seems strange. The two lines appear to conflict because the first permits stu563 but the second rejects it. The server handles this in the following way: if any line prevents access to an account, the account can't be accessed. So in the preceding example, stu563 is denied access by the second line. Consider another example:# SSH1, SSH2, OpenSSH AllowUsers stu* DenyUsers stu563
It permits SSH connections to the smith account but denies connections to any account beginning with "s". What does the server do with this clear contradiction? It rejects connections to the smith account, following the same rule: if any restriction prevents access, such as the DenyUsers line shown, access is denied. Access is granted only if there are no restrictions against it. sshd can store at most 256 user strings for AllowUsers and 256 for DenyUsers. This undocumented static limit applies if the strings follow a single keyword (e.g., AllowUsers followed by 256 strings) or multiple keywords (e.g., 16 AllowUsers keywords with 16 strings each). That is, the limit is internal to the server, not related to the length of a line in the configuration file. Finally, here is a useful configuration example, expressed in SSH1 syntax:# SSH1, SSH2, OpenSSH AllowUsers smith DenyUsers s*
This restricts access for most accounts to connections originating inside the domain beach.net -- except for the accounts "walrus" and "carpenter", which may be accessed from anywhere. The @* following walrus and carpenter isn't strictly necessary, but it helps make clear the intent of the line. It's worth noting that hostnames in these access-control statements are dependent on the integrity of DNS, which is easily spoofed. If this is a concern, consider using IP addresses instead, even though maintenance might be more cumbersome.AllowUsers walrus@* carpenter@* *@*.beach.net
These keywords operate much like AllowUsers and DenyUsers. SSH1 and OpenSSH accept the wildcards * and ? within group names, whereas SSH2 accepts its usual regular expressions (see Appendix A, "SSH2 Manpage for sshregex"), and you may provide multiple strings per line:# SSH1, OpenSSH (separation by whitespace) AllowGroups faculty DenyGroups students secretaries # SSH2 only (separation by comma) AllowGroups faculty DenyGroups students,secretaries
Unfortunately, these directives apply only to the target user's primary group, the one listed in the passwd record for the account. An account may belong to other groups as well (e.g., by entry in the /etc/groups file or NIS map), but SSH doesn't notice. It's a pity: if supplementary groups were supported, you could easily designate a subset of SSH-accessible accounts by defining a group -- say, sshusers -- and configure the SSH server with AllowGroups sshusers. This feature also automatically prevents access to system accounts such as bin, news, and uucp that don't require SSH. Perhaps some SSH implementors will fix this someday. By default, access is allowed to all groups. If any AllowGroups keyword appears, access is permitted to only the primary groups specified (and may be further restricted with DenyGroups). As was the case for AllowUsers and DenyUsers, conflicts are resolved in the most restrictive way. If any AllowGroups or DenyGroups line prevents access to a given group, access is denied to that group even if another line appears to permit it. Also as before, there is a static limit of 256 strings that may follow Allow-Groups or DenyGroups keywords in the configuration file.# SSH1, OpenSSH AllowGroups ?aculty s*s # SSH2 only AllowGroups ?aculty,s*s
SSH1 and SSH2 provide the keywords AllowHosts and DenyHosts to restrict access by s host more concisely, getting rid of the unnecessary account-name wildcard:# SSH1, OpenSSH AllowUsers *@example.com DenyUsers *@example.com
The AllowHosts and DenyHosts keywords permit or prevent (respectively) SSH connections from given hosts.[69] As with AllowUsers and DenyUsers:# SSH1, SSH2 AllowHosts example.com DenyHosts example.com
[69]Finer-grained control is provided by the "from" option in authorized_keys. [Section 8.2.5, "Restricting Access by Host or Domain "] Each public key may be tagged with a list of acceptable hosts that may connect via that key.
This printing is controlled by the SilentDeny keyword. If its value is no (the default), the message is printed, but if the value is yes, the message is suppressed (i.e., silent denial):Sorry, you are not allowed to connect.
As a side effect, SilentDeny also prevents the failed connection attempt from appearing in the server's log messages. With SilentDeny turned off, you see this in the log:# SSH1 only SilentDeny no
When SilentDeny is turned on, these messages don't appear in the server logs. SilentDeny doesn't apply to any other access-control keywords (DenyUsers, DenySHosts, etc.), nor is it related to authentication.log: Connection from client.marceau.net not allowed. fatal: Local: Sorry, you are not allowed to connect.
[70]Even though the keywords have "SHosts" in their names, they apply also to .rhosts and /etc/hosts.equiv files.For example, the line:
forbids access by connections from badguy.com, but only when trusted-host authentication is being attempted. Likewise, AllowSHosts permits access only to given hosts when trusted-host authentication is used. Values follow the same syntax as for AllowHosts and DenyHosts. As a result, system administrators can override values in users' .rhosts and .shosts files (which is good, because this can't be done via the /etc/hosts.equiv or /etc/shosts.equiv files). As for AllowHosts and DenyHosts:# SSH1, SSH2 DenySHosts badguy.com
Permissible values for this keyword are yes (the default) to allow access to the root account by SSH, no to deny all such access, and nopwd (SSH1, SSH2) or without-password (OpenSSH) to allow access except by password authentication. In SSH1 and OpenSSH, PermitRootLogin applies only to logins, not to forced commands specified in authorized_keys. [Section 8.2.4, "Forced Commands "] For example, if root's authorized_keys file contains a line beginning with:# SSH1, SSH2, OpenSSH PermitRootLogin no
then the root account may be accessed by SSH to run the dump command, no matter what the value of PermitRootLogin. This capability lets remote clients run superuser processes, such as backups or filesystem checks, but not unrestricted login sessions. The server checks PermitRootLogin after authentication is complete. In other words, if PermitRootLogin is no, a client is offered the opportunity to authenticate (e.g., is prompted for a password or passphrase) but is shut down afterward regardless. We've previously seen a similar keyword, IgnoreRootRhosts, that controls access to the root account by trusted-host authentication. It prevents entries in ~root/.rhosts and ~root/.shosts from being used to authenticate root. Because sshd checks PermitRootLogin after authentication is complete, it overrides any value of IgnoreRootRhosts. Table 5-2 illustrates the interaction of these two keywords.command="/bin/dump" ....
IgnoreRootRhosts yes | IgnoreRootRhosts no | |
---|---|---|
PermitRootLogin yes | Yes, except by trusted-host | Yes |
PermitRootLogin no | No | No |
PermitRootLogin nopwd (nopassword) | Yes, except by trusted-host or password | Yes, except by password |
Several accounts may be specified on the same line, separated by commas, meaning that each of these accounts are individually restricted when accessed via SSH2:# SSH2 only ChRootUsers smith
The other keyword, ChRootGroups, works similarly but applies to all accounts in a given Unix group:# SSH2 only ChRootUsers smith,jones,mcnally
# SSH2 only ChRootGroups users,wheel,mygroup
WARNING: ChRootGroups only examines an account's primary group; supplementary groups aren't considered. This makes it a much less useful feature than it would otherwise be. Hopefully, a fuller implementation will come in the future.To make this chroot functionality work, you might need to copy some system files into the account in question. Otherwise the login might fail because it can't access needed resources, such as shared libraries. On our Linux system, we needed to copy the following programs and libraries into the account:
/bin/ls /bin/bash /lib/ld-linux.so.2 /lib/libc.so.6 /lib/libtermcap.so.2This sort of thing can be reduced by statically linking the SSH executables. SSH2 recently added a tool called ssh-chrootmgr to help with this process; unfortunately, it occurred too close to press time for us to review it. See the manpage for details.
If you are... | And you want to allow or restrict... | Then use... |
---|---|---|
User | Connections to your account by public-key authentication | authorized_keys [Section 8.2.1, "SSH1 Authorization Files "] |
Administrator | Connections to an account | AllowUsers, DenyUsers |
User | Connections by a host | authorized_keys from="..." option [Section 8.2.5.1, "Simulating "from" with SSH2 "] |
Administrator | Connections by a host | AllowHosts, DenyHosts (or AllowUsers, DenyUsers) |
User | Connections to your account by trusted-host authentication | .rhosts, .shosts |
Administrator | Trusted-host authentication | RhostsAuthentication, RhostsRSAAuthentication, IgnoreRhosts, AllowSHosts, DenySHosts, /etc/hosts.equiv, /etc/shosts.equiv |
Administrator | Root logins | IgnoreRootRhosts, PermitRootLogin |
If you are... | And you want to allow or restrict... | Then use... |
---|---|---|
User | Connections to your account by public-key authentication | authorization file [Section 8.2.2, "SSH2 Authorization Files "] |
Administrator | Connections to an account | AllowUsers, DenyUsers |
User | Connections by a host | N/A |
Administrator | Connections by a host | AllowHosts, DenyHosts |
User | Connections to your account by trusted-host authentication | .rhosts, .shosts |
Administrator | Trusted-host authentication | AllowedAuthentications, AllowSHosts, DenySHosts, /etc/hosts.equiv, /etc/shosts.equiv |
Administrator | Root logins | PermitRootLogin |
[71]If /bin/login is invoked, you might wonder why it doesn't prompt every SSH client for a login password. Well, the server runs /bin/login -f, which disables login's password authentication. The -f option is left unmentioned in the login manpage of many operating systems.What's the difference? That depends on the operating system on the server machine. The login program might set some additional environment variables (such as DISPLAY for the X Windows system), perform additional auditing or logging, or take other actions a shell doesn't. In order for the login program specified by -- with-login to be invoked by sshd1, you must also set the undocumented keyword UseLogin. It takes a value of yes (to use an alternative login program) or no, the default:
OpenSSH doesn't have -- with-login, so you can't specify an alternative login program. The OpenSSH UseLogin statement chooses only between /bin/login and a login shell. The behavior of a login program versus a login shell is entirely implementation-specific, so we won't cover the intricacies. If you need to muck with UseLogin, you first need to understand the features of your operating system and your login program in detail.# SSH1, OpenSSH UseLogin yes
![]() | ![]() | ![]() |
5.4. Getting Ready: Initial Setup | ![]() | 5.6. User Logins and Accounts |
Copyright © 2002 O'Reilly & Associates. All rights reserved.