|
     |
Public-key authentication is based on the use of digital signatures and provides very good authentication security. To use public-key authentication, the user must first create a key pair on the client, and upload the public key to the server.
The default directory where Tectia Server stores the users' public keys is
$HOME/.ssh2/authorized_keys on Unix, and
%USERPROFILE%\.ssh2\authorized_keys on Windows. The directory can be changed
with the authorized-keys-directory attribute in the
ssh-server-config.xml file. See
auth-publickey
.
The user is required to have the read rights, (and optionally
the write rights) to the public-key files and directories, but the locations must
not be accessible to other users. The read permissions are required for the
key.pub file, the authorized_keys directory, and
to the authorization file, if used. The write permission to
these files are needed if the users are allowed to upload their own keys to the server.
To enable public-key authentication on the server, the
authentication-methods element of the ssh-server-config.xml file
must contain an auth-publickey element. For example:
<authentication-methods>
<authentication action="allow">
<auth-publickey authorized-keys-directory="%D/.ssh2/authorized_keys" />
...
</authentication>
</authentication-methods>
Also other authentication methods can be allowed.
By using selectors, it is possible to allow or require public-key authentication only for a specified group of users. See Using Selectors in Configuration File for more information.
Using the Tectia Server Configuration tool, public-key authentication can be allowed on the Authentication page. See Authentication.
Tectia Server 4.x (and earlier) required an authorization file that listed the user
public keys that are authorized for login. Using the authorization file with Tectia Server 5.0 and
later is optional. If the file does not exist, Tectia Server looks for authorized public keys in the
authorized-keys directory (as described in User Authentication with Public Keys
above), and if that fails, in the default directory for user public-keys.
The default location for the authorization file is
$HOME/.ssh2/authorization on Unix, and
%USERPROFILE%\.ssh2\authorization on Windows. The file location can be
changed with the authorization-file attribute in the
ssh-server-config.xml file. See
auth-publickey
.
The authorization file contains a list of public key filenames each
preceded by the keyword Key. If there is more than one
Key, they are all authorized for login. For more information on the syntax
of the authorization file, see $HOME/.ssh2/authorization (user-specific) under the section called “Files”.
Tectia Client on Windows can upload the public keys and edit the authorization file automatically.
Tectia Server supports also user public keys generated with OpenSSH. The OpenSSH keys can be configured the same way as described above for keys generated with Tectia Client.
Alternatively, the OpenSSH-style authorized keys file can be specified in the
ssh-server-config.xml file by using the
openssh-authorized-keys-file attribute. See
auth-publickey
. An example configuration is shown below:
<authentication-methods>
<authentication action="allow">
<auth-publickey authorization-file="%D/.ssh2/authorization"
openssh-authorized-keys-file="%D/.ssh/authorized_keys" />
...
</authentication>
</authentication-methods>
Tectia Server checks the file defined in
openssh-authorized-keys-file if it cannot find a matching key in the Tectia
authorization-file or the authorized-keys-directory. Public keys
defined in the Tectia locations have precedence over the keys in the OpenSSH file if the same
key is defined in both.
On the Tectia Server for Windows, the recommended location for public keys is the
%USERPROFILE%\.ssh2 directory. This location reflects the standard Unix usage
and works with the default settings of Tectia Client automatic key upload, and the user's profile
directory always has the appropriate access permissions (set by the operating system during
the account creation).
The user configuration directory can be changed on the General page of the Tectia Server Configuration tool. See General.
If users need to manage their public keys themselves, the administrator should inform the users about the location of the user configuration directory. Otherwise, the administrator has to place the user's public keys in the proper directory.
![[Note]](images/note.gif) | Note |
|---|---|
Tectia Client uses SFTP for the automatic uploading of the public key. It will not succeed if
the user configuration directory has been set to a location that is not under the user's
SFTP home directory. By default, both directories are under
|
If you want to enable automatic public-key upload for the users, change both the user configuration directory and the SFTP user home directory to point to the same directory. See SFTP.
For example, set
D:\SFTP\%username% as the SFTP user home directory and
D:\SFTP\%username%\.ssh2 as the user configuration directory.
See also the general considerations on user name handling in User Logon Rights on Windows.
Tectia Server supports storing domain users' authorized keys (and authorization files) on a network drive.
Because the user's network drives are restored only after the user has been fully authenticated, the path to the authorized keys directory must be specified in UNC format, for example:
\\server.my-company.com\dfs\authorized_keys
Tectia Server is accessing the network drive from a thread impersonating the user who is logging on. The impersonation token is obtained via Microsoft Kerberos extension Service for User to Self (S4U2self)[1]. Therefore, the computer domain account is acting on behalf of the user.
To enable access to network resources this way, the following requirements must be met:
The computer must be configured on a domain controller to be trusted for delegation of CIFS services for the particular network drive. For instructions on how to configure this, see Virtual Folders Defined on Windows Network Shared Folders Are Not Available on Tectia Server on Windows.
The individual users must have read access to their files granted in the access control list of the folder itself, as well as in the network drive.
Example configuration:
<authentication-methods login-grace-time="600">
<authentication name="Default-Authentication" action="allow" password-cache="no">
<auth-publickey
authorized-keys-directory="\\server.my-company.com\dfs\authorized_keys\%U"
require-dns-match="no" />
<auth-password failure-delay="2" max-tries="3" />
<auth-gssapi allow-ticket-forwarding="no" />
<auth-keyboard-interactive failure-delay="2" max-tries="3">
<submethod-password />
</auth-keyboard-interactive>
</authentication>
</authentication-methods>[1] S4U2self is an extension that allows a service to obtain a Kerberos service ticket to itself. The service ticket contains the user's groups and can therefore be used in authorization decisions.
| |