Encrypted connection using SSH and OpenSSH

Home » » Networks » Encrypted connection using SSH and OpenSSH
Networks No Comments

* Steps for installation and configuration Installing the OpenSSH package for MS-Windows

* Start the service

* Some important rules

* Annexes

* Installing and configuring OpenSSH on GNU / Linux

Sometimes you need to remotely administer a server and we must establish a secure communication between the host and the system from which we establish the connection. Telnet sessions do not offer much security as the data travels through the network without any encryption and potentially supceptibles be intercepted by an attacker.

Currently computer networks are the most used digital media in all areas of society to information transfer. Typically these means are in public networks, which are exposed to interventions of one form or another.

When a connection to a remote server using eg telnet or ftp, the login (username) and password (password) are transmitted over the network in clear, which is a major risk if it comes into existence on the network a program that captures information based on promiscuous mode ethernet networks (commonly called sniffer), caused obtain both the login and password and can then break into the server with this information.

This type of problem has led to diseode tools to avoid these situations being the case of Secure Shell (SSH), developed by Tatu Ylonen at Helsinki University of Technology in Finland and OpenSSH, born of a project-oriented operating system with safety philosophy of mind such as OpenBSD.

Secure Shell (SSH) is a software-based solution that keeps data secure network. Many users of telnet, rlogin, ftp, and other such programs might not realize that their password is transmitted unencrypted over the network. SSH encrypts all traffic (including passwords) to effectively eliminate a the “hear”, the connection hijacking, and other network-level attacks.

In addition, SSH provides ample opportunities for creating secure tunnels, apart from a variety of authentication methods. It seems crazy, but Secure Shell is a shell. There is an interpreter, command history, or other.

SSH provides strong authentication and secure communications over an insecure channel and was created as a replacement for telnet, ftp, rlogin, rsh, and rcp, which provide flexibility in network management, but nevertheless presents great risks security of a system. Additionally, ssh provides security for X Windows utility connections and secure delivery of arbitrary TCP connections.

Secure Shell supports multiple encryption algorithms among which are included:

Blowfish

3DES

IDEA

RSAThe most significant advantage of ssh is not much change routines. In all aspects, ssh log is as simple as (and similar to) start a telnet session. Both the key exchange, authentication and encryption subsequent sessions are transparent to users.

OpenSSH is a FREE version of the toolkit secure communication protocol SSH / secsh network, a security solution that is gaining the trust of a growing number of Internet users. Many users of telnet, rlogin, ftp, and other such programs might not realize that their password is transmitted unencrypted over the network. OpenSSH encrypts all traffic (including passwords) to effectively eliminate a the “hear” the connection hijacking, and other network-level attacks. Additionally, OpenSSH provides possibilities for creating secure tunnels, apart from a variety of authentication methods.

SSH is a protocol that allows establishing secure connections over networks that are not, and can serve as a secure tunnel for other protocols that are not. We can then carry out maintenance of systems and UNIX-style remote connections securely.

SSH2, the second version of SSH, solve some of the shortcomings of its predecessor SSH1, thus providing a high level of data encryption and authentication method quite reliable. It is also a reliable alternative to unsafe: telnet or rlogin, rsh, rcp, rdist

But it makes things very useful for the security of a system in unreliable environments. Some “features”:

Cryptographic protocol in a client / server model

Authentication of the most varied forms:

password

by host

for key system

Integration with authentication systems as:

Kerberos

SecurID

PGP

TIS Gauntlet

PAM

Seguriza application protocols (almost) transparent

Implementation on most operating systems and platforms

Secure Shell prevents also a series of attacks like those from Sniffers:

IP Spoofing

MACpoofing

DNS Spoofing

Telnet Hickjacking

ARP Spoofing

Routing IP Spoofing

Spoofing ICMP

We can also serve to create secure tunnels channels or for other applications such as mail, VNC, ftp, etc..

Steps for installation and configuration

Installing the OpenSSH package for MS-Windows

Download the package *. ZIP (OpenSSH for Windows v3.4-3).

Creating a pair of keys / key

To create a DSA key pair, enter the base directory OpenSSH using the command line and run:

ssh-keygen-d-f c: \ ssh \ ssh_host_dsa_key-N “”

To create an RSA key pair, run the command:

ssh-keygen-f c: \ ssh \ ssh_host_key-N “”

In these examples use the C: \ ssh as the base directory, so if you use a different base directory that will replace the data in the example. Will be generated by key pairs defect of 1,024 bits, in principle sufficiently secure.

Environment Variables

My Computer -> Properties -> Advanced -> Environment Variables ->

Add the path the value of the path where OpenSSH for example:

C: \ Program Files \ Exceed.nt; C: \ Program Files \ Common Files \ Autodesk Shared \, C: \ OpenSSH

My Computer> Properties> Advanced> Environment Variables>

Create a new system variable:

Variable: HOME

Value: C: \ OpenSSH (or path where you are OpenSSH)

Creating passwd and group files

Inside the folder / bin are mkpasswd and mkgroup programs to create users / groups that serve for authentication. Once the authentication Cygenwin, this transfers the request to Windows 2000 authentication for password checking in the SAM (Security Accounts Manager) local and then the domain database if it exists. Whereupon, users created with passwd users must also be created in the system.

mkpasswd-l-u username >> .. \ etc \ passwd

mkgroup-l >> .. \ etc \ group

replace username with the username that must exist in Windows 2000 and by-d-l if we are in a domain.

For users of the system where we configure OpenSSH:

C: \ OpenSSH \ bin> mkpasswd-l

SYSTEM: *: 18:544:, S-1-5-18 ::

Administrators: *: 544:544:, S-1-x-32-544 ::

Administrador:unused_by_nt/2000/xp:500:513:U-INFOGRAFIA3\Administrador,S-1-5-21-682003330-10600084298-49167539-500:/home/Administrador:/bin/switch

Example of creating user / group:

C: \ OpenSSH \ bin> mkpasswd-d-u INFOGRAFIA3 >> .. \ etc \ passwd

C: \ OpenSSH \ bin> mkgroup-d >> .. \ etc \ group

Restricting users

So that only certain users can connect to the server via SSH, add the following line to / etc / sshd_config:

AllowUsers …

It is also possible to accept user groups. It is made with AllowGroups.

Start the service

C: \ net start opensshd

OpenSSH server connection

To connect to the OpenSSH server from a Windows client can use PuTTY, a telnet client and SSH “free” for interoperating with OpenSSH from Windows: http://gnuwin.epfl.ch/apps/putty/es/

To connect from a MSDOS shell mode:

ssh user @ server

Security

You need to assign permissions to folders that only few users who want to access them.

Some important rules

Whenever possible, allow remote access only to administrators.

Only the LocalSystem account and the local group “Administrators” should have access to the \ ssh \ var and \ etc.

If a message is displayed warning SSH client to tell the server host key has changed and OpenSSH is not the first time that connects to that server, find out what the cause.

Use SSH1 only when there older clients using that version of SSH.

Annexes

I) Some parameters ssh_config

OpenSSH configuration files

OpenSSH has two different sets of configuration files, one for client programs (ssh, scp, and sftp) and one for server services (sshd), located in two different sites.

SSH configuration information for the entire system is stored in the / etc / ssh:

primes – Contains Diffie-Hellman groups that serve to exchange Diffie-Hellman key. Fundamentally, this key exchange creates a shared secret value that neither party can determine one and is used to provide host authentication. This file is essential for the construction of a secure transport layer.

ssh_config – the configuration file for all the SSH client system is used to direct the SSH client. If a user has its own configuration file available in your home directory (~ / .ssh / config), its values will override the values stored in / etc / ssh / ssh_config.

sshd_config – The configuration file for sshd.

ssh_host_dsa_key – DSA private key used by sshd.

ssh_host_dsa_key.pub – The DSA public key used by sshd.

ssh_host_key – The RSA private key used by sshd for version 1 of the SSH protocol.

ssh_host_key.pub – RSA public key used by sshd for version 1 of the SSH protocol.

ssh_host_rsa_key – The RSA private key used by sshd for version 2 of the SSH protocol.

ssh_host_rsa_key.pub – RSA public key used by sshd for version 2 of the SSH protocol.

The SSH configuration information specific to the user is stored in the user’s home directory in the subdirectory. Ssh:

authorized_keys2 – the file containing a list of public keys “authorized”. If a user who connects can check who knows the private key corresponding to any public key, then it will be authenticated. Note that this is only an optional authentication method.

id_dsa – Contains the DSA authentication identity of the user.

id_dsa.pub – The DSA public key of the user.

id_rsa – The RSA public key used by sshd for version 2 of the SSH protocol.

identity – The RSA private key used by sshd for version 1 of the SSH protocol.

known_hosts2 – stores DSA host keys of the servers to which users kicking off a session via SSH when the user decides to save them. If you modify a server host keys in legitimately, perhaps when reinstalling Red Hat Linux users will receive a warning that the host key known_hosts2 stored in the file that corresponds with this host does not match. Then the user must delete the host key in known_hosts to store the new host key for that system. Known_hosts2 The file is very important to ensure that the client is connecting to the correct server. If you changed a host key, and you are not perfectly sure why it has been changed, then you should contact the administrator of the host system to ensure that the host has not been exposed to danger.

(Some parameters ssh_config: out of http://www.tau.org.ar/base/computacion/gsal-19991128-htm/ssh.htm)

Port 22

# Runs on port 22,

0.0.0.0 ListenAddress

# Listen on all interfaces

HostKey / etc / ssh / ssh_host_key

# Where the host key

RandomSeed / etc / ssh / ssh_random_seed

# Where the random seed

ServerKeyBits 768

# For how long the server key

LoginGraceTime 300

# How long you have to enter credentials

KeyRegenerationInterval 3600

# How often regenerate the server key

PermitRootLogin no

# Allow root to login

Yes IgnoreRhosts

# Ignore. Rhosts user

Yes StrictModes

# To ensure that users do not nonsense

QuietMode not

# If yes it does not log anything. We want to log logins / etc.

X11Forwarding no

# X11 forwarding why not have a server

FascistLogging not

# Maybe not we want to do too much log

Yes PrintMotd

# Print the message of the day Always good

KeepAlive yes

# Make sure that the sessions are disconnected correctly

DAEMON SyslogFacility

# Who is doing the logging

RhostsAuthentication not

# Authentication using rhosts or / etc / hosts.equiv is not

# On my mind. Default is yes, so that is disabled.

Yes RSAAuthentication

# Allow pure RSA authentication It’s pretty safe

PasswordAuthentication yes

# Allow users to use their normal login / passwd

# Why not.

PermitEmptyPasswords not

# Permit accounts with empty passwords no

Other directives sshd_conf useful include:

AllowGroups – explicitly allow groups (/ etc / group) to login using ssh

DenyGroups – explicitly disable groups to login (/ etc / groups)

DenyUsers – explicitly lock users to login

AllowHosts – allow certain hosts, the rest will be denied

DenyHosts – blocks certain hosts, the rest will be allowed

IdleTimeout time – time in minutes / hours / days / etc, forces a logout process making a SIGHUP

II) On public keys

ssh_host_dsa_key – DSA private key used by sshd.

ssh_host_dsa_key.pub – The DSA public key used by sshd.

ssh_host_key – The RSA private key used by sshd for version 1 of the SSH protocol.

ssh_host_key.pub – RSA public key used by sshd for version 1 of the SSH protocol.

ssh_host_rsa_key – The RSA private key used by sshd for version 2 of the SSH protocol.

ssh_host_rsa_key.pub – RSA public key used by sshd for version 2 of the SSH protocol.

Installing and configuring OpenSSH on GNU / Linux

Sometimes you need to remotely administer a server and we must establish a secure communication between the host and the system from which we establish the connection. Telnet sessions do not offer much security as the data travels through the network without any encryption and potentially supceptibles be intercepted by an attacker, so as best method available to us we OpenSSH.

With power OpenSSHvamos to execute a secure shell server podernos while connecting to it by a customer also secure so that the communication be reinforced at both ends.

Well, to properly use OpenSSH and is fully encrypted communication, we must first install OpenSSL libraries providing Secure Socket Layer or Secure socket layer (SSL). We can install OpenSSL from the distribution CDs or compile your source code (denote the command line with the # symbol):

# Tar-zxvf openssl-nmerodeversin.tar.gz

# Cd openssl /

#. / Configure

# Make

# Make install

We already have OpenSSL installed, now it’s the turn of OpenSSH. We can also install the prebuilt packages that come with your distribution or compile the source:

# Tar-zxvf openssh-nmerodeversin.tar.gz

# Cd openssh /

#. / Configure-with-ssl-dir = / usr / local / ssl

(Note: ssl location may vary depending on distribution or if you compiled or installed using RPM packages)

# Make

# Make install

Now start the SSH server:

# / Etc / init.d / ssh start

Starting SSH daemon done

And we try to connect to port 22 of our system:

# Ssh localhost

root @ localhost’s password:

Last login: Tue November 23 15:29:31 2004 from localhost

Have a lot of fun …

linux: ~ #

As we can see in the example we have been able to connect as the root user, this is perfectly safe because communication is fully encrypted, but if we change this we should edit / etc / ssh / sshd_config and add:

PermitRootLogin no

You may already exist in the file a line saying PermitRootLogin yes, if it exists and is annotated, add ours and if not change the yes to no.

This type of authentication as we see is based on the exchange of user-password pair, but we can increase security even more if you add a pair of public and private keys, to what end, Very simple, this mechanism provides security ssh client you are connecting to the server is authentic and not an intruder. If this happens a message appears on the screen warning us that you can not verify the authenticity of the server and we are asked if we agree to continue the session in spite of the circumstances.

# Ssh localhost

The authenticity of host ‘localhost (:: 1)’ can not be established.

RSA key fingerprint is 74:4 e: 7c: 2b: ee: 18: ca: 5a: e4: 55:1 c: bd: dc: 72: dd: 7e.

Are you sure you want to continue connecting (yes / no) / I>

To generate keys act as follows as root:

# Ssh-keygen-t rsa

Generating public / private rsa key pair.

Enter file in Which to save the key (/ root / .ssh / id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in / root / .ssh / id_rsa.

Your public key has been saved in / root / .ssh / id_rsa.pub.

The key fingerprint is:

fa: 3a: 7b: 65:73:1 b: 20: ec: 4e: 3e: 23:80:17:5 c: 52:60 root @ linux

The possible values are rsa1-t for protocol version 1 and RSA and DSA for 2. Version 2 will choose to be more secure.

When we have the keys only have to provide the public key to the client and that you add to your known_hosts file located in the directory. Ssh your / home.

# Ssh localhost

user @ localhost’s password:

Last login: Thu November 25 15:01:06 2004 from localhost

Have a lot of fun …

One last note, when trying to login can indicate the user you want to access the system:

# Ssh-l root localhost

root @ localhost’s password:

Last login: Thu November 25 15:09:10 2004 from localhost

Have a lot of fun …

And of course, getting out of an ssh session and just like we would in the end of our own system, you would type:

# Exit

 

 

Bibliography

– (11/11/2003) Author: Alfonso.

Xombra