ssh protokol se uporablja za secure remote login oz. secure shell.
Kako se uporablja zgeneriras kljucke jih preneses prek usb kljucka na drug rac in se povezes.
Lahko takoj direktno, sam ti lahko kdo prisluskuje in desifrira tvoj kljuc.
Potem vsa komunikacija poteka sifrirano, kako mocno je odvisno od kljuca, ki ga hoces zgenerirat.
Najboljs je to, ko X11 forwardiras iz remote machine k sebi.
na dolgo:
One of the most popular file transfer and remote login Linux applications is OpenSSH which provides a number of ways to creating encrypted remote terminal and file transfer connections between clients and servers. The OpenSSH Secure Copy (SCP) and secure FTP (SFTP) programs are secure replacements for FTP, while Secure Shell (SSH) is often used as a stealthy alternative to Telnet. OpenSSH isn't limited to Linux, SSH and SCP clients are available for most operating systems including Windows.
An Quick Introduction To SSH Encryption
Data encryption is accomplished by using special mathematical equations to scramble the bits in a data stream in order to make it unreadable to anyone who does not have access to the corresponding decryption equation. The process is usually made even harder through the use of an encryption key that is used to modify the way the equations do the scrambling. Only persons with access to this key and the corresponding programs are able to recover the original data. Data encryption helps to prevent unauthorized persons from having access to the data.
SSH uses the concept of randomly generated private and public keys to do its encryption. The keys are usually created only once, but you have the option of regenerating them should they become compromised.
A successful exchange of encrypted data requires the receiver to have a copy of the sender's public key beforehand. Here's how it's done with SSH.
When you log into an SSH server, you are prompted as to whether you want to accept the download of the server's public key before you can proceed. The SSH client's key is uploaded to the server at the same time. This creates a situation in which the computers at each end of the SSH connection have each other's keys and is able to decrypt the data sent to it from the other end of the encrypted link or "tunnel".
All the public keys that an SSH client's Linux user has encountered are stored in a file named ~/.ssh/known_hosts along with the IP address that provided it. If the match changes, then SSH knows that something is wrong. In many cases this is due to upgrades in the SSH application which may regenerate the keys, or a complete reinstallation of the operating system. You should also be aware that the keys could change due to someone trying some soft of cyber attack. Always investigate changes to be safe. Your server's own public and private SSH keys are stored in the /etc/ssh/ directory.
Note: The .ssh directory is a hidden directory, as are all files and directories whose names begin with a period ".". The "ls -a" command will list all normal and hidden files in a directory. The "~/" notation is a universally accepted way of referring to your home directory and is recognized by all Linux commands.
There are other key files that Linux uses to provide the capability of password-less logins and file copying to remote servers using SSH and SCP. In this case, the SSH connection is established then the client automatically sends its public key which the server uses to match against a predefined list in the user's directory. If there is a match then the login is authorized. The files for this purpose are also stored in your ~/.ssh directory and need to be specially generated. The files named id_dsa, id_dsa.pub are your private and public keys respectively, and the file named authorized_keys stores all the authorized public keys from remote hosts that may log into your account without the need for passwords. This process will be discussed in more detail later.
Starting OpenSSH
OpenSSH is installed by default during Linux installations, and as they are part of the same application, both SSH and SCP share the same configuration file and are governed by the same /etc/init.d/sshd startup script.
You can get SSH configured to start at boot by using the chkconfig command.
[root@bigboy tmp]# chkconfig sshd on
You can also start/stop/restart SSH after booting by running the sshd initialization script.
[root@bigboy tmp]# service sshd start
[root@bigboy tmp]# service sshd stop
[root@bigboy tmp]# service sshd restart
Remember to restart the SSH process every time you make a change to the configuration files for the changes to take effect on the running process.
Testing To See If SSH Is Running
You can test whether the SSH process is running with the following command. You should get a response of plain old process ID numbers:
[root@bigboy tmp]# pgrep sshd
The /etc/ssh/sshd_config File
The SSH configuration file is called /etc/ssh/sshd_config. By default SSH listens on all your NICs and uses TCP port 22. See the configuration snippet below which we'll also refer to later:
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
SSH Versions 1 and 2
The original encryption scheme of SSH was adequate for its time but was eventually found to have a number of limitations that led to the development of version 2. You should always force your systems to operate exclusively with version 2 by setting the protocol statement in the /etc/ssh/sshd_config file to "2". Remember to restart SSH to make this take effect.
#
# File: /etc/ssh/sshd_config
#
Protocol 2
How To Change The TCP Port On Which SSH Listens
If you are afraid of people trying to hack in on a well known TCP port, then you can change port 22 to something else that won't interfere with other applications on your system, such as port 435. This is only a rudimentary precaution as good network scanning programs can detect SSH running on alternative ports.
Here is how it can be done:
1. First make sure your system isn't listening on port 435, using the "netstat" command and using "grep" to filter out everything that doesn't have the string "435".
[root@bigboy root]# netstat -an | grep 435
[root@bigboy root]#
2.No response, OK. Change the Port line in /etc/ssh/sshd_config to mention 435 and remove the "#" at the beginning of the line. If port 435 is being used, pick another port and try again.
Port 435
3.Restart SSH
[root@bigboy tmp]# service sshd restart
4. Check to ensure SSH is running on the new port
[root@bigboy root]# netstat -an | grep 435
tcp 192.168.1.100:435 0.0.0.0:* LISTEN
[root@bigboy root]#
Next we'll discover how to actually login to systems using SSH.
Using SSH To Login To A Remote Machine
Using SSH is similar to Telnet. To login from another Linux box use the "ssh" command with a "-l" to specify the username you wish to login as. If you leave out the "-l", your username will not change. Here are some examples for a server named "smallfry" in your /etc/hosts file.
User "root" Logs In To smallfry As User "root"
[root@bigboy tmp]# ssh smallfry
User "root" Logs In To smallfry As User "peter"
The examples below assume that you have created a user called "peter" on smallfry.
Using default port 22
[root@bigboy tmp]# ssh -l peter smallfry
Using port 435
[root@bigboy tmp]# ssh -l peter -p 435 smallfry
What To Expect With Your First Login
The first time you log in, you will get a warning message saying that the remote host doesn't know about your machine and will prompt you to store a copy of the remote host's SSH identification keys on your local machine. It will look something like this:
[root@bigboy tmp]# ssh smallfry
The authenticity of host 'smallfry (smallfry)' can't be established.
RSA key fingerprint is 5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'smallfry' (RSA) to the list of known hosts. root@smallfry's password:
Last login: Thu Nov 14 10:18:45 2002 from 192.168.1.98
No mail.
[root@smallfry tmp]#
The key is stored in your ~/.ssh/known_hosts file and you should never be prompted for this again.
SSH Failures Due To Linux Reinstallations
If Linux or SSH is reinstalled on the remote server then the keys are regenerated and your SSH client will detect that this new key doesn't match the saved value in the known_hosts file. The SSH client will fail giving an error like this, erring on the side of caution to alert you to the possibility of  a form of hacking attack.
[root@bigboy tmp]# ssh 192.168.1.102
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@Ă‚ Ă‚ Ă‚ Ă‚ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:2
RSA host key for 192.168.1.102 has changed and you have requested strict checking.
Host key verification failed.
[root@bigboy tmp]#
If you are confident that this is due to a reinstallation, then you need to edit your ~/.ssh/known_hosts text file and remove the entry for the offending remote server. Once this is done, try connecting via SSH again, you'll be prompted to ad the new key to your ~/.ssh/known_hosts file and the login session should proceed as normal after that.
Deactivating Telnet once SSH is installed
You should always consider the use of SSH more favorably than that of Telnet because of the inherent data encryption features of SSH and the current widespread availability of SSH clients for both Linux and Windows.
By default, the Telnet server isn't installed with Fedora Linux. If you do decide to deactivate an active Telnet server on Fedora, then use the chkconfig command as detailed in Chapter 16.
[root@bigboy tmp]# chkconfig telnet off
Using SSH To Execute Remote Commands On Demand
A nice feature of SSH is that it is capable of logging in and executing single commands on a remote system. You just have to place the remote command, enclosed in quotes, at the end of the ssh command of the local server. In the example below, a user on server "smallfry" who needs to know the version of the kernel running on server "bigboy" (192.168.1.100) remotely runs the "uname -a". The command returns the version of 2.6.8-1.521 and the server's name, "bigboy".
[root@smallfry tmp]# ssh 192.168.1.100 "uname -a"
root@192.168.1.100's password:
Linux bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux
[root@smallfry tmp]#
This feature can be very useful. You can combine it with password-less login, explained later in this chapter, to get the status of a remote server whenever you need it. More comprehensive monitoring may best be left to purpose built programs like MRTG covered in Chapter 22.
Using SCP as a more secure replacement for FTP
From a networking perspective, FTP isn't very secure as usernames, passwords and data are sent across the network unencrypted. More secure forms such as SFTP (Secure FTP) and SCP (Secure Copy) are available as a part of the OpenSSH package that is normally installed by default on RedHat and Fedora Core. Remember, unlike FTP, SCP doesn't support anonymous downloads like FTP.
The Linux scp command for copying files has a format similar to that of the regular Linux cp command. The first argument is the source file and the second is the destination file. When copying to/from a remote server, SCP logs in to the server to transfer the data and this therefore requires you to supply a remote server name, username and password to successfully execute the command. The remote filename is therefore preceded by a prefix of the remote username and server name separated by an "@" symbol. The remote filename or directory then follows separated by a colon. The format therefore looks like this:
username@servername:filename
username@servername:directoryname
For example file /etc/syslog.conf on a server with IP address 192.168.1.100 that needs to be retrieved as user "peter" would have the format peter@192.168.1.000:/etc/syslog.conf, the entire /etc directory would be peter@192.168.1.000:/etc/.
Note: There is an easy to use Windows SCP client called WinSCP which can be downloaded at
http://winscp.vse.cz/eng/
Copying Files To The Local Linux Box
With an understanding of the representation of remote filenames by scp it becomes fairly easy to start copying files. Here are some examples:
Copy file /tmp/software.rpm on the remote machine to the local directory /usr/rpm
[root@bigboy tmp]# scp root@smallfry:/tmp/software.rpm /usr/rpm
root@smallfry's password:
software.rpm 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#
Copy file /tmp/software.rpm on the remote machine to the local directory /usr/rpm using TCP port 435
[root@bigboy tmp]# scp -P 435 root@smallfry:/tmp/software.rpm /usr/rpm
root@smallfry's password:
software.rpm 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#
Copying Files To The Remote Linux Box
Copying files to the local Linux server now becomes intuitive. Here are some examples:
Copy file /etc/hosts on the local machine to directory /tmp on the remote server.
[root@bigboy tmp]# scp /etc/hosts root@192.168.1.103:/tmp
root@192.168.1.103's password:
hosts 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#
Copy file /etc/hosts on the local machine to directory /tmp on the remote server using TCP port 435
[root@bigboy tmp]# scp -P 435 /etc/hosts root@192.168.1.103:/tmp
hosts 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#
Using SFTP as a more secure replacement for FTP
OpenSSH also has the SFTP program which runs over an encrypted SSH session but whose commands mimic those of FTP. SFTP can be more convenient to use than SCP when you are uncertain of the locations of the files you want to copy as it has the directory browsing abilities of FTP. Unlike FTP, SFTP doesn't support anonymous logins.
Here is a sample login sequence that logs in, gets help on the available commands and downloads a file to the local server.
[root@bigboy tmp]# sftp 192.168.1.200
Connecting to 192.168.1.200...
root@192.168.1.200's password:
sftp> help
Available commands:
cd path                       Change remote directory to 'path'
lcd path                      Change local directory to 'path'
chgrp grp path                Change group of file 'path' to 'grp'
chmod mode path               Change permissions of file 'path' to 'mode'
...
...
sftp> ls
..
..
anaconda-ks.cfg
install.log
install.log.syslog
..
..
sftp> get install.log
install.log                        100%   17KB  39.4KB/s  00:00
sftp> exit
[root@bigboy tmp]#
Ă‚
Using SSH and SCP without a password
From time to time you may want to write scripts that will allow you to copy files to a server, or login, without being prompted for passwords. This can make them simpler to write and also prevents you from having to embed the password in your code.
SCP has a feature which allows you to do this. You no longer have to worry about prying eyes seeing your passwords nor worrying about your script breaking when someone changes the password. You can configure SSH to do this by generating and installing encryption keys for the data transfer that are tied to the IP addresses of the two servers. The servers then use these pre-installed keys to authenticate one another for each file transfer. As you may expect, this feature doesn't work well with computers with IP addresses that periodically change such as those obtained via DHCP.
There are some security risks though. The feature is automatically applied to SSH as well. There is the possibility of someone using your account to login to the target server by entering the username alone. It is therefore best to implement this using unprivileged accounts on both the source and target servers.
In the case below, we'll be enabling this feature in one direction (from server "bigboy" to server "smallfry") and only using the unprivileged account called "filecopy".
Configuration - Client Side
Here are the steps you need to do on the computer which will be acting as the SSH client:
Ă‚
1.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Generate your SSH encryption keypair for the "filecopy" account. Hit the enter key each time you are prompted for a password to be associated with the keys. (ie. Do NOT enter a password.)
Ă‚
[filecopy@bigboy filecopy]# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key
(/filecopy/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/filecopy/.ssh/id_dsa.
Your public key has been saved in
/filecopy/.ssh/id_dsa.pub.
The key fingerprint is:
1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa
filecopy@bigboy
[filecopy@bigboy filecopy]#
Ă‚
2.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ These keyfiles are stored in the .ssh subdirectory of your home directory. View the contents of that directory. The file named "id_dsa" is your private key, and "id_dsa.pub" is the public key which you will be sharing with your target server. Non RedHat / Fedora versions may use different filenames, use the SSH man pages to verify this.
Ă‚
[filecopy@bigboy filecopy]# cd ~/.ssh
[filecopy@bigboy filecopy]# ls
id_dsa  id_dsa.pub  known_hosts
[filecopy@bigboy .ssh]#
Ă‚
3.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Copy the ONLY public key to the home directory of the account to which you will be sending the file.
Ă‚
[filecopy@bigboy .ssh]# scp id_dsa.pub filecopy@smallfry:public-key.tmp
Ă‚
Configuration - Server Side
Here are the steps you need to do on the computer that will act as the SSH server.
Ă‚
4.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Now log into smallfry as user "filecopy". Create a ".ssh" sub directory in your home directory and then "cd" into it.
Ă‚
[filecopy@smallfry filecopy]# ls
public-key.tmp
[filecopy@smallfry filecopy]# mkdir .ssh
[filecopy@smallfry filecopy]# chmod 700 .ssh
[filecopy@smallfry filecopy]# cd .ssh
Ă‚
5.Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Ă‚ Append the public-key.tmp file to the end of the authorized_keys file using the ">>" append redirector with the cat command. The authorized_keys file contains a listing of all the public keys from machines that are allowed to connect to your smallfry account without a password. Non RedHat / Fedora versions may use different filenames, use the SSH man pages to verify this.
Ă‚
[filecopy@smallfry .ssh]# cat ~/public-key.tmp >>
authorized_keys
[filecopy@smallfry .ssh]# rm ~/public-key.tmp
Ă‚
From now on you can ssh and scp as user "filecopy" from server bigboy to smallfry without being prompted for a password.