Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to realize user Management under Linux

2025-02-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to achieve user management under Linux, the article is very detailed, has a certain reference value, interested friends must read it!

In Linux, the management of users is divided into two types: groups and users. The same is true under this Windows. A group is a general term for a class of users. The relationship between groups and users is a many-to-many relationship. That is, users can exist in multiple groups, and there can also be multiple users in the group. The permissions of the group are granted to the users in the group, and the user can inherit permissions from multiple groups.

The administrative commands for the group are:

The code is as follows:

# group management commands

Groupadd # add Group

Groupdel # Delete user groups

Groupmod # modify user group

Groups # displays the user groups to which the current user belongs

Grpck # check the integrity of user groups and password files (etc/group and / etc/gshadow files)

Grpconv # synchronizes or creates / etc/gshadow through the file contents of / etc/group and / etc/gshadow, or if / etc/gshadow does not exist

Grpunconv # synchronizes or creates / etc/group with the contents of the / etc/group and / etc/gshadow files, and then deletes the gshadow file.

The administrative commands for users are:

The code is as follows:

# commands related to user management

Useradd # add user

Adduser # add user

Passwd # set the password for the user

Usermod # modify user commands. You can use usermod to modify login, user's home directory, and so on.

Pwcov # synchronize users from / etc/passwd to / etc/shadow

Pwck # pwck verifies the legality or completeness of the contents of user profile / etc/passwd and / etc/shadow files

Pwunconv # is a vertical reverse operation of pwcov, creating / etc/passwd from / etc/shadow and / etc/passwd, and then deleting the / etc/shadow file

Finger # tool for viewing user information

Id # View users' UID, GID and user groups to which they belong

Chfn # change user Information tool

Su # user switching tool

Sudo # sudo executes commands (execute a command as another user) through another user, su is used to switch users, and then completes the corresponding tasks by switching to users, but sudo can directly execute commands later, for example, sudo does not need a root password to execute root assigned execution, only root can execute corresponding commands; but you have to edit / etc/sudoers through visudo

Visudo # visodo is the command for editing / etc/sudoers; you can also use vi to edit / etc/sudoers directly without this command.

Sudoedit # is similar to sudo in function

These commands can complete the vast majority of user and group management operations, the following code, the completion of the add groups and users function, if there are places that can not be reached-use powerful text editing bar, a variety of users and groups of files waiting for you to explore (followed by the case to modify the file).

The code is as follows:

# if you don't want to use an existing user group, you can create a new user group

Groupadd GROUPNAME # GROUPNAME is the name of the new user group. The GID used here is the default

# after adding a user group, we can add users to the user group.

Useradd username-G GROUPNAME # add user username to GROUPNAME, note that no password is added

# modify user password

Passwd username # set user password

# other various operations.

In Linux, root is a very special account, and the permissions are very large, for the production environment, root account protection is very important, one of the points is that when remote SSH connection, we had better be able to turn off the remote connection function of root. This needs to be done by modifying the configuration file. There is a sshd_config file under / etc/ssh, in which there will be a PermitRootLogin configuration, which is commented out by # by default. To disable SSH login, you need to remove this comment and change the value to no (default is yes).

The code is as follows:

# modify the contents of / etc/ssh/sshd_config file

Vi / etc/ssh/sshd_config

# find the content # PermitRootLogin yes line, change it to the following line

PermitRootLogin no

# Save the content and exit

# restart sshd service

Service sshd restart

Note: if you are a remote login server, you need to create an ordinary user before the above operation, otherwise you will have to run to the computer room.

At this point, after we close putty, reconnect, enter root and provide the password, the remote return will be: Access denied. This disables SSH connections to the root account. If you need to use the execute rights of your root account to execute commands when you are in SSH, just use su/sudo to do it.

For ordinary users, there are many banned ways to find on the Internet, as for which kind of treatment will be better depends on personal hobbies, here are some of them:

The code is as follows:

# disable users directly, so that users cannot log in. The methods are as follows:

# 1. Modify the second column of / etc/shadow to * to prevent users from logging in to the system

Username:*:15864:0:99999:7:::

# the user handled in this way can no longer log in to the system, and the user's password is also lost. If you want to log in again, you need to reset the password.

# 2. Similar to the first, this way is to directly modify the last column of the user path line in / etc/passwd, changing / bin/bash to / sbin/nologin

Username:x:501:500::/home/username:/sbin/nologin

# after this method is modified, the user cannot log in either, and the effect is similar to the above, but if the / bin/bash is restored, the user can directly enter the password to log in.

# 3. Of course, if you don't want to modify the file, you can use usermod directly.

Usermod-L username # # Lock the username account

# in this way, if you want to unlock, you can use usermod-U username. You don't have to modify the file anymore.

# 4. Modify the shell type to prohibit the user and let the user know why

Chsh username-s / sbin/nologin # modify the shell of username

# modify / etc/nologin.txt (if not, you can create it)

# add prohibited reasons to the file.

# this method is similar to the second method, but this method can let users know why they can't log in.

# 5. Prohibit multi-user login

# first, you need to create a nologin document under / etc

Touch / etc/nologin

# # after the file exists, all users except root cannot log in. This file can write down the reason why login is prohibited, so that users can see the reason when they cannot log in.

# # if you don't want to disable all users, just delete the / etc/nologin file.

# 6. Modify the / etc/ssh/sshd_config file, modify the value of AllowUsers

# look for AllowUsers in the file, and if not, add it to the end of the file.

AllowUsers username root # only allows username,root to log in through SSH

# after modifying the file to save, you need to restart the sshd service

# if you want to display a prompt, you can modify / etc/issue.net to add information to the file. At the same time, modify the Banner parameter in the sshd_config file.

Banner / etc/issue.net

# this Banner is prompted before the user logs in.

# if you want to be prompted after entering a password, you can put the prompt in / etc/motd

# # #

# differences between motd and issue.net (the online version of issue) on the Internet:

# / etc/motd, that is, messageoftoday, each time the user logs in, the contents of the / etc/motd file are displayed on the user's terminal. The system administrator can edit the system activity message in the file, for example, the administrator informs the user when the system will be upgraded or maintained, and so on. / etc/motd may not see the prompt when the user enters the graphical interface.

# / etc/issue.net is similar to the / etc/motd file, except that when a network user logs in to the system, the file contents of / etc/issue.net are displayed before the login prompt, while the contents of / etc/motd are displayed after the user successfully logs in to the system.

# 7. Another way is to modify the / etc/pam.d/sshd file

# add to the first line of the file:

Auth required pam_listfile.so item=user sense=deny file=/etc/sshdusers onerr=succeed

# # be sure to be on the first line. The execution order of pam is from top to bottom, giving priority to matching.

# after saving, we also add the user name that needs to be prohibited in the file specified by file

# restart sshd.

Extension:

1. The above is to disable the login of the account, if you want to disable whether an IP can connect or not, use / etc/host.allow and / etc/host.deny files, deny file is blocked IP file, allow is allowed file. The rule is to match deny first and then allow, so the file in allow overrides the file rule in deny:

The code is as follows:

We prohibit all IP connections in the # / etc/host.deny file

Sshd:ALL # all IP are prohibited from SSH to this machine

The specified IP connection is allowed in the # / etc/host.allow file

Sshd:192.168.128.183:allow

# the rules for the two files eventually become:

# only 192.168.128.183 is allowed to connect to this machine.

# after modification, the file takes effect immediately, but not for currently running programs. In order to prevent unnecessary trouble, it is recommended to modify host.allow first, and then modify the host.deny file, so as to ensure that the IP in host.allow can access the sshd process.

two。 Most of the files used in the above management are sshd_config files to control SSH-related operations. For more information on all configuration details of sshd_config, please see here. The following is an excerpt:

The code is as follows:

SSHD_CONFIG (5) OpenBSD Programmer's Manual SSHD_CONFIG (5)

Name

Sshd_config-OpenSSH SSH server daemon configuration file

Outline

/ etc/ssh/sshd_config

Description

Sshd (8) reads configuration information by default from the / etc/ssh/sshd_config file (or the file specified through the-f command line option).

The configuration file is made up of "instruction value" pairs, one per line. Blank lines and lines starting with'# 'are ignored.

If the value contains a blank character or other special symbol, it can be defined by double quotation marks (") on both sides.

[note] the value is case-sensitive, but the instruction is case-independent.

All currently available configuration instructions are as follows:

AcceptEnv

Specifies which environment variables sent by the client will be passed to the session environment. [note] only the SSH-2 protocol supports the passing of environment variables.

For details, please refer to the SendEnv configuration instructions in ssh_config (5).

The value of the instruction is a space-separated list of variable names (where you can use'* 'and'?' As a wildcard). You can also use multiple AcceptEnv to achieve the same goal.

It is important to note that some environment variables may be used to bypass environment variables that are prohibited by users. For this reason, the directive should be used with care.

The default is not to pass any environment variables.

AddressFamily

Specify which address family sshd (8) should use. The value range is: "any" (default), "inet" (IPv4 only), "inet6" (IPv6 only).

AllowGroups

This instruction is followed by a list of group names separated by spaces (you can use "*" and "?" Wildcards). All groups are allowed to log in by default.

If this directive is used, only members of these groups will be allowed to log in, while all other groups will be denied.

The "group" here refers to the "primary group", that is, the group specified in the / etc/passwd file.

Only the name of the group is allowed here, not GID. The related allow/deny instructions are processed in the following order:

DenyUsers, AllowUsers, DenyGroups, AllowGroups

AllowTcpForwarding

Whether to allow TCP forwarding. The default value is "yes".

Disabling TCP forwarding does not enhance security unless users are prohibited from accessing shell because users can install their own transponders.

AllowUsers

This instruction is followed by a list of user names separated by spaces (where you can use "*" and "?" Wildcards). All users are allowed to log in by default.

If this directive is used, only these users will be allowed to log in and all other users will be denied.

If a user in USER@HOST mode is specified, USER and HOST are checked at the same time.

Only the user's first name is allowed here, not UID. The related allow/deny instructions are processed in the following order:

DenyUsers, AllowUsers, DenyGroups, AllowGroups

AuthorizedKeysFile

Stores the RSA/DSA public key that the user can use to log in.

The following symbols that are expanded according to the actual situation at the time of the connection can be used in this directive:

%% means'%',% h represents the user's home directory, and% u represents the user's user name.

The expanded value must be either an absolute path or a relative path relative to the user's home directory.

The default value is ".ssh / authorized_keys".

Banner

The contents of the file specified by this directive are displayed to the remote user before the user authenticates.

This feature is only available for SSH-2, and nothing is displayed by default. "none" means to disable this feature.

ChallengeResponseAuthentication

Whether challenge-response (challenge-response) authentication is allowed. The default is "yes".

All authentication methods allowed in login.conf (5) are supported.

Ciphers

Specifies the encryption algorithm allowed by SSH-2. Multiple algorithms are separated by commas. The following algorithms can be used:

"aes128-cbc", "aes192-cbc", "aes256-cbc", "aes128-ctr", "aes192-ctr", "aes256-ctr"

"3des-cbc", "arcfour128", "arcfour256", "arcfour", "blowfish-cbc", "cast128-cbc"

The default value is that all of the above algorithms can be used.

ClientAliveCountMax

The maximum number of "alive" messages that sshd (8) is allowed to send before receiving any client response. The default value is 3.

When this limit is reached, sshd (8) will forcibly disconnect and close the session.

It is important to note that "alive" messages are very different from TCPKeepAlive.

"alive" messages are sent over encrypted connections, so they are not spoofed; TCPKeepAlive can be spoofed.

If ClientAliveInterval is set to 15 and ClientAliveCountMax is left at the default value

Then the client that does not reply will be forcibly disconnected after about 45 seconds. This directive can only be used for the SSH-2 protocol.

ClientAliveInterval

Set a time in seconds. If you do not receive any data from the client for more than this long time

Sshd (8) will send a "alive" message to the client through a secure channel and wait for a reply.

The default value of 0 means that the "alive" message is not sent. This option is valid only for SSH-2.

Compression

Whether to encrypt the communication data, or delay to encrypt the communication data until after the authentication is successful.

Available values: "yes", "delayed" (default), "no".

DenyGroups

This instruction is followed by a list of group names separated by spaces (you can use "*" and "?" Wildcards). All groups are allowed to log in by default.

If this directive is used, members of these groups will be denied login.

The "group" here refers to the "primary group", that is, the group specified in the / etc/passwd file.

Only the name of the group is allowed here, not GID. The related allow/deny instructions are processed in the following order:

DenyUsers, AllowUsers, DenyGroups, AllowGroups

DenyUsers

This instruction is followed by a list of user names separated by spaces (where you can use "*" and "?" Wildcards). All users are allowed to log in by default.

If this directive is used, these users will be denied login.

If a user in USER@HOST mode is specified, USER and HOST are checked at the same time.

Only the user's first name is allowed here, not UID. The related allow/deny instructions are processed in the following order:

DenyUsers, AllowUsers, DenyGroups, AllowGroups

ForceCommand

Enforce the commands specified here while ignoring any commands provided by the client. This command will be executed using the user's login shell (shell-c).

This can be applied to the completion of shell, commands, and subsystems, usually in Match blocks.

This command is initially supported on the client side through the SSH_ORIGINAL_COMMAND environment variable.

GatewayPorts

Whether to allow the remote host to connect to the local forwarding port. The default is "no".

Sshd (8) binds remote port forwarding to the loopback address by default. This will prevent other remote hosts from connecting to the forwarding port.

The GatewayPorts directive allows sshd to bind remote port forwarding to a non-loopback address, thus allowing remote hosts to connect.

"no" means that only local connections are allowed, and "yes" means that remote port forwarding is forced to be bound to a unified address (wildcard address)

"clientspecified" means to allow the client to choose which address to bind remote port forwarding to.

GSSAPIAuthentication

Whether GSSAPI-based user authentication is allowed. The default is "no". For SSH-2 only.

GSSAPICleanupCredentials

Whether to automatically destroy the user credential cache after the user logs out. The default is "yes". For SSH-2 only.

HostbasedAuthentication

This instruction is similar to RhostsRSAAuthentication, but can only be used for SSH-2. The default value "no" is recommended.

It is recommended to use the default value "no" to disable this unsafe authentication method.

HostbasedUsesNameFromPacketOnly

With HostbasedAuthentication turned on

Specifies whether the server does a reverse domain name query when using ~ / .shosts ~ / .rhosts / etc/hosts.equiv for remote hostname matching.

"yes" means that sshd (8) trusts the hostname provided by the client without reverse querying. The default is "no".

HostKey

The location of the host private key file. If the permissions are incorrect, sshd (8) may refuse to start.

SSH-1 defaults to / etc/ssh/ssh_host_key.

SSH-2 defaults to / etc/ssh/ssh_host_rsa_key and / etc/ssh/ssh_host_dsa_key.

A host can have multiple different private keys. "rsa1" is for SSH-1 only, and "dsa" and "rsa" are for SSH-2 only.

IgnoreRhosts

Whether to ignore .rhosts and .shosts files during RhostsRSAAuthentication or HostbasedAuthentication.

However, / etc/hosts.equiv and / etc/shosts.equiv will still be used. It is recommended to set it to the default value "yes".

IgnoreUserKnownHosts

Whether to ignore the user's ~ / .ssh/known_hosts file during RhostsRSAAuthentication or HostbasedAuthentication.

The default is "no". To improve security, you can set it to "yes".

KerberosAuthentication

Whether the password provided by the user for PasswordAuthentication must be authenticated by Kerberos KDC, that is, whether or not to use Kerberos authentication.

To use Kerberos authentication, the server needs a Kerberos servtab that can verify KDC identity. The default is "no".

KerberosGetAFSToken

If AFS is used and the user has a Kerberos 5 TGT, when the instruction is turned on

An attempt will be made to get an AFS token before accessing the user's home directory. The default is "no".

KerberosOrLocalPasswd

If the Kerberos password authentication fails, the password will also have to go through other authentication mechanisms (such as / etc/passwd).

The default is "yes".

KerberosTicketCleanup

Whether to automatically destroy the user's ticket after the user logs out. The default is "yes".

KeyRegenerationInterval

Under the SSH-1 protocol, the short-lived server key will be continuously regenerated during a period of time (seconds) set by this instruction.

This mechanism can minimize the loss of keys or the loss caused by hackers.

Set to 0 to never regenerate, and the default is 3600 (seconds).

ListenAddress

Specify the network address that sshd (8) listens on, and listen on all addresses by default. You can use the following format:

ListenAddress host | IPv4_addr | IPv6_addr

ListenAddress host | IPv4_addr:port

ListenAddress [host | IPv6_addr]: port

If port is not specified, the value of the Port instruction is used.

Multiple ListenAddress instructions can be used to listen on multiple addresses.

LoginGraceTime

The user must be successfully authenticated within the specified time limit. 0 means there is no limit. The default value is 120 seconds.

LogLevel

Specifies the log level (detail level) for sshd (8). The available values are as follows:

QUIET, FATAL, ERROR, INFO (default), VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3

DEBUG is equivalent to DEBUG1; DEBUG2 and DEBUG3 specify more detailed and verbose log output, respectively.

Logs that are more detailed than DEBUG may reveal sensitive information about users, so they are opposed to use.

MACs

Specifies which message digest algorithms are allowed in SSH-2 for data validation.

You can use a comma-separated list to specify that multiple algorithms are allowed. The default value, which includes all available algorithms, is:

Hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96 HmacMurray Md5-96

Match

Introduce a conditional block. The end mark of the block is another Match instruction or the end of the file.

If all the conditions specified on the Match line are met, subsequent directives will override the directives in the global configuration.

The value of Match is one or more condition-mode pairs. The available conditions are: User, Group, Host, Address.

Only the following instructions can be used in Match blocks: AllowTcpForwarding, Banner

ForceCommand, GatewayPorts, GSSApiAuthentication

KbdInteractiveAuthentication, KerberosAuthentication

PasswordAuthentication, PermitOpen, PermitRootLogin

RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset

X11Forwarding, X11UseLocalHost

MaxAuthTries

Specifies the maximum number of authentications allowed per connection. The default value is 6.

If the number of failed authentication is more than half of this number, the connection will be forcibly disconnected and additional failure log messages will be generated.

MaxStartups

The maximum number of unauthenticated connections allowed. The default value is 10.

When the limit is reached, new connections will no longer be accepted unless the previous connection authentication was successful or exceeded the LoginGraceTime limit.

PasswordAuthentication

Whether password-based authentication is allowed. The default is "yes".

PermitEmptyPasswords

Whether to allow users with empty passwords to log in remotely. The default is "no".

PermitOpen

Specifies the destinations allowed for TCP port forwarding, and multiple forwarding destinations can be separated by spaces. All forwarding requests are allowed by default.

The legal instruction format is as follows:

PermitOpen host:port

PermitOpen IPv4_addr:port

PermitOpen [IPv6_addr]: port

"any" can be used to remove all restrictions and allow all requests to be forwarded.

PermitRootLogin

Whether to allow root login. The available values are as follows:

"yes" (default) means allowed. "no" means forbidden.

"without-password" means that login with password authentication is prohibited.

"forced-commands-only" means that login with public key authentication is allowed only if the command option is specified.

At the same time, all other authentication methods are prohibited. This value is often used to do remote backups and the like.

PermitTunnel

Whether to allow tun (4) devices to forward. The available values are as follows:

"yes", "point-to-point" (layer 3), "ethernet" (layer 2), "no" (default).

"yes" implies both "point-to-point" and "ethernet".

PermitUserEnvironment

Specifies whether sshd (8) is allowed to handle the environment= option in ~ / .ssh/environment and ~ / .ssh/authorized_keys.

The default is "no". If set to "yes", users may have the opportunity to use certain mechanisms (such as LD_PRELOAD) to bypass access control, creating security vulnerabilities.

PidFile

Specifies in which file the process number of the SSH daemon is stored, which defaults to the / var/run/sshd.pid file.

Port

Specifies the port number that the sshd (8) daemon listens to, which defaults to 22. You can use multiple instructions to listen on multiple ports.

By default, it will listen on all network interfaces on this machine, but it can be specified by ListenAddress to listen only on a specific interface.

PrintLastLog

Specifies whether sshd (8) prints the login time of the last user at each interactive login. The default is "yes".

PrintMotd

Specifies whether sshd (8) prints the contents of the / etc/motd file at each interactive login. The default is "yes".

Protocol

Specifies the version number of the SSH protocol supported by sshd (8).

'1' and' 2' indicate that only SSH-1 and SSH-2 protocols are supported. "2recover1" means that both SSH-1 and SSH-2 protocols are supported.

PubkeyAuthentication

Whether public key authentication is allowed. Can only be used for SSH-2. The default is "yes".

RhostsRSAAuthentication

Whether to use strong trusted host authentication (authentication by checking the remote hostname and associated user name). For SSH-1 only.

This is verified by checking ~ / .rhosts or / etc/hosts.equiv after the RSA authentication is successful.

For security reasons, the default value "no" is recommended.

RSAAuthentication

Whether pure RSA public key authentication is allowed. For SSH-1 only. The default is "yes".

ServerKeyBits

Specifies the length of the temporary server key. For SSH-1 only. The default value is 768 bits. The minimum value is 512.

StrictModes

Specify whether to require sshd (8) to host and permission checks the user's home directory and related configuration files before accepting the connection request.

It is strongly recommended that you use the default value "yes" to prevent possible low-level errors.

Subsystem

Configure an external subsystem (for example, a file transfer daemon). For SSH-2 protocols only.

The value is the name of a subsystem and the corresponding command line (with options and arguments). Such as "sft / bin/sftp-server".

SyslogFacility

Specifies the log subsystem (facility) through which sshd (8) sends log messages. Valid values are:

DAEMON, USER, AUTH (default), LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7

TCPKeepAlive

Specifies whether the system sends TCP keepalive messages to the client. The default is "yes".

This message can detect exceptions such as dead connections, improper connection closures, client crashes, and so on.

This feature can be turned off by setting it to "no".

UseDNS

Specify whether sshd (8) should reverse resolve the remote hostname to check that the hostname really corresponds to its IP address. The default is "yes".

UseLogin

Whether to use login (1) during the login process of an interactive session. The default is "no".

If this directive is turned on, X11Forwarding will be disabled because login (1) does not know how to handle xauth (1) cookies.

It is important to note that login (1) is prohibited for remote command execution.

If UsePrivilegeSeparation is specified, it will be disabled after authentication is complete.

UsePrivilegeSeparation

Whether to let sshd (8) separate permissions by creating a non-privileged child process to handle access requests. The default is "yes".

After the authentication is successful, another child process will be created as the authenticated user.

The goal is to prevent privilege escalation through defective child processes, thus making the system more secure.

X11DisplayOffset

Specifies the first available display area (display) number forwarded by sshd (8) X11. The default value is 10.

This can be used to prevent sshd from occupying the real X11 server display area, thus causing confusion.

X11Forwarding

Whether X11 forwarding is allowed. The default value is "no" and set to "yes" to allow.

If X11 forwarding is allowed and the display area of the sshd (8) agent is configured to listen on an address (X11UseLocalhost) containing wildcards.

Then additional information may be leaked. Due to the possible risk of using X11 forwarding, the default value of this directive is "no".

It is important to note that banning X11 forwarding does not prevent users from forwarding X11 traffic because users can install their own transponders.

If UseLogin is enabled, X11 forwarding is automatically disabled.

X11UseLocalhost

Whether sshd (8) should bind the X11 forwarding server to the local loopback address. The default is "yes".

Sshd binds the forwarding server to the local loopback address by default and sets the hostname portion of the DISPLAY environment variable to "localhost".

This prevents the remote host from connecting to the proxy display. However, some older X11 clients do not work properly in this configuration.

To be compatible with these old X11 clients, you can set it to "no".

XAuthLocation

Specifies the absolute path to the xauth (1) program. The default is / usr/X11R6/bin/xauth

Time format

The time values used in sshd (8) command line arguments and configuration files can be specified in the following format: timequalifier.

Where time is a positive integer, and qualifier can be one of the following units:

Second

S | S seconds

M | M minutes

H | H hours

D | D days

W | W week

You can accumulate time by specifying multiple values, such as:

1h40m 1 hour 30 minutes (90 minutes)

File

/ etc/ssh/sshd_config

The main configuration file for sshd (8). The host of this file should be root, and the maximum permission can be "644".

See also

Sshd (8)

Author

OpenSSH is a derivative of the original and free ssh 1.2.12 release by

Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo

De Raadt and Dug Song removed many bugs, re-added newer features and cre-

Ated OpenSSH. Markus Friedl contributed the support for SSH protocol

Versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support

For privilege separation.

The above is all the contents of the article "how to achieve user Management under Linux". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report