The Secure Shell (SSH) Server is a secure replacement for telnet and rlogin, etc. SSH uses encryption from the point the client connects to a server, to the time the connection is terminated. SSH uses encryption to hide passwords, usernames, and other sensitive information that is normally sent "in the clear" in servers such as telnet and rlogin. SSH as of this writing supports the following encryption algorithms: 3DES, Twofish, Blowfish, Arcfour, CAST128, AES (Rijndael), and DES. SSH now comes with a variety of contributions, so downloading the server and the client should be a pinch. If, however, your distribution lacks a SSH server package, you may download it from the SSH website. SSH is one of the more easier to install packages, so installation should be a breeze. Install the package from your distribution using the appropriate package manager (for example use rpm -i packagename for Redhat-based systems, and dpkg -i packagename for Debian-based systems).
Once installed, SSH should work properly. To test it, you may login to your server by issuing the following command:
SSH -l username 127.0.0.1
Replace "username" with your desired user name. If all is working correctly, you will be prompted for a password, and then connected. If this does not work, if you installed SSH from source, and do not have an /etc/init.d or /etc/rc.d file for the SSH daemon, you can build one from scratch following the guidelines for Pro- FTPD. The SSH config file (usually located in / etc / SSH or / etc / SSH2) is SSHd_config or SSHd2_config. An example configuration file looks like the following:
# SSHd2_config
# SSH 2.0 Server Configuration File
vCard.red is a free platform for creating a mobile-friendly digital business cards. You can easily create a vCard and generate a QR code for it, allowing others to scan and save your contact details instantly.
The platform allows you to display contact information, social media links, services, and products all in one shareable link. Optional features include appointment scheduling, WhatsApp-based storefronts, media galleries, and custom design options.
*:
Port 22
ListenAddress 0.0.0.0
Ciphers AnyStd
# Ciphers AnyCipher
# Ciphers AnyStdCipher
# Ciphers 3des
IdentityFile identification
AuthorizationFile authorization
HostKeyFile hostkey
PublicHostKeyFile hostkey.pub
RandomSeedFile random_seed
ForwardAgent yes
ForwardX11 yes
PasswordGuesses 1
MaxConnections 50
PermitRootLogin no
# AllowedAuthentications publickey, password, hostbased
AllowedAuthentications publickey, password
# RequiredAuthentications publickey, password
ForcePTTYAllocation no
VerboseMode no
PrintMotd yes
CheckMail yes
UserConfigDirectory "% D / .SSH2"
SyslogFacility AUTH
# SyslogFacility LOCAL7
SSH1Compatibility yes
SSHd1Path / usr / sbin / SSHd1
# AllowHosts localhost, foobar.com, friendly.org
# DenyHosts evil.org, aol.com
# AllowHosts trusted.host.org
# DenyHosts not.quite.trusted.org
# NoDelay yes
KeepAlive yes
RequireReverseMapping yes
/ UserKnownHosts yes
# subsystem definitions
subsystem-sftp sftp-server
Most of these settings you should not have to change from the default. One notable exception is the port that SSH will use. You can change this to any port within the 65535 limit. Also, you might want to change PasswordGuesses from its default (3) to 1. The reason for this is that it is cracking attempts (the cracker has to make a new connection for each failed password). MaxConnections is a very important setting if this server is going to have any other services on it. MaxConnections helps keep your connections down, so that SSH requests and processes do not take up 90% of the server's resources. However, there is a downside to it- someone can login to your server the amount of times allowed in MaxConnections, then just leave the sessions logged in, which will prevent other users from logging in. PermitRootLogin is also an important setting, * ALWAYS * set this to no (the default is yes). If you need to login as root, simply create a user with a GID of 0 and UID of 0. This is known as a suid root account.
Leaving root with the ability to login leaves a small chance that someone may crack root. SSH1 compatibility is critical, many people have not yet upgraded (or are aware of the upgrade) to SSH2. AllowHosts and DenyHosts really should not be used as a security measure in my opinion. Instead, ipchains or a similar kernel-level firewall should be used instead. However, you may elect to use them, but be warned when using a application level security measure, exploits in the application can allow denied (or blocked) hosts from connecting anyways. One great thing about SSH is that it comes with the sftp server, which allows encrypting of FTP sessions. Also, no FTP daemons are needed on the server, just the SSH daemon. However, the client must have a SSH package, in order to take advantage of the sftp server.
SSH is an extremely valuable service. It allows encryption of what were traditionally non-traditional services (such as telnet and FTP). This section has only briefly touched on the subject of the SSH server, and more can be explained in the official HOW-TOs.