SSH - (Secure Shell) - network protocol, allowing to produce remote control computer and file transfer. Similar in functionality to the Telnet and rlogin protocols, however, it uses encryption algorithms for transmitted information.
The shortcomings of telnet led to a very rapid abandonment of this protocol in favor of the more secure and functional SSH protocol. SSH provides all those functionality, which were presented in telnet, with the addition of effective coding to prevent the interception of data such as logins and passwords. The public key authentication system introduced in the SSH protocol ensures that remote computer really is who he says he is.
The cryptographic protection of the SSH protocol is not fixed; different encryption algorithms can be selected. Clients and servers supporting this protocol are available for various platforms. In addition, the protocol allows not only the use of a secure remote shell on the machine, but also tunneling GUI- X Tunnelling (only for Unix-like OS or applications using the X Window System GUI). SSH is also capable of transmitting any other network protocol through a secure channel (Port Forwarding), providing (with proper configuration) the ability to securely forward not only the X interface, but also, for example, audio.
However, the SSH protocol does not solve all network security problems. It only focuses on ensuring the secure operation of applications such as terminal emulators. Using implementations of the SSH protocol on servers and client applications helps protect data only during transmission. The SSH protocol is in no way a replacement for firewalls, intrusion detection systems, network scanners, authentication systems and other tools to protect Information Systems and networks from attacks.
39.The role and tasks of the server in local network.
In general terms, a server is Calculating machine, which usually has high performance and other computing resources, designed to provide certain capabilities for computers on a local or global network. These capabilities are called network services.
Server tasks:
1.providing access to data stored on the organization’s server drives;
2.storage, processing and access to company databases;
3. software processing of data that the user sends to him, and gives this user the final results;
4. provision of an Internet page to the user who requests it;
5.sending, receiving, storage and distribution emails, which are sent by all users of the local network.
Network services.
For the end user, a network is not about computers, cables and hubs, or even information flows, for him the network is, first of all, that set network services, with the help of which he gets the opportunity to view a list of computers available on the network, read a remote file, print a document on a “foreign” printer or send postal message. It is the totality of the opportunities provided - how wide their choice is, how convenient, reliable and safe they are - that determines the appearance of a particular network for the user.
In addition to the actual data exchange, network services must solve other, more specific tasks, for example, tasks generated by distributed data processing. Such tasks include ensuring the consistency of several copies of data located on different machines (replication service), or organizing the execution of one task in parallel on several machines on the network (remote procedure call service). Among the network services, we can distinguish administrative ones, that is, those that are mainly aimed not at the ordinary user, but at the administrator and serve for the organization proper operation the network as a whole.
Implementation of network services is carried out software. Basic services - file service and print service are usually provided by the network operating system, and auxiliary services, such as database, fax, or voice services, are usually provided by system network applications or utilities that work closely with the network OS. Generally speaking, the distribution of services between the OS and utilities is quite arbitrary and changes in specific OS implementations.
When determining the degree of convenience of a shared resource, the term “transparency” is often used. Transparent access is access in which the user does not notice where the resource he needs is located - on his computer or on a remote one. After he has mounted the remote file system into his directory tree, access to deleted files becomes completely transparent to him. The mount operation itself can also have varying degrees of transparency - in networks with less transparency the user must know and specify in the command the name of the computer on which the remote file system is stored; in networks with a greater degree of transparency, the corresponding software component of the network searches for shared file volumes regardless of their location storage, and then provides them to the user in a form convenient for him, for example, as a list or a set of icons.
To ensure transparency, the way of addressing (naming) shared network resources. The names of shared network resources should not depend on their physical location on a particular computer. Ideally, a user should not change anything about their experience if the network administrator has moved a volume or directory from one computer to another. The administrator himself and the network operating system have location information file systems, but it is hidden from the user. This degree of transparency is still rare in networks - usually to gain access to resources specific computer first you have to establish a logical connection with it. This approach is used, for example, in Windows networks NT
There are several ways to access the CLI environment. The most common methods:
-
Telnet or SSH
Console
The CLI can be accessed through a console session, also known as a CTY line. The console uses a low-speed serial connection that occurs by connecting a computer or terminal directly to the console port on the router or switch.
The console port is a management port that provides out-of-band access to the router. The console port is available even if no network services have been configured on the device. The console port is often used to access a device when network services have not started or have stopped working.
Examples of using the console:
Initial configuration of a network device
Procedures disaster recovery and troubleshooting when remote access is not possible
Password recovery procedures
When the router is first used, the network settings are not yet configured. Therefore, the router cannot communicate through the network. To prepare it for initial startup and configuration, terminal emulation software is run on the computer to connect to the device's console port. Configuration commands to configure the router can be entered through the connected computer.
During operation, if the router cannot be accessed remotely, connecting to the console via a computer may allow the status of the device to be determined. By default, the console displays information about device startup, debugging, and error messages.
For many iOS devices, console access does not require any form of security by default. However, the console must be configured with passwords to prevent unauthorized access to the device. When a password is lost, there is a special set of procedures to bypass the password and gain access to the device. The device should be located in a locked room or equipment rack to prevent physical access.
Telnet and SSH
Telnet - method for receiving remote access to the router CLI session. Unlike a console connection, Telnet sessions require active network services on the device. A network device must have at least one active interface configured with a Layer 3 address, such as an IPv4 address. Cisco IOS devices include a Telnet server process that starts when the device starts. iOS also includes a Telnet client.
Knot with Telnet client can access vty sessions running on a Cisco device. For security reasons, IOS requires that the Telnet session use a password as the minimum authentication method. Methods for setting up accounts and passwords will be discussed in subsequent articles in this section.
The Secure Shell (SSH) protocol is a more secure method for remotely accessing a device. This protocol provides remote login similar to Telnet, except that it uses more secure network services.
SSH provides stronger password authentication than Telnet and uses encryption when transporting session data. The SSH session encrypts all data transfers between the client and the IOS device. This protects the user ID, password, and management session details. As a best practice, always use SSH instead of Telnet whenever possible.
Most newer ones iOS versions contain an SSH server. Some devices have this service enabled by default. Other devices require the SSH server to be enabled.
IOS devices also include an SSH client that can be used to establish SSH sessions with other devices. Similarly, you can use a remote computer with an SSH client to start a secure CLI session. SSH client software is not provided by default on all computer operating systems. You may need to obtain, install and configure SSH client software for your computer.
AUX
Another way to establish a CLI session remotely is over a dial-up telephone connection, using a modem connected to the router's AUX port. Similar to a console connection, this method does not require any network services to be configured or available on the device.
The AUX port can also be used locally as a console port when connected directly to a computer running a terminal emulation program. A console port is required for router configuration, but not all routers have an auxiliary port. The console port is also preferred over the diagnostic auxiliary port because it displays router startup details, debugging information, and default error messages.
Typically, the only time the AUX port is used locally instead of the console port is when there are problems using the console port, such as if some console parameters are unknown.
Telnet is a basic UNIX OS protocol that provides terminal access for users to a remote computer.
Initially, a terminal was a typewriter-type device on which the operator (user) typed commands and observed the results. Later the terminal was divided into a monitor and a keyboard.
By default, Telnet uses port 23. Must be running on the remote computer server part, and on the user’s computer – client. The client program has the same name - telnet and allows you to enter parameters from the command line. These options include:
Server name (IP address) and port number
Text terminal type
Username
Connection log name
Determining the actions of some keyboard function keys, etc.
The command line syntax depends on the software implementation of telnet and from this point of view telnet can be considered as a service or service.
The telnet protocol involves transmitting to the server (remote computer) via the TCP protocol each character typed by the user in a separate packet. If echo is enabled, the server returns the sign to the user's monitor. The results of executing programs running on the server are transmitted in blocks. Within the limits of the user's rights and capabilities of the terminal, telnet provides full access to server programs and files. When establishing a connection, the authentication process sends the username and password characters in clear text, making telnet extremely dangerous to use.
The most popular method for increasing the security of terminal application protocols (for example, telnet) is the SSH (Secure SHell) protocol, which uses port 22 by default. Just like in telnet, the SSH server part is launched on the remote computer, and the client part is launched on the user computer. After establishing a connection, all data is transmitted in encrypted form and all application protocol data is tunneled over this secure connection as shown in Figure 3.5.3.1.
Before using telnet, the remote computer and the user’s computer establish a secure connection on port 22 (it is assumed that before using SSH, cryptographic protection passwords have already been defined in the client and server parts). When calling telnet, port 23 is opened, but the transmitted packets are intercepted by the SSH client, encrypted and sent over a secure channel. The SSH server decrypts the data and transmits it to the telnet server on port 23. The server's response is transmitted in reverse order. The user does not feel the operation of the SSH protocol and works as with a regular telnet client on port 23.
Email protocols
Electronic mail (E-mail) is one of the oldest and most widespread network services, popular both in local and global networks.
The e-mail system appeared in 1982 as a service of the Internet ancestor of the ARPANET network. This system differed significantly from the X.400 series of recommendations adopted by CCITT. The complexity of the X.400 recommendations and their lack of thought led to a rare case in network technology when proactive development defeated an international standard. Email services that comply with X.400 are not widely used and are of rather scientific interest.
An electronic mail message, as in regular mail, contains an envelope with the information necessary for delivery, a header with data useful for automated processing by the addressee, and the message itself.
The envelope and header have formal fields. The most important of them are (fields required to be filled in by the sender are highlighted in bold):
Then: - address(es) of the recipient(s) in the format mailbox_name@mail_server_name
CC: - (carbon copy) address(es) of additional recipient(s)
Bcc: - (blind carbon copy) blind address(es) of the recipient(s) that is not disclosed to others
Sender: - email sender address
Received: - field where, when passing each node, the node name, date and time of reception are added
Return-Path: - names of nodes on the letter path
Date: - date and time of sending the letter
Reply-to: - address where you need to reply
Message-id: - unique message identifier (for links)
In-Reply-id: - identifier of the letter to which a reply is given
Subject: - subject of the letter
The body of the message is a set of strings of no more than 1000 (up to 78 recommended) ASCII (American Standard Code for Information Interchange) characters, i.e. 7-bit numbers representing letters of the Latin alphabet, punctuation marks and numbers (popular for such a representation is the term “encoding”). Characters of national encodings (for example, Cyrillic characters), binary files (for example, with audio or video information), etc. are displayed in accordance with the MIME (Multipurpose Internet Mail Extension) convention, which provides a field indicating encoding method (for example, Base64 - see paragraph 3.5.2).
The basic method for ensuring email confidentiality is cryptographic protection. The most popular system is called PGP (Pretty Good Privacy). This system was proposed by Phil Zimmerman and involves the use of several encryption algorithms (RSA, IDEA, MD5).
Another system is called PEM (Privacy Enhanced Mail) and differs from PGP in the need for communication with key certification authorities, a lower degree of security (to encrypt data, the PGP system uses 128-bit long keys, while the PEM system uses only 56-bit keys) , but in full compliance with ITU-T recommendations (X.400 and X.509).
Email protocols are characterized by significant diversity, from proprietary ones suitable for software products of specific manufacturers to generally recognized ones. We are talking about protocols specifically for email systems, and not about common systems for emulating email services based on the HTTP protocol (see, for example, www.mail.ru).
Some of the mail protocols include:
SMTP (Simple Mail Transfer Protocol) is a protocol used to exchange mail between nodes and send letters from a client to a mail server. By default, the protocol uses port 25.
POP3 (Post Office Protocol v.3 – email protocol version 3) – protocol for receiving mail by the client. By default, the protocol uses port 110.
IMAP v4 (Internet Message Access Protocol v.4) is a protocol similar to POP3, but allows the client to store and process mail on the mail server itself. By default the protocol uses port 585
SMNP protocol
The SNMP (Simple Network Management Protocol) protocol was originally developed to manage routers, but was then extended to any network devices(default ports 161/162). Currently, version 2 of the protocol (1999) is current.
The protocol is built on the client-server principle (the client program must be running on the managed network device) and includes a control protocol (interaction between the managed and control nodes), the ASN.1 language (Abstract Syntax Notation v.1 - abstract syntax notation version 1) descriptions of the management model and the management model itself MIB (Management Information Base). The spread of the protocol is hampered by its low security and reliance on the UDP protocol, which leads to possible loss of DNS messages
The task of name resolution involves determining the IP address of a node by its symbolic name and determining the symbolic name by a given IP address.
Historically, the first, but still valid, mechanism for name resolution is associated with the direct setting of a table of correspondence between symbolic names and IP addresses in the hosts/lmhosts file (the first file is used by UNIX/Linux and some other operating systems (OS), and the second is used by Microsoft OS ). Both files are text files and their formats and keys can be found in MS Windows in files of the same name with the extension . sam (sample – sample). Obviously, for any large network it is not possible to completely solve the problem in this way, although recording information about the main servers, routers, gateways, etc. in these files is very effective for speeding up the start of a computer in a networked environment.
Another fairly popular method of name resolution involves using NetBIOS (Network Basic Input/Output System) over TCP/IP. This system was developed jointly by Microsoft and IBM in the 1980s as a network I/O service for the operating room. Windows systems. Later, to implement user access to network resources, the NetBEUI protocol (NetBIOS Extended User Interface) was developed as the main network protocol in Windows for Workgroups and NT. Finally, with the widespread adoption of the TCP/IP stack, Microsoft was forced to release an implementation of NetBIOS that uses IP to transfer the necessary data (NetBIOS over TCP/IP). NetBIOS is still supported in Windows 2000/NT/XP, although no longer as the main mechanism for accessing network resources. NetBIOS is useful for small, peer-to-peer networks.
Initially, each node on a NetBIOS network has a symbolic name (up to 15 characters) with a resource identifier (16th character) that indicates the role of the node ( file server, print server, workstation, etc.). "Pure" NetBIOS is applicable only to small networks and is considered "non-routable" because -
the naming system does not allow the network to be identified
Broadcast requests are widely used to obtain and update information about network hosts (most routers do not allow broadcast requests)
To eliminate these shortcomings, Microsoft offered the WINS service (Windows Internet Name Service - Windows service Internet names) based on NetBIOS name servers. It should be noted that despite mentioning Internet networks WINS is not used on this WAN.
The first drawback of NetBIOS is eliminated in WINS by entering a group name for the network, and the second by the fact that name resolution requests are addressed to specific WINS servers. Instability in the operation of the service, administration difficulties and difficulty of use on the global Internet have now forced Microsoft company switch to full DNS support.
DNS (Domain Name System) is implemented using the application protocol of the same name, using port 53 by default. The DNS system was developed within the UNIX operating system and the corresponding service that uses DNS has the same abbreviation, but stands for Domain Name Service.
Names in DNS are built according to a hierarchical principle in the form of an inverted tree. Top-level domains (root) are divided according to professional principles (. com - commercial, . gov - government, . net - network and other nodes) or national (. ru - Russian, . fi - Finnish, . fr - French, etc. .d.). The UNIX OS was developed in the USA and, of course, it was assumed that all nodes were located there. Nowadays you can find double domain names, for example. com. tw – commercial Taiwanese.
In turn, each domain contains a subdomain, the name of which is added to the left and separated by a dot, etc. The entry ends by adding the host name to the left. The name of each domain, subdomain or host must not exceed 63 characters, and the full name must not exceed 255 characters. The Latin alphabet, numbers and dashes are traditionally used to denote names (the _ sign is not allowed), but, in principle, it is possible to register a domain with a name in Cyrillic, but the meaning of this is problematic.
Data about the names of subdomains/nodes registered in any domain and their IP addresses are stored in two tables on DNS servers, which also contain the name and address of the overlying domain. Using the first table, the digital address is determined for a given symbolic name (direct conversion and, accordingly, the so-called “direct zone”), and the second table determines the symbolic name at the given address (reverse conversion and “reverse zone”).
To increase reliability, each domain must have at least 2 servers (primary - primary and secondary - backup), and these servers must be physically located in different networks and may not be located in the same domains as the host names they contain.
The root domain is supported by over 10 DNS servers, whose IP addresses and names are “hardwired” into the network OS. Registration of new names and allocation of corresponding IP addresses is carried out by the domain owner. For example, registration in a domain. ru is produced by RosNIIROS, where registering a name and obtaining an IP address will cost approximately $50, and annual address support will cost $10. All changes in the name table are made on the primary DNS server, backup servers only update their records according to the records of the primary server. Zone replication (updating) is carried out using the reliable TCP protocol, while for DNS client requests, the UDP protocol is used. To speed up the name resolution process and reduce traffic on the network, so-called DNS cache servers are sometimes installed, which record frequently used names and addresses. The operating mode of a DNS server can be recursive or non-recursive. In the case of recursive mode, if it is impossible to resolve a DNS request, this request is translated to a specially designated other DNS server (forwarder), which then returns the received response. In non-recursive mode, in the absence of information about the requested node, an appeal is made to the root DNS servers, and from them down the chain until a response is received.
NAT (Network Address Translation) implements the conversion (substitution) of IP addresses of local networks into external IP addresses of the global Internet. The need for such a conversion follows from the agreement on using part of IP addresses only in local networks (see clause 3.2), according to which global network routers destroy packets with these addresses.
NAT operates at the network and partially at the transport levels, ensuring the conversion of local network host addresses in IP packets to an external address. The conversion is performed by replacing the address of the internal node with an external address. The replaced addresses are stored in a table, with the help of which the reverse replacement is performed when a response packet is received. It should be noted that to eliminate possible indistinguishability, not only the IP address is converted, but also the port number using PAT (Port Address Translation).
In addition to address translation, NAT allows you to reduce the need for IP addresses for global networks, since all users of the local network can access global network resources through one external address.
NAT is not the only way to send packets from a local network to a global network; an alternative to address translation is to use an intermediary server.
The book discusses in detail the settings of network services that allow you to create a server with the required configuration and functionality based on the Linux OS. You can configure any type of server: from a local network server to an Internet server and a remote access server. Linux administration is described in detail.
The presentation of the material is based on distribution kits Red Hat and Mandrake. Lots of unique information: launching Windows games for Linux and creating a Linux server for the gaming room, setting up Dr. antiviruses. Web and AVP for Linux, traffic accounting program MRTG, security and attack detection system LIDS, and much more. Particular attention is paid to the security of Linux servers. The Linux OS itself is described in sufficient detail and a reference book of its commands is provided. After reading the book, you will become knowledgeable about setting up and compiling the kernel, creating your own rpm packages, the bash command interpreter, using RAID arrays. You will get to know the inner world of Linux. The book is suitable for both professional and novice administrators, since the presentation of the material begins with installing the Linux OS, and the first chapter describes the basic network technologies and protocols (Young Administrator Course).
All listings given in the book have been tested in practice and are placed on the attached CD. In addition, it contains a lot of reference information (HOWTO, RFC), as well as articles on Linux. Rich set posted auxiliary utilities And software for the server (Apache, MySQL, MRTG, etc.).
Book:
Sections on this page:
The Telnet service provides basic terminal emulation of remote systems that support the Telnet protocol over the TCP/IP protocol. Emulation of Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY terminals is provided. The Telnet protocol is described in RFC 854, which you will find on the included CD.
Any commands issued using Telnet are processed by the telnet server, not local computer. The user only sees the result of executing these commands.
To use Telnet, a telnet daemon must be installed on the remote computer. A client program must be installed on the user's computer. In almost every operating system There is a telnet utility, which is a client for the telnet protocol (see Figure 8.2).
The Telnet service has been and remains one of the most popular ways to remotely register and work on a remote machine. Its main disadvantage is that any information, including passwords, is transmitted in clear text without any encryption.
SSH (Secure Shell) is a program that allows you to log into remote computers and establish an encrypted connection. There is also a "secure" version of telnet - stelnet.
SSH uses cryptography public key to encrypt the connection between two machines, as well as to authenticate users.
Rice. 8.2.Telnet client for Windows
The ssh shell can be used to securely log into a remote server or copy data between two machines, while preventing session hijacking and DNS spotting attacks.
Secure Shell supports the following encryption algorithms:
BlowFish is a 64-bit encryption scheme. This algorithm is often used for high-speed encryption of large volumes of data.
Triple DES(Data Encryption Standard) - standard for data encryption. This algorithm quite old, so it is not recommended to use it. Typically, DES is used to encrypt unclassified data.
IDEA(International Data Encryption Algorithm) - international information encryption algorithm. This algorithm works with a 128-bit key and is therefore more secure than BlowFish and DES.
RSA(Rivest-Shamir-Adelman algorithm) - Rivest-Shamir-Adelman algorithm. It is an encryption scheme with public and private keys.
When choosing an encryption algorithm, you need to consider the confidentiality of the information you need to transmit. If the information is secret, it is better to use IDEA or RSA algorithms. If you simply don't want to transfer data in cleartext, use the BlowFish algorithm, since it is much faster than DES.
The ssh shell is very effective against protocol analyzers because it not only encrypts, but also compresses the traffic before transmitting it to the remote computer. The ssh program can be downloaded from http://www.cs.hut.fi/ssh/. The UNIX version of ssh is free, but you have to pay for the Windows version (meaning the Windows client).
The ssh shell is indispensable in cases where you need to administer the server remotely or when the server does not have its own monitor. When using telnet, all data transmitted through the telnet connection is available in clear text. This means that usernames and passwords will be available to everyone who listens to traffic using the analyzer. SSH performs encryption using several different algorithms, including DES and 3DES.
The program consists of the sshd daemon, which runs on a Linux/UNIX machine, and the ssh client, which is distributed for both Linux and Windows. To install ssh, take the sources and place them in the /usr/src/ directory as usual. Then unpack the archive and install the program by following these steps:
cd /usr/src/
tar xzf ssh-2.4.0.tar.gz
cd ssh-2.4.0
./configure
make
make install
For ssh to start working, you need to start the sshd daemon on the machine to which you are supposed to connect. It is advisable to add a startup command to the system boot script to automatic start. The sshd daemon runs on port 22 (see Listing 8.6). If I'm not mistaken, ssh cannot be used together with xinetd/inetd - it must be launched like an httpd server in standalone mode.
Listing 8.6. Fragment of the /etc/services file
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
Usually there are no unpleasant issues with setting up sshd. Setting up the daemon will be discussed in detail later in this chapter. Now try to log in to this machine via ssh. To do this, you need to install the same package on another machine running Linux/UNIX (or install a Windows ssh client) and enter the command:
$ ssh hostname.domain
ssh will ask you to enter the user's password. The name will be used as the username to establish the connection current user, that is, the name under which you are currently registered in the system. If authentication is successful, the communication session will begin. You can terminate the session using the Ctrl+D key combination.
If you need to specify a different username, use the –l option of the ssh program:
ssh –l user hostname.ru
This way you can tell the ssh program which user should be used to register on the remote machine (see Fig. 8.3).
When using a Windows client, the computer name, user name and password must be entered in the program dialog box. If the connection fails, try selecting the blowfish encoding method. If that doesn't work, choose 3DES.
Working in ssh is similar to working in telnet. You can administer a remote machine just as easily as a local one. The ssh program options are listed in the table. 8.5.
Fig.8.Z. Registration on a remote machine
ssh program options Table 8.5
| Option | Description |
|---|---|
| -A | Disables connection agent authentication redirection |
| -A | Enables connection agent authentication redirection |
| -with blowfish|3des | Allows you to select the encryption algorithm when using the first version of the SSH protocol. You can specify either blowfish or 3des |
| -с cipher | Specifies a comma-separated list of ciphers in order of preference. Only for the second version of the SSH protocol. Valid values are blowfish, twofish, arcfour, cast, des and 3des |
| -f | This option puts ssh into the background after user authentication. It is recommended to use it to launch the X11 program. For example, ssh –f hostxterm |
| -i | ident_file Specifies a non-standard identification file (for non-standard RSA/DSA authentication) |
| -l username | Indicates on behalf of which user the registration on the remote machine will be carried out |
| -p port | Defines the port to which the ssh program will connect (default is port 22) |
| -q | "Quiet mode". Only fatal error messages will be displayed. All other warning messages will not be written to standard output. |
| -x | Disable X11 redirection |
| -X | Enable X11 redirection |
| -1 | Use only the first version of the SSH protocol |
| -2 | Use only version 2 of the SSH protocol |
| -4 | |
| -6 |
The ssh shell uses two configuration files ssh_conf and sshd_conf. I think there is no point in saying that they are located in the /etc/ssh directory. I recommend adding the following line to the sshd_conf file:
allowedadress 10.1.1.1 10.1.2.1 10.1.3.1
This means that access via ssh can only be performed from machines with addresses 10.1.1.1, 10.1.2.1, 10.1.3.1. This will protect your computer from unwanted intrusions from the outside.
The stelnet program is completely similar in everything telnet program, but it encrypts the traffic that is transmitted during the telnet connection.
The sshd daemon is a daemon program for the ssh shell. Typically sshd runs on the machine to which ssh clients connect. Latest versions The sshd daemon supports two versions of the ssh protocol - ssh version 1, and ssh version 2.
SSH protocol version 1
Each node has its own RSA key (usually 1024 bits), which is used to identify the node. This key is also called a public key. Additionally, when the daemon starts, another RSA key is generated - the server key (usually 768 bits). This key is regenerated every hour and is never saved to disk.
Each time a connection is established with a client, the daemon responds with its public key and the server key. The client compares the resulting public key with its database to check if it has changed. The client then randomly generates a 256-bit number and encodes it using two keys simultaneously - the public key and the server key. Both parties use this random number as a session key, which is used to encrypt all data transmitted during the session.
The client then attempts to authenticate itself using .rhosts authentication, RSA authentication, or password authentication.
Typically .rhosts authentication is insecure and is therefore disabled.
SSH protocol version 2
Version 2 works similarly: each node has a specific DSA key that is used to identify the node. However, when the daemon is started, a server key is not generated. Connection security is ensured by the Diffie-Hellman key agreement.
The session can be encoded using the following methods: 128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES.
The sshd daemon options are listed in table. 8.6.
sshd daemon options Table 8.6
| Option | Description |
|---|---|
| -b bits | Defines the number of bits for the server key (default 768). This option can only be used if you are using SSH protocol version 1 |
| -d | Debug mode (DEBUG). In this mode, the server does not go into the background and logs its actions in detail in the system log. Using this option is especially useful when studying how the server works |
| -e | If this option is specified, the sshd daemon sends debug messages to the standard error stream rather than to the system log. |
| -f config_file | Sets alternative file configurations. The default is /etc/ssh/sshd_config |
| -g time | Gives an unauthenticated client additional time to authenticate itself. The default time is 600 seconds. If the client is unable to authenticate itself within this time, the connection will be terminated. A value of 0 is interpreted as waiting indefinitely |
| -h | keyfile Specifies an alternate public key file (host key). The default file is /etc/ssh/ssh_host_key. This option may be needed to allow sshd to run as something other than root. Additionally, a common use of this option is to launch sshd from scripts specifying various settings depending on the time of day. For example, during the daytime (working) time some options are installed, and in the evening (working) time - others |
| -i | Used if you need to run sshd through the xinetd superserver (inetd). Usually the sshd daemon is not started by the xinetd (inetd) superserver, but is started at system boot, because the sshd daemon takes some time (10 seconds) to generate the server key before it can respond to client requests |
| -k time | Sets the time after which the server key will be recreated. The default time is 3600 seconds (1 hour). This option can only be used if you are using SSH protocol version 1 |
| -p port | Specifies an alternate port that the sshd daemon will listen on. The default is port 22 |
| -q "Quiet mode". | In this mode, session logging will not be performed. Typically the start of authentication, the result of authentication and the end time of the session are logged. |
| -t | Test mode. This mode used to check the correctness of the configuration file |
| -D | When using this option the daemon will not go into the background |
| -4 | It is allowed to use IP addresses only in IPv4 format |
| -6 | It is allowed to use IP addresses only in IPv6 format |
The daemon configuration file /etc/ssh/sshd_config looks something like Listing 8.7
Listing 8.7 Configuration file /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# This is the sshd server system-wide configuration file. See sshd(8)
# for more information.
Port 22
# Protocol 2.1
# ListenAddress 0.0.0.0
#ListenAddress::
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
#
# Don't read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
# IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
#PrintLastLog no
KeepAlive yes
#Logging
SyslogFacility AUTHPRIV
LogLevel INFO
# obsoletes QuietMode and FascistLogging
RhostsAuthentication no
#
# For this to work you will also need host keys in /etc/ssh/
ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
#
RSAAuthentication yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# Uncomment to enable RAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of "PasswordAuthentication"
# PAMAuthenticationViaKbdInt yes
# To change Kerberos options
# KerberosAuthentication no
# KerberosOrLocalPasswd yes
# AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
# KerberosTgtPassing yes
# CheckMail yes
# UseLogin no
# MaxStartups 10:30:60
# Banner /etc/issue.net
# ReverseMappingCheck yes
Subsystem sftp/usr/libexec/openssh/sftp-server
SSH (Secure Shell) is a remote access network protocol that uses encryption and compression for transmitted data. Simply put, this is a very useful and powerful tool that allows you to authenticate in the system and fully work on behalf of local user, being many kilometers away from a working machine. Also, unlike telnet and rsh, SSH encrypts all traffic, so that all transmitted information remains confidential.
So, we already have ssh installed and ssh-daemon is added to startup at system startup. You can control it with the command:
service ssh stop|start|restart
On Ubuntu, or:
/etc/init.d/ssh (start|stop|reload|force-reload|restart|status)
On Debian, or:
systemctl start|stop|restart sshd.service
In ArchLinux (after each edit of the config you need to restart). The kit includes a client and server.
Let's try it in action! First, create a folder ~/.ssh
mkdir ~/.ssh
Generate keys for given user server with the command:
ssh-keygen (as a regular user).
When generating, you can set a passphrase for the key (it is advisable to set a long one - then even having obtained the key but not knowing the password for the key, the attacker will not be able to log in), or you can skip it by simply pressing "Enter" - in this case, the password will never be won't ask. The same public and private key appeared in the ~/.ssh folder.
Find another car (even smartphone will do- there are some great SSH clients on Android, like ConnectBot or JuiceSSH), install ssh on it and connect to the server with the command:
ssh user@server
If done correctly, you will be prompted for the user's password, and once entered you will be logged into your system with a command line view.
For Windows, by the way, there are also ssh servers and clients.
Having enjoyed the result of our labors, let's move on to the even more boring part - setting up the client/server.
The client part config is in /etc/ssh/ssh_config, and the server one - /etc/ssh/sshd_config. Most complete guide on configuration is, perhaps, the page in man - man ssh and man sshd_config, so we recommend reading it. And in this article we will look at the most necessary things.
Settings
The standard ssh port is 22. It can be changed to any non-standard one (complicating possible hacking due to security through obscurity, or to attract the attention of potential hackers :) - to do this, uncomment the line:
#Port 22
And add any desired one up to 65535 (making sure that the port does not conflict with other services with the command #netstat -tupln | grep LISTEN).
Now, when connecting to the server, the client will need to write with the key:
ssh -p [port] :
By default, access as root is allowed. It is highly advisable to limit it (and instead properly delineate local user rights using sudo). To do this, find the line "PermitRootLogin" and change the value to "no". You can also change it to “without-password” - in this case, login as root will only be allowed from machines with a trusted key.
You can disable password authentication and work only with keys - find the line: "PasswordAuthentication" and change the value to "no". For what? If someone really wants to gain access to your system, they can either try to guess your password during authorization attempts, or listen in and decrypt your connection. If you disable password authentication and add the public key of your, for example, work laptop to ~/.ssh/authorized_keys on the server, then, as we remember, we will be allowed into the server immediately. But what if you are working on someone else’s machine and urgently need to gain access to the ssh server, but as expected, it won’t let us in? Then you can not disable password authentication, but use the fail2ban utility. Just install it from your repository, after which it will apply the default settings and, at a minimum, protect your ssh channel from brute-force hacking. More information about fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.
In case your server stores keys for launching nuclear missiles, you can do something like this:
PermitRootLogin no - login as root is prohibited.
PasswordAuthentication no - login without a password
Let's generate a long key on the remote machine (-t encryption_type, -b bit length):
ssh-keygen -t rsa -b 4096
With an equally complex passphrase (recover forgotten password, by the way, it’s impossible. You can change it with the command "ssh-keygen -p", but in any case you will be asked for the old one). Let's transfer the public key of the remote local machine to ~/.ssh/authorized_keys of the server, and voila - now access can be obtained from a single machine, using the passphrase of the private key. SSH allows you to configure many security configurations and has many specific settings for this - read about them in the man.
Two sshd_config parameters serve the same purpose:
LoginGraceTime- specifies the time after which the connection will be terminated if authentication does not occur.
MaxAuthTries- sets the number of incorrect attempts to enter a login, upon reaching which the connection will be terminated.
MaxSessions- number of simultaneous sessions (if the server is yours home computer, to which you are going to connect from university or from work, then it would be reasonable to limit the number of sessions to one - a rejected login, in this case, will become a reason for increasing paranoia, generating new keys and changing the password). However, if you are attentive, you might have noticed that every time you log in to the server, the line “Last Login” is displayed. In addition to it, you can add your own welcome message - find the line "Banner" and instead of none set the path to the file with the text that will be read and displayed upon login.
Among other things, you can allow only certain users to log in, or allow everyone except certain users:
AllowUsers user1- allow only user1 to login.
DenyUsers user1- allow everyone except user1.
And similar parameters for access of certain groups - AllowGroups and DenyGroups.
You can also transfer an X11 session over SSH. To do this, find the line "ForwardX11" and change the value to "yes".
Find a similar line in the client config - /etc/ssh/ssh_config, and also change it to “yes”.
Now you need to connect to the server via ssh with the -X argument:
ssh -X user@server>
You can immediately launch the application upon connection:
ssh -X user@server "application"
This is what a running GIMP looks like in an ssh session:
Or you can get output from an unsuspecting user's laptop webcam :)
The calculations are performed directly on the server, and the output is transferred to the client machine (that is, even if the server itself does not have X11 installed, graphical applications can be rendered on your remote machine). This scheme works quite slowly (don’t forget that all traffic is dynamically encrypted) - but this function is very useful.
You can also copy files using an SSH session - there is a simple "scp" utility for this. You can transfer files directly in the session, both from server to client:
scp user@server:/path/to/file/on/server/where/to/save/on/local/machine
So from client to server:
scp path/to/file/client user@server:/path/on/server
This is quite convenient if you need to copy a text book or a photo, but what to do when you have to work with many files? There is a very convenient thing for this - sshfs (available for installation in the repositories of most *nix systems).
Just set the path similar to scp:
sshfs user@server:/home/user /mnt/
And the server’s /home/user folder will appear at the /mnt mount point of the local machine!
Unmounting is done via umount.
And finally, let’s talk about one little-known feature. If you create a file /.ssh/config and fill it like this:
Host [name]
Hostname
User [server username]
desired options
like
ForwardX11 yes
Port 30000
Then we can log in using:
ssh [name]
ssh -X -p 30000 user@server
And all options will be picked up automatically. Thus, by frequently authenticating to a specific server, you will simplify this process to a matter of a couple of moments.
Well, we've covered everything (and even more) that you need to know about SSH for everyday use - we've learned how to use key authentication, protected the server from brute force hacking and, in general, patched most of the potential holes. In fact, SSH can do many other things - for example, tunneling and port forwarding through an SSH session, but it is unlikely that you, as an ordinary user, will ever use this. Additional Resources
Loading...
