Date published: Tuesday, January 19, 2009 10:43:53
Translation: Kovalenko A.M.
Transfer date: August 4, 2009

Do you use both Windows and Linux? Can you remotely control Windows from Linux (Ubuntu or another distribution) or Linux from Windows? Surely you can. Similar to how it is used Remote Desktop Connection between Microsoft platforms(or remote control between Linux machines), it is also possible to control the desktop from different platforms. You can click on your desktop and launch applications, just as you would if you were sitting directly in front of your computer.

We'll discuss a few different features you can get using a Remote Desktop Connection. Plus, we'll walk you through a step-by-step method of establishing a remote desktop connection using free tools. So let's get started.

Selecting a Remote Desktop Protocol

Remote desktop applications typically use either Remote Desktop Protocol(RDP) or protocol Virtual Computer Network (VNC). To establish a remote connection, both nodes (server and client) must support the same protocol. The problem is that not all operating systems (OS) use the same protocols by default. In addition to this, some Linux distributions and some Windows edition do not contain either a remote desktop server or client application, or do not contain a remote desktop application at all.

Your first task should be to determine the protocol that is already supported on your computers. In addition to researching your OS, searching for documentation, linking to cheat sheets, you should be able to understand what is what and where. Then, at the end, you must select the protocol to use on all your computers.

Note:

• Remote desktop VNC is generally slower than RDP connections, however, VNC is usually easier to implement on a variety of platforms.
• For better performance and security, you can use the free NoMachine's NX server and clients or the FreeNX server and clients, but it is more complex to configure and requires some thought.
• It is also possible to provide support for RDP connections on Linux machines, for example, using an xrdp server.

Opening a firewall (firewall)

Before you can start making or accepting remote connections, you need to configure your firewall software. The computers you want to connect to remotely must allow VNC or RDP traffic through your firewall.

In Windows, when the server starts, you should receive a request to Block or Allow network access to the remote desktop server application. If you click the "Allow" button, everything should work. If you do not receive the request, you can go to the Windows Firewall properties and manually add permission for this application using the port numbers listed below.

On Linux, you will most likely need to manually add incoming connection rules to the firewall on the computer receiving the connection requests. If necessary, you can call the browser from the menu and search in Google information about how to configure a firewall. Your Linux distribution may include a GUI (graphical user interface) for your firewall, or you can use the command line to configure it. In the same way, add an exception or rule to allow traffic on the appropriate ports listed below.

• RDP uses TCP port 3389
• VNC uses ports starting at 5900 (each remote connection to the server uses a different port; display 1 uses port 5901, display 2 uses port 5902, etc.). The best method Therefore, there will be a port scope definition (such as 5900 - 5905) when you create a firewall rule or exception.

Now you have the ability to remotely connect to computers in your local network. To connect remotely via the Internet, you must also configure your router. We will discuss this in the next part.

Using VNC server and client in Ubuntu

If you are using Ububntu, then you already have a VNC client and server installed and ready to use. (This article is based on the Ubuntu Desktop 8.10 Intrepid Ibex distribution.) To be able to accept remote connections, simply select System > Properties > Remote Desktop. In the dialog box, configure the desired shares and security settings. The command/address list is presented to you to indicate other computers on the local network with Ubuntu or other installed Linux distribution, from which the connection will be made.

To use the VNC viewer on Ubuntu, select Applications > System Tools > Terminal. If you are connecting to a computer running Ubuntu, type the command suggested by Ubuntu. If you are connecting to a computer running another Linux distribution, the following command format is used:

$vncviewerComputerName or _IP_address:#

as shown in Figure 1. This line contains the command, vncviewer, followed by the name or IP address of the computer (or Internet IP if the connection is via the web), ending with a colon and the ID (identifier) ​​of the display (tunnel). If you are connecting to a computer on which Windows is installed, then the colon and display number are not specified, in which case the command format is as follows:

$ vncviewerComputer_name_or_IP_address

picture 1

Installing VNC Client and Server on other Linux distributions

If you are using a Linux distribution other than Ubuntu, look in its repositories for appropriate packages for installing VNC server and client. If there are no such packages, then you can download TightVNC directly from their website and follow the assembly and installation instructions.

TightVNC/RealVNC server does not have GUI, you have to use the command line, but don't worry - it's easy. Just open Terminal, type vncserver and press Enter. When you first start it, you will be asked to create a password for VNC connections. Once you have set the password, the display or tunnel will be automatically configured as shown in Figure 2.

figure 2

VNC supports multiple displays to provide access to a large number of users and/or to define variations in attributes such as screen resolution, startup commands, etc. Each time it is run, the vncserver command creates a new tunnel, with a number usually starting from 1, which is incremented by one each time the command is run.

Below are various vncserver command options that are useful to remember:

• For help, use the -help option or enter the man vncserver command.
• Using the -name desiredname option you can assign a name to a specific tunnel or display, which is displayed in the VNC client title bar when a remote connection is made to that display.
• Correction:# allows you to manually define the tunnel or display number.
• Using the -geometry WxH option you can set the screen width and height for displaying the remote desktop.
• By adding -depth # you can set the color depth from 8 to 32 bits per pixel.
• To close a VNC tunnel, use the -kill:# option, replacing the hash icon with the desired tunnel (display) identifier.

Depending on the specific Linux distribution and the VNC solution that is installed, you may or may not have a graphical user interface for the client or viewer application. If a GUI is available, feel free to use it, but you can also use the command line if you wish.

For a GUI, you can usually configure options from a dialog box. When connecting to a machine running a Linux distribution, type the computer name or IP address of the remote machine (or Internet IP when connecting via the web), followed by a colon, the tunnel or display ID, and press Enter. For example, ericlinuxbox:1 or 192.168.0.122:1. If you are connecting to a Windows machine, the colon and display number are not required. To connect from a terminal, enter vncviewer and host information in the same manner as shown in Figure 1 earlier.

Installing VNC client/server on Windows

TightVNC also offers a client and server in a Windows version on its download page. After installing TightVNC you can start the server from the menu Start (approx. translator: Start > All Programs > TightVNC), selecting Launch TightVNC server. This will bring up a properties dialog (see Figure 3) where you must assign a password for incoming sessions.

figure 3

After checking all settings, click OK. The server will be running and ready to receive incoming connections, and at the same time the server icon will appear in the system tray. Once again, do not use a colon and display number when connecting to a Windows computer from any platform.

If you are connecting to a remote computer from Windows, select the TightVNC Viewer shortcut from start menu. Similarly, to connect from other platforms, enter the name or IP address of the remote computer (or Internet IP address when connecting via the web), and when connecting to a Linux computer, include a colon and display number in the command.

July 28

New versions of Ubuntu already have a built-in VNC server. We will use his standard tools. While I was understanding this issue, I had to read a decent number of forums. So, many users write that in version ubuntu 14.04 this trick does not work due to some internal subtleties of the kernel structure. I didn’t go into this question deeply... in any case, if suddenly you are the happy owner of this particular version, you can use the alternative x11vnc server.

It is installed quite simply:

Sudo apt-get remove vino sudo apt-get install x11vnc

In the same article, we will look at the standard VNC server already included in ubuntu by default. How to set everything up?

Let's connect to the remote host.

We connect via ssh to the remote computer to which we want to gain graphical access. At the same time, we must know its ip and login with the password of the user whose screen we want to see. In fact, the data of any user with sudo rights will suit us, but then we will have to adjust some points.

So, let's say on a local network we have a computer running Ubuntu with an IP address of 10.20.0.30 and a user feanor184. We connect to it from the console with the -X key (to launch graphic X):

Ssh -X [email protected]

enter the password and get into the console of our remote computer.

Now, enter in it:

Sudo vino-preferences

and see the graphic window

Check the boxes here:

allow other users to view your desktop — We allow you to view your desktop.

allow other users to control your desktop — We allow you to control the mouse and keyboard remotely.

require the user to enter this password — Be sure to set a password for the connection. How many people are surfing our network?

show notification area icon: always — We always display the vnc icon at the top of the screen in the tray.

You can also set your own settings - my settings are described here)

Save the settings and disconnect from the remote host.

To connect to the configured computer, we use any client with vnc support.

For example, Remmina is for Linux.

UltraVNC Viewer - for Windows.

Let me remind you once again that in order for the described connection settings to work, the remote computer must be running Ubuntu OS. Installing ubuntu is a separate topic that I would not like to focus on here, so we will skip this step. There are many manuals on this topic on the Internet.

What do we end up with?

We were able to connect to a remote computer running ubuntu and perform any operations on it as if we were sitting at its monitor.

To the service technical support RUVDS is regularly contacted about the GUI and remote access to it on virtual servers with Linux, despite the fact that there is a lot of material on the Internet covering this problem. Therefore, for our users, we decided to collect everything on this topic in one article.

You can also forward RDP traffic through an SSH tunnel. To do this, you need to edit the xrdp configuration file:

$ vi /etc/xrdp/xrdp.ini
You need to add the line to the section: address=127.0.0.1

$ systemctl restart xrdp
You can check that everything is correct like this:

$ nmap -p 3389 Starting Nmap 6.47 (http://nmap.org) at 2016-10-04 13:07 MSK Nmap scan report for unspecified.mtw.ru () Host is up (0.0087s latency). PORT STATE SERVICE 3389/tcp closed ms-wbt-server
Then if you are using cygwin or mingw, linux or mac os:

Ssh root@ -L 3389:localhost:3389
If PuTTY:

Launch PuTTY. In the tree menu on the left Connection → SSH → Tunnels. Next, add a new Forwarded Port (Source port: 3389, Destination: localhost:3389). Click Add.

VNC

Client:

For example, let's put this DE:

$ apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E $ echo "deb http://packages.x2go.org/debian jessie main" > /etc/apt/sources.list.d/x2go .list $ echo "deb-src http://packages.x2go.org/debian jessie main" >> /etc/apt/sources.list.d/x2go.list $ apt-get update $ apt-get install x2go- keyring && apt-get update $ apt-get install x2goserver x2goserver-xsession
The output of the following command should show that x2go is ready to go:

$ systemctl status x2goserver ● x2goserver.service - LSB: Start and stop the X2Go daemon Loaded: loaded (/etc/init.d/x2goserver) Active: active (running) since Tue 2016-10-11 22:05:51 MSK; 30min ago...
And now an important point, you won’t be able to connect without this fix! You need to find the line “mesg n” in the .profile file and replace it with “tty -s && mesg n”.

$vi.profile
The following command will display the path to the startfluxbox executable file, which will be needed when setting up the client:

$whereis startfluxbox
Installing a server on Ubuntu:

$ apt-get install xfce4 xfce4-terminal $ add-apt-repository ppa:x2go/stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession

$vi.profile
Installing a server on CentOS:

$ yum install epel-release $ yum install x2goserver x2goserver-xsession
The client for Linux is installed from the above repositories with the following command:

$ apt-get install x2goclient
For Windows - download, install, launch. There is a client for OS X at the same link above.

Let's launch the client:

In the session settings we indicate: in the Host field - the IP of your server, in the Login field - root, leave the port as is, session type - the GUI that was installed.

As you can see, there is an option for key authentication. In general, a lot of things. See for yourself. And the sound can be output through PulseAudio.

After clicking Ok, you will see these charming little things that you need to click on to receive a request to enter a password and connect to the selected session:

Note: please note that your favorite FluxBox is not in the list, so you have to write the path to it manually.

An important feature of x2go is the ability to run any graphical application without installing DE at all. To do this, in the session settings you need to select the single application item in the session type section and select the application to run or enter the path to the program that should be launched.

In this case, installing the software on the server will look like this. In the case of Ubuntu:

$ add-apt-repository ppa:x2go/stable $ apt-get update $ apt-get install x2goserver x2goserver-xsession
And now an important point, you won’t be able to connect without this fix! You need to find the line “mesg n ||” in the .profile file. true" and replace it with "tty -s && mesg n".

$ vi .profile $ apt-get install firefox xterm
And by setting up a session as shown below, you can launch the browser on the remote server, and a window displaying it will open on your machine:

Or so; then a terminal window will simply open:

Below you can see a screenshot of the current session status window. The buttons are marked with orange numbers:

1. “Suspend session” - after clicking this button, the connection will be terminated, but the session will remain and will wait for reconnection. All applications you launched on the server will continue to work;
2. “Terminate session” - after clicking, the connection to the server will be terminated, and the applications you are running on the server will be terminated.

TeamViewer

The latest method to access your desktop remotely.

Installation on Ubuntu:

$ apt-get update $ apt-get install lubuntu-desktop $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386 .deb $ apt-get -f install $ teamviewer --passwd
Installation on Debian:

$ apt-get update $ apt-get install lxde lightdm $ reboot $ dpkg --add-architecture i386 $ apt-get update $ wget http://download.teamviewer.com/download/teamviewer_i386.deb $ dpkg -i teamviewer_i386. deb $ apt-get -f install $ teamviewer --passwd
Installation on CentOS:

$ yum groupinstall "X Window system" $ yum install epel-release $ yum install fluxbox xterm lightdm $ systemctl set-default graphical.target $ reboot $ curl -o TeamViewer_Linux_PubKey.asc -Lk http://www.teamviewer.com/link /?url=354858 $ rpm --import TeamViewer_Linux_PubKey.asc $ curl -LOk http://download.teamviewer.com/download/teamviewer.i686.rpm $ yum install teamviewer.i686.rpm $ teamviewer --passwd
It is also necessary to accept license agreement TeamViewer, this can be done using “Emergency mode”, or add the following lines to the end of the /opt/teamviewer/config/global.conf file:

$ echo " EulaAccepted = 1" >> /opt/teamviewer/config/global.conf $ echo " EulaAcceptedRevision = 6" >> /opt/teamviewer/config/global.conf $ teamviewer --daemon restart
The following command will show the state of the TeamViewer daemon and the nine-digit TeamViewer ID required for connection:

$ teamviewer --info

After launching the client downloaded here, you need to enter the TeamViewer ID in the Partner UD field and click on the “Connect to partner” button. Next, TeamViewer will ask for a password: .

Instead of a conclusion

That seems to be all. We hope that this article will help users of Linux servers in setting up a comfortable and convenient environment for them.

Samba is effective method not only organize the interaction of computers under Windows control and Linux, but also in networks consisting only of Linux machines, it allows you to quickly organize general access to resources. The Samba configuration file can be enormously long and have many parameters to consider, but in most cases far fewer settings are sufficient.

If we want to share ourselves and have access to files on other computers, then we need to install three packages:

sudo aptitude install samba smbclient smbfs

Let's create backup copy/etc/samba/smb.conf:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.backup

Now let's open the /etc/samba/smb.conf file for editing:

sudo nano /etc/samba/smb.conf

Clear and insert something like this:

workgroup = home

netbios name = linux--server

server string = linux_file_server

security = user

browseable = yes

path = /home/download

comment = download

readonly = No

path = /home/torrent

comment = torrent

readonly = No

path = /home/virtdiver/hdisk

comment = hdisk_250G

readonly = No

workgroup– this is the network name and must be the same for all computers.

netbios name – sets the NetBIOS name by which the Samba server will be accessible. By default, the first part of the computer's domain name is used.

server string- description of the computer, an analogue of a similar value in Windows.

security- determines access to shared directories.

security = USER- The client must first log in with an existing username and password. Note that the name of the requested resource will not be sent to the server until the server authenticates the client. This is why guest accounts do not work in USER mode, preventing the server from converting unidentified users into guests.

security = SHARE- When clients join a resource with security = SHARE they do not need to register with a valid username and password. Instead, clients send authentication information (passwords) to a specific resource when they want to access that resource. In SHARE mode, the user is not required to send his name, only his password.

security = SERVER - In this mode, Samba will try to determine the correct user/password pair by passing it to another SMB server, such as NT. If this fails, security = USER will work.

security = ADS- In this mode, Samba works as a member of the AD domain.

security = DOMAIN- In this mode, Samba will try to recognize the username and password by passing them to the primary or backup Windows NT domain controllers, i.e. will do the same thing he would do Windows server N.T.

Note:I checked with the share and user parameters, in both cases there were no problems either when connecting to Windows 7 or when connecting from a machine running Linux, but with a PDA running WM 6.1 I was able to connect only in user mode.

browseable- whether you want to make all subdirectories of the shared directory available. This option can also be used separately for each shared directory.

path- path to the shared folder. In this particular example, the torrent folder (for uploading torrent files for the rtorrent program), download (for downloading uploaded rtorrent files) and the hdisk folder in which my external hard drive is mounted will be shared.

comment- a comment.

readonly- only for reading. Please note that Samba can limit user rights, but cannot expand system-defined rights. That is, if the shared directory does not have write permissions for everyone in the system itself, Samba will not be able to allow third-party users to write to it. However, if the directory has permissions 777, then by setting the readonly = Yes parameter you can limit write access for users connecting from the network.

guest ok = Yes- add if you want to make access without authorization. (In mode

security = USER will not work, see above)

We give rights to the folders:

sudo chmod 777 /home/torrent/ and similarly for others.

After completing the configuration, run the command:

testparm

it will automatically check the configuration file. After this, reboot Samba:

sudo /etc/init.d/samba restart

sudo smbpasswd -a virtdiver # add user to samba

We mount in Linux network folders So:

sudo smbmount //192.168.1.33/hdisk/ /home/virtdiver/hdisk/ -o rw,iocharset=utf8,usermame=virtdiver,password=pass

sudo smbmount //linux--server/hdisk/ ~/hdisk/ -o rw,iocharset=utf8,usermame=virtdiver,password=pass

unmount:

sudo smbumount ~/hdisk

It is inconvenient to enter three such lines, so we write a script.

touch samba.sh

nanosamba.sh

write to the file:

#!/bin/bash

echo "Mount //192.168.1.33/hdisk/"

sudo smbmount //192.168.1.33/hdisk/ /home/virtdiver/hdisk/ -o rw,iocharset=utf8,usermame=virtdiver

echo "Mount //192.168.1.33/torrent/"

sudo smbmount //192.168.1.33/torrent/ /home/virtdiver/torrent/ -o rw,iocharset=utf8,usermame=virtdiver

echo "Mount //192.168.1.33/download/"

sudo smbmount //192.168.1.33/download/ /home/virtdiver/download/ -o rw,iocharset=utf8,usermame=virtdiver

We give execution rights to:

sudo chmod 755 samba.sh

let's launch.

5. Move the panel Buttons and Location address bar using the mouse.

6. Resize panels using special sizing handles on window borders.

7. Run the vi command in the right pane.

8. In the left view pane, open the applet by pressing the keys .

9. On the bottom panel, use the compiler and other tools command line.

10. Select the Setting Save View Profile option to save the profile.

11. Enter a name for the profile and then select the Save window size in profile option. After this, you need to click on the Save button to save the settings.

6. Control questions

1. What programs are called file managers?

2. What information is displayed in the Konqueror view area?

3. How to create a new window using Konqueror?

4. List management tasks file system, which can be solved using the file manager?

5. List standard features KDE.

6. What is the KDE desktop component?

7. Name the functions of the desktop panel.

8. How can I get online help?

9. What features does the KDE Control Center provide?

Literature 1,3,4

Lab #9 Remote Access in Linux

Purpose of work: To become familiar with remote control tools in the operating room. Linux system. Gain experience and skills in remote access management

Lesson plan

4. Using theoretical information, study the purpose and rules of working with the ssh service.

5. If necessary, install the required software (ssh, sshd, putty).

6. Provide access via ssh to your computer. Grant the rights and password to remotely control your computer to a neighboring - counterclockwise - computer.

7. Establish a remote connection to a remote computer. The computer next to it clockwise acts as the Remote. That is, you must control the computer on your right remotely, and provide the ability for the computer on your left to remotely control your computer.

8. To make a report.

Brief theoretical information

1. Remote access protocols: telnet and ssh

The UNIX operating system was originally developed as an Internet server. Tools for working with the Network are built directly into the core of this operating system, and all the necessary software for organizing a server is included in the distribution kit. UNIX works with all network protocols (especially TCP/IP) better than any other operating system for Intel platforms. It is not without reason that they say that UNIX is designed for the network, like a bird is for flight. All the qualities listed above also apply to the Linux OS. There are many areas where Linux servers are used: WWW servers, FTP servers, mailers, gateways. Therefore, remote management of a Linux server is of great importance.

For remote access to Linux, two protocols are used: telnet and SSH. Telnet is an Internet data line protocol that allows

computer to function as a terminal running under the control of a remote computer. The telnet protocol was originally developed for the ARPAnet and is an important part of the TCP/IP data transfer protocol.

There are three main problems associated with using telnet, making it a poor choice for modern systems from a security point of view:

The default telnet daemons have several vulnerabilities discovered over the years, and probably several more still exist.

Telnet does not encrypt any data that is sent over the established connection (including passwords), and thus it becomes possible to eavesdrop on the communication and use the password later for malicious purposes.

The absence of an authentication system in telnet does not provide any guarantee that the connection established between two remote hosts will not be interrupted in the middle.

It is not advisable to use the telnet protocol on security-sensitive systems, such as the public Internet. Telnet sessions do not support data encryption. This means anyone who has access to any router, switch or gateway on a network between two remote computers connected

communication session via the telnet protocol, can intercept passing packets and easily obtain the login and password to access the system (or take possession of any other information exchanged between these computers) using any publicly available utility like tcpdump and Ethereal.

SSH - (Secure Shell) - network protocol, allowing you to remotely control your computer and transfer files. Similar in functionality to the telnet protocol, but 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.

Since using the telnet protocol for remote control is incorrect from a security point of view, laboratory work Let's consider only remote control via SSH.

On this moment There are two versions of the SSH protocol: Description of SSH-1 protocol technology:

First, the client sends a request to the server to establish an SSH connection and create a new session. The connection will be accepted by the server if it accepts messages of this kind and is ready to open a new communication session. The client and server then exchange information about which protocol versions they support. The connection will continue if a match is found between the protocols and confirmation is received that both parties are ready to continue the connection via this protocol. Immediately after this, the server sends the client permanent public and temporary server keys. The client uses these keys to encrypt the session key. Even though the temporary key is sent in plain text, the session key is still secure. The session key is then encrypted with the temporary key and the server's public key and thus only the server can decrypt it. At this stage, both the client and server have the session key and are therefore ready to securely transmit encrypted packets.

Server authentication is based on its ability to decrypt the session key, which is encrypted with the server's public key. Client authentication can occur in a variety of ways, including DSA, RSA, OpenPGP, or

by password. The session continues as long as both the client and server are able to authenticate each other. Established connection via SSH protocol-1 allows you to protect transmitted data with a strong encryption algorithm, data integrity check and compression.

Description of SSH-2 protocol technology:

Both protocols essentially perform the same functions, but the SSH-2 protocol does it more elegantly, more securely, and more flexiblely. The main difference between the protocols is that the SSH-2 protocol divides all the functions of the SSH protocol between three protocols, while the SSH-1 protocol is one single and indivisible protocol. By modulating the functions of the SSH protocol into three protocols - the transport layer protocol, the authentication protocol and the connection protocol, SSH-2 makes the most flexible and powerful mechanism for creating secure tunnels. Given below short description and the purpose of each of the three protocols that make up the SSH-2 protocol:

Transport layer protocol – provides the ability to encrypt and compress transmitted data, and also implements a data integrity monitoring system.

Connection Protocol – Allows clients to establish a multi-threaded connection through the native SSH tunnel, thus reducing the load that client processes create.

Authentication Protocol – The authentication protocol is separate from the transport layer protocol because It is not always necessary to use an authentication system. If authentication is required, the process is protected by the original secure channel established through the transport layer protocol.

It should be noted that the SSH protocol does not solve all problems network security. 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.

The SSH server is the sshd daemon, which runs on a UNIX machine.

Currently, OpenSSH, PuTTY, SecureCRT, SFTPPlus, TeraTerm, etc. are used as SSH clients. In the laboratory workshop, the most common OpenSSH will be used to connect a Linux client and PuTTY to connect a Windows client.

OpenSSH (Open Secure Shell - open secure shell) - a set of programs,

providing encryption of communication sessions via computer networks using the SSH protocol. It was created under the leadership of Theo de Raadt as an open alternative to commercial software from SSH Communications Security.

PuTTY (from TTY - teletype, English putty - putty) is a freely distributed client for SSH protocols. Originally developed for Windows, but later ported to Unix.

2. Setting up ssh server on server

For the SSH service to start working on the server, you need to start the sshd daemon on it. It is advisable to add a startup command to the system boot script. The sshd daemon runs on port 22. You can run it from under the xinetd/inetd super daemon, but usually sshd starts on its own - in standalone mode._

The sshd server configuration file is called /etc/ssh/sshd_config. Help on its syntax can be obtained using the man 5 sshd_config command. The openssh-server package contains a configuration file with typical settings.

To protect your computer from unwanted intrusions from the outside, it is recommended to enter the allowedadress directive into the configuration file and list, separated by spaces, the IP addresses of those machines from which clients are allowed to log in. For example, for the ws2 workstation in the laboratory, you can allow remote connections only from the teacher’s computer and the closest computer on the left:

allowedadress 192.168.1.100 192.168.1.101

Example configuration file /etc/ssh/sshd_config:

# First we try to work using the SSH 2 protocol, and then,

# if that side does not support the second version, - via SSH 1 Protocol 2.1

# Key for SSH protocol version 1 HostKey /etc/openssh/ssh_host_key

# Keys for the SSH2 protocol - RSA and DSA HostKey /etc/openssh/sshjiost_.rsajtey HostKey /etc/openssh/ssh_host_dsa_key

# Lifetime and key size of ssh version 1 KeyRegenerationlnterval 3600

# The default size is 768 bits, set to 1024 ServerKeyBits 1024

# The time after which the server keys will be recreated.

# Changing keys periodically increases system security.

KeyRegenerationlninterval lh

# We prohibit registration of the root user via ssh.

# This does not exclude the possibility of remote

# administration: you just have to log in as root

# as a normal user, and then run the su command.

# But the attacker will need to steal

# not one, but two passwords: both root and regular user.

PermitRootLogin no

# Logging (uncomment if necessary

# log using syslog) #SyslogFacility AUTH

# Authentication

# Enables password authentication

# and prohibits empty passwords

PasswordAuthentication yes PermitEmptyPasswords no

#StrictModes yes

# use RSA authentication

RSAAuthentication yes PubkeyAuthentication yes

# rhosts authentication - not usually used,

# therefore we prohibit it:

# user files-/.rhosts and -/.shosts will not be used

RhostsAuthentication no IgnoreRhosts yes

# DO NOT use RAM authentication

PAMAuthenticationViaKbdlnt no

# Additional time for the client to authenticate himself.

# If during this time the client was unable to enter the password,

# the connection will be terminated

LoginGraceTime 2m

# Path to banner

Banner /some/path

# Sftp server subsystem

Subsystem sftp /usr/libexec/openssh/sftp-server

The keys with which you can run sshd are listed in Table 9.1.

	Table 9.1. sshd server keys.
	Purpose
	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
	Debug mode (DEBUG). In this mode, the server does not go into the background
	mode, handles only one connection and logs in detail
	your actions in the system log. The debug key is especially useful for
	studying the operation of the server.
	Just like when using the previous key, the sshd server will not
	go to background mode. However, unlike -d, the -D switch does not translate

	server in debug mode
	Send debug messages not to the system log, but to the standard one
	error stream
	Specifies an alternative configuration file instead of /etc/ssh/sshd_config
	Provides an unauthenticated client with additional
	time to enter the password. A value of 0 is interpreted as infinite
	expectation
	Specifies an alternate public key file (host key). Default
key_file	The file /etc/ssh/ssh_host_key is used. This key may be needed
	to run sshd as an unprivileged user. Also
	The -h switch is often used when starting sshd from scripts that specify
	various settings depending on the time of day (working and
	non-working hours)
	Used if you need to run sshd through the xinetd superserver. Usually
	The sshd daemon starts separately when the system boots. This is due to the fact that
	that the sshd daemon takes some time to generate the key
	server before it can respond to client requests. On startup
	through the superserver, with each connection the superserver will be re-created
	call sshd, and it will regenerate the key. However, on modern
	On computers the delay is almost unnoticeable. Therefore it is quite possible
	run sshd and via superserver
	Sets the time after which the server key will be recreated. By
	The default time is 1 hour. This option can only be used with
	SSH protocol version 1
	Specifies an alternate port that the sshd daemon will listen on
	instead of port 22
	“Silent mode”: do not log the session. Usually logged
	authentication start, authentication result and end time
	Test mode. Used to check the correctness of the file
	configurations
	It is allowed to use IP addresses only in IPv4 format
	It is allowed to use IP addresses only in IPv6 format
		Remote access from a Linux client

Let's start the server with CentOS Linux. Using the ps (process status) command with the C (by command name) and l (long format) keys, we will check whether the sshd daemon is running, and with the ifconfig command

Let's check the server address (Fig. 7.1).

Rice. 9.1. Checking the sshd service load and server IP address We see that the sshd process is running. Its parent is the process

initialization with ID 1. The server IP address is, as was specified during installation, 192.168.100.3.

We boot the client machine with Alt Linux Lite. We launch a terminal on it and check the connection with the server - type the command ping 192.168.100.3. As can be seen from Fig. 9.2 it is not possible to establish a connection to the server immediately after downloading.

Rice. 9.2. Checking connection with the Linux server

IP protocol configuration is required. Select (see Fig. 7.3) Settings - System Control Center - Network, enter the IP address 192.168.100.4 and click the “Apply” button.

Rice. 9.3. Setting up an IP interface on a Linux client

We again check the possibility of establishing a connection with the server. As can be seen from Fig. 9.4 the client now “sees” the server.

Rice. 9.4. After connecting the client to the 192.168.100 network, the connection is established. Since the setting is not saved when booting from a Live-CD, set the IP address

the client needs it every time he boots Alt Linux from a Live-CD. Now we try to connect remotely to the server.

The ssh client program can be launched with numerous keys; the general format for launching it is as follows:.

ssh [keys] [keys_with_arguments] [login_name@]host.domain [command]

We will use the l key, which can be used to specify which user will be used to log on to the remote machine, and the v key, which enables the display of all debugging information. We type the ssh command with the server address and these keys. As you can see from this figure, the client and server have exchanged information about which protocol versions they support (OpenSHH_4.7p1 on client side and OpenSHH_4.3 on the server), the server sent an open RSA key and the program asks the user for confirmation to include the server in the list of known hosts.

Rice. 9.5. Obtaining a public key to encrypt data from the server.

This is an important property of the SSH protocol. It is designed to protect the user against attacks known as spoofing or man-in-the-middle. One of the problems associated with older protocols such as Telnet, FTP, RSH, etc., in addition to the fact that they transmit all information in clear text, is that these protocols are vulnerable to this type of attack. An attacker with access to the intermediate network

can intercept your packets, store them, and then send them to the direct recipient. Even worse, it can overwrite your packets, for example by replacing ls -la mydir with rm -r mydir (delete instead of viewing) or send you a rooted file instead of the original through your intercepted FTP session. The attacker could finally simply redirect your connection to another computer, so that you send your password to another machine. Using this technique, an attacker will be able to find out the password that protects your account, and will then be able to register under your name for its own purposes.

SSH provides the ability to verify the identity of the host you are connecting to. If you have verified the host correctly, there is no way for an intermediate device to read or manipulate your packets. Successful host verification indicates that the connection is end-to-end encrypted - your SSH client has established a secure connection directly to the SSH server, and no intermediate machines have access to this connection.

Since this is the first time we've connected to this machine, and SSH doesn't rely on a third party trustee like Certificate Authorities, all the work involved with key management is on you. Your client displays a public key fingerprint, an easy-to-read string of numbers that you can use to manually verify the key. If you answer "Yes, the fingerprint is correct", your SSH client will continue with the authentication, giving you the opportunity to enter your password and get started.

How do you know you've received the correct key? After all, if, while connecting to the server, an attacker intercepted your SSH connection and passed all the traffic through himself, he can slip you his key, instead of the host’s real public key. There are several ways to verify the authenticity of a key. For example, the system owner can place the key fingerprint on his secure web page. Another option is you can call system administrator host and check the key over the phone (if the possibility of an attacker intercepting a telephone conversation is excluded).

We confirm the continuation of the connection by typing yes, and we receive a message from the program that the server is included in the list of known hosts (Fig. 9.6).

Rice. 9.6. RSA check

When you answered yes, our SSH client stored the server key in a known_hosts file, which is essentially your personal Certificate Authority - a list of the keys of all the SSH servers you work with.

Now you can connect to the server remotely. Repeat the command ssh 192.168.100.3 –l root –v

and we receive information about the establishment of a connection (Fig. 9.7), where the last stage of authentication is entering the password of the root user of the remote server computer.

Rice. 9.7. Debugging information for a remote connection Enter the server root user password (Fig. 9.8) and enter the remote control session.

Rice. 9.8. Remote connection procedure after entering the password You can now manage the server remotely. You can, for example, reboot it remotely by executing the reboot command, as shown in the following Figure 9.9.

This figure shows that immediately after the reboot command, it is not possible to re-establish a remote connection - the server has not yet booted. Once the connection is established, the ps command shows that there are two user processes running on the server − bash shell and the ps command itself. Both processes are started from the remote console pts/0.

Let's finish remote session logout command.

The developed laboratory setup allows you to study remote control of a Linux server in detail. SSH configuration on the server can be done using the sshd_config configuration file. The user can get help on its syntax using the man sshd_config command. In the package openssh-server there is a configuration file with standard settings.

4. Remote access from Windows client

Not everyone has built-in SSH clients. operating systems, UNIX has it, Windows doesn't. Under Windows you can install an SSH client - PuTTY, ( official server http://www.chiark.greenend.org.uk/~sgtatham/putty/). Composition of the distribution used

PuTTY is shown in Fig. 9.10.

Fig.9.10. Composition of the PuTTY distribution.

Putty is several separate programs designed to work with a unix server using the SSH1, SSH2, Telnet, Rlogin, Raw protocols. The program runs on Windows for Intel x86 and Alpha, as well as on UNIX. Shown in Fig. 9.11 a complete set of programs, under the general name PuTTY, consists of the following utilities:

- putty.hlp – help file;

- putty.exe - client for connecting to the server via telnet protocols, ssh, raw, rlogin;

- puttygen.exe - rsa/dsa key generator;

- pageant.exe - authentication agent, stores keys in memory, when using it you do not need to manually enter a key passphrase;

- plink.exe - command line interface for putty;

- pscp.exe - secure file copying;

- psftp.exe is safe ftp client for copying, viewing, renaming files, etc.

It is not necessary to install putty, you can simply copy the files to the desired directory.

We launch putty.exe and create a profile with settings for our remote server. In PuTTY you can create profiles for different SSH servers, so you don't have to enter settings for a specific server the next time you want to connect to it. We are now in the Sessions category (see the tree on the left in Figure 9.11). Enter the host address 192.168.100.3 in the Host Name (or IP address) line, leaving the default port number (22) and Protocol (SSH). Under Saved Sessions, enter the profile name, for example, Session with CentOS, which will help you remember which server this profile belongs to.

Fig.9.11. Creating a profile with settings in PuTTY

Then we go to the Connection -> Data category and indicate in Auto-login username (see Fig. 9.12) the user name under which we will connect to the SSH server - root.

Fig.9.12. Set the username of the remote host

Now let's go back to the category Sessions, save the profile by clicking Save. Next time you launch PuTTY, simply select the appropriate profile from

Saved Sessions, click Load and Open.

Now we can connect to our SSH server by simply clicking Open. When this client connects for the first time, a warning appears (see Fig. 9.13) about

security threat similar to the message shown in Fig. 9.5. This is because PuTTY is not yet known. public key server host. PuTTY writes the host key for each server you join to the Windows registry. Every time you connect to a server, it checks that the host key provided by the server is the same key that was in the last connection. If this is not the case, you will receive a warning and have the option to terminate your connection before you type any private information (such as a password). Since we are connecting to the server via the SSH protocol, everything said in the previous above regarding checking the server’s public key to connect a Linux client applies to this connection.

In our case, there are no doubts about the authenticity of the server - click the button

Rice. 9.13. PuTTY warning when connecting to a remote host for the first time

Since we have saved the name under which we are connecting in the profile settings, we do not need to enter it again, we will only specify the user password (Fig. 9.14).

Rice. 9.14. Remote server control session

The remote connection has been established. In Fig. Figure 9.14 shows executing several commands on a remote Linux server and then rebooting the server remotely. After a reboot, the session becomes inactive. You should close it and connect to the server again when it boots.

The most common connection method was considered - with password identification. If anyone knows the name and password, they can connect too. So if you have a simple password and/or are the victim of a brute-force attack, there may be problems. Alternatively, you can use the method Authentication of the user himself using public key encryption. You can use PuTTYgen to generate a private/public key pair. Then the public key will need to be transferred to the server, and the private key will need to be attached to the PuTTY profile. These procedures are described in detail in the putty.hlp manual.

Thus, the developed laboratory setup allows you to study in detail remote control of a Linux server from a Winows client.

Work order:

1) Check if it is running xinetd super server. If it is not running, install super

server from the xinetd-2.3.14-10.el5.i386.rpm package. (/usr/sbin)

2) Check using the find command for availability and location ssh server shhd. If sshd is not installed, install it from packages

openssh-4.3p2-16.el5.i386.rpm, openssh-askpass-4.3p2-16.el5.i386.rpm; openssh-server-4.3p2-16.el5.i386.rpm. (usr/sbin)