Remote access from Windows on FreeBSD for beginners

Once it was necessary to establish remote ssh access on a working machine under Win XP to a remote computer running FreeBSD.
There are a lot of separate manuals for work in Fryushka, the generation of keys in OpenSSL, etc., but there was no suitable one for this situation, so I decided to put the separate instructions together.
Next - a description of the entire process from the preparation of the platform to performance checks.

Part 1 preparatory. Creating a user and giving him the necessary rights.

First, all work is done on a remote computer under Frusha.
I did not have my own user on a remote computer, so I must first create it.

% sudo adduser
further questions will be answered which can be answered something like this:
Username: shurchik
Full name: (you can not answer it, this is info for the user profile),
UID (Leave empty for default): (allow the system to choose the free identifier itself, skip it),
Login group [shurchik]: wheel (here we enter the main group of the user, by default it is equal to the user name, but to create a system administrator it is better to place it in the wheel group),
Login group is wheel. Invite shurchik into other groups?: Login group is wheel. Invite shurchik into other groups?: (You can also skip the request because you do not need to include this user in other groups. Then you can also add him to the groups),
Login class [default]: (I also skip it, but theoretically you can set the locale - the layout and language of the user, saying russian.),
Shell (sh csh tcsh bash nologin) [sh]: bash (This is a command shell request, you can leave the shell, which is the default, but more convenient bash or zsh),
Home directory [/home/shurchik/]: (If this house directory suits, then I press Enter, if not - I am writing another one, for example, / home / test /),
Home directory permissions (Leave empty for default): (you can force permissions, but I leave everything as it is by default),
Use password-based authentication? [yes]: Use password-based authentication? [yes]: (I also leave it by default, since I will not be able to log in to the system otherwise),
Use an empty password? (yes/no) [no]: Use an empty password? (yes/no) [no]: (I also leave it by default, since logging in without a password does not make sense),
Enter password: (enter the password for the user, but take into account that the password is not indicated when entering, even asterisks),
Enter password again: (everything is clear here too, repeat the password),
Lock out the account after creation [no]:

After all, a user profile will appear in the terminal asking whether you agree with it or not:
Username: shurchik
Password:******
Full name:
UID: 1010
Class:
Groups: wheel
Home directory: /home/shurchik/
Home mode:
Shell: /bin/bash
Locked: no
OK? (yes/no):
I type yes

Adduser: INFO: Successfully added (shurchik) to user database.
On a new request to create another user answer no:
Add another user? (yes/no): no
Goodbye!

In order for the newly created user to have the right to sudo, either the entire wheel group must be registered in the sudoers file, or only the user himself.
This is done like this:
In the / PCBSD / local / etc / sudoers file, uncomment the line
% wheel ALL=(ALL) NOPASSWD: ALL
(This means that access to sudo (superuser do) is now open to all members of the wheel group without a password),
! Changes to the sudoers file take effect immediately after saving it. It is necessary to put the rights on it 440.
')
Now let's log in with a new user:
% su shurchik
password:

You can find out which commands are available to this user.
% sudo –l
You can display a list of all groups and their members:
% less /etc/group

Part 2, the main. Setting up the sshd daemon
Generation of private and public key.

I will work with the program Openssh.

1. Setting up the ssh program
Open port 22 on the gateway.

First, check to see if the daemon is running on the server. (The ssh daemon name is sshd)
Ways:
% ps auwx | grep sshd

Or
% sockstat -4l | grep :22
If the output:
sshd …tcp4 :22
then port 22 is listening (by default. ssh goes through this port)
If the port is not listening, then the ssh daemon is not running.
Or you can just give the command:
% sudo /etc/rc.d/sshd start
If you swear, then you need to change the configuration file.

Then go to the configuration file rc.conf.local (located in / etc). If it is not already there, then create it and write there sshd_enable = ”YES”. (You can instead write the same line simply in rc.conf.)
This is necessary in order to be able to start the ssh daemon with the start command. Changes take effect immediately.

Now again, give the command to start ssh:
% sudo /etc/rc.d/sshd start should start.
Now again to check its operation, whether port 22 is listening:
% sockstat -4l | grep :22
Must withdraw:
sshd …tcp4 :22
In addition, you can give a command, for example, to connect with a local host:
% ssh localhost
If it is ..connection refused, then ssh is not running. And you need to look at the config again.

2. Key generation
Give the command to generate keys:
% ssh-keygen
The default encryption method is rsa. To generate, for example, using the dsa encryption method, you need to say % ssh-keygen –t dsa
The generation of the key pair private key / public key will begin.
Will say:
Enter passphrase: (better long and complicated)
Keys are generated in the ~ / .ssh directory (/home/shurchik/.ssh).

Now check what is lying there:
% ls –l ~/.ssh
id_rsa is a private key (it can be called, for example, just rsa),
id_rsa.pub is the public key (may be called, for example, rsa.pub).

Next, you need to put the public key on the server in an understandable form. To do this, do the following:
Add the contents of the file id_rsa.pub to the contents of the file authorized_keys.
This is done by the command:
% cat id_rsa.pub >> authorized_keys
It adds the contents of id_rsa.pub to the end of the authorized_keys file. And if not, it creates. cat is short for concatenate.

If there is no authorized_keys file at all, you can create it by copying id_rsa.pub:
% cp id_rsa.pub authorized_keys

Check again the contents of the .ssh folder:
% ls –l ~/.ssh
(Should be something like the following)
id_rsa
id_rsa.pub
authorized_keys

The authorized_keys file is left on the remote computer, and id_rsa and id_rsa.pub are saved somewhere else and deleted from the ~ / .ssh folder. It is important not to lose the public key, because otherwise you have to re-generate everything.
And finally, we will find out the name of the host on the remote machine (it is needed when connecting via ssh), then we will go to the working computer and we will torture it already.
% hostname
testhost

Now we find out the ip-address of the company:
% host testhost

! Note: FreeBsd7 uses des-encryption, which is compatible with Putty. But FreeBsd9 already uses another encryption method that this program does not recognize. Therefore, in this case, you will have to generate the keys in the putty-gen program itself, and then convert them into a form that Unix understands.

3. Convert the private key into a format that Putty can understand.
(On Windows)
Download the Putty program, install it. Bring a freshly generated key to a Windows machine. Putty understands the keys of only one format (your =) .ppk

Run the Putty-gen program (installed simultaneously with the main one or separately).
but. File-load private key (since Putty is installed on my working machine, which requires a private key, we convert it.)
b. Save private key (for example, id_rsa.ppk)

Part 3, solemn. Configure Putty and establish an encrypted remote connection.

1. Start Putty.
The settings are as follows:

Session: hostname testhost (or ip)

Logging: any logs, if desired + mark always overwrite it (or append to the end of it), so as not to ask each time whether to overwrite the logs;

Window: translation utf-8

Connection: auto-login username shurchik

SSH: browse ... specify the path to the id_rsa.ppk file (it can lie anywhere, putty is absolutely indifferent. Where to get it.)

And now we will save everything:
Session: Saved sessions: new (set the name of this session), click Save, the session new will appear in the list.
To call it later without setting up everything again, after running Putty, simply select new from the list and click Load.
Now press Open and the terminal opens with a request to enter a pass phrase.
If something goes wrong with the keys, then the program, cursing, will ask for the login and password (the shurchik and the password for it).

2. At the end, it is possible to prohibit access via an encrypted connection to a remote computer using a login password (leaving only possible connections with passphrase.)
On the remote computer, go to the ssh configuration file:
/ etc / ssh / sshd_config.
There you have to add (or uncomment) the line:
UsePAM no.

Then you need to restart ssh:
% sudo /etc/rc.d/sshd stop
% sudo /etc/rc.d/sshd start

Everything!