SSH

OpenSSH Open Secure Shell
supports both : SSH1 [rsa] / SSH2 [dsa] protocols
OpenSSH suite :
1. sshd - server
2. ssh - client
3. ssh-keygen
4. ssh-agent
5. ssh-add
6. sftp-server
7. sftp
8. scp
============================
* Replacement for the dangerously insecure Berkely r cmds : rlogin, rcp and rsh
* Whenever you telnet or FTP (not anonymous FTP) to a remote machine, you are
asked to identify yourself by giving your login name and a password.
=========================
Case I - without any keys
=========================
Server
[ganesh]
======
1. # adduser foo
passwd ....
2. # service sshd restart
You OpenSSH server is now up
Client
[brahma]
======
1. login as 'foo'
2. # ssh -l foo ganesh
* The first time around it will ask you if you wish to add the remote host
ganesh to a list of "known_hosts"; go ahead and say yes. After saying yes,
and if there is an account on the remote system ganesh named foo, it will
prompt you for foo's password on the remote system [ganesh].
* If you type in the remote password correctly it should let you in.
3. Type 'yes'
4. Put you password which you gave on the remote SSH server for foo [a VLU]
* You are remotely logged in with ssh on ganesh. Just like telnet but secure.
* Examine your home on brahma [client] : /home/foo/.ssh/known_hosts
Will contain the sshd server name and a DSA algol key.
* The server you just successfully connected to is now a _known_host_
[sshd server ganesh is now a known host server]
* The next time you ssh to ganesh, this file is verified and now you will only
be asked for a password.
* The 'mitm' [man-in-the-middle] attack could still trip you dangerously
===================
Case II - with keys
===================
Client
[brahma]
==========
1. Login as foo
2. ssh-keygen -d
or -t rsa <--- to generate a rsa key
* Will autom generate a DSA public-private key pair of 1,024 bits.
* Press CR for the default file name to save the keys in :
/home/foo/.ssh/id_dsa
* Subsequently, you'll be asked for a passphrase (password) with confirmation.
* This can be anything and can be very long. Over 600 characters will be
accepted in the passphrase.
* The point is that passphrases are not supposed to be like your normal
password and should be much longer and kept just as secret as your normal
password.
* After you've typed in a passphrase twice it will spit out a long string of
numbers with your username@hostaddress at the end. Should look something
like this:
Your public key is:
ssh-dss AAAAB3NzaC1kc3MAAACBANTlkP9edHvaSnr+QDxD3cdJFOpOiGHTultOlp5J7RWzpENIb/AnK0iuYubCErYgGDiyqzR4duXD4V+zNy0vI1++pdFjpkN1h0X1RaCaJ04SnSca7jfnG7Pt65sYNoTldNl20RUZBmb/NbBttWBvLJxsGGs0pawYxXFSlhI7COhBAAAAFQCRW47ddyLK71XJu4vEY38OjpxAvwAAAIBCC+Ki98tAtmwFL+Sdvxxr1HA3bHQSqBUxOZawOkB7ri0l93o/wMcl8e20N+ffrGnVyc7DgI8klt2qXrJQ9LBasLl9aJR+HfUzOGfA8lSdJlxgAfFxHzOXVqgQ7OXhYKsHCs6MwixsuxSH0Nuaw2x4ZLs0ti09KJPwoL0gF8ptNgAAAIBA4MYs/MbtI1dkzk2ltq+vyOVVDuLdhTrMdCfLHGJWUij6wgbCe7wGwDOIR493LrUkgJkB01qru1qHRr1WAzlR/ZZ2Sv0CVsrRCBFN3etrMWhICl/1wV/3Cp7hev1gfjNY2GgXIo51ujIU/yFgQna83Paf2s43e9l7MmB5LdwctA== bar@brahma.bom.labs.net
* However your terminal program will have wrapped the long lines around so
that it all fits on one screen. It's important to keep in mind though that
the string of numbers is and must all be on one line as it is shown above.
* The big line above consists of 4 sections. It's important that each of
those sections have no spaces in them. The first section is the bit level
and is usually going to be 1024, the second section is the salt, the third
is the actual key and the forth section is the user@host identification.
* You will be asked this paraphrase whenever you access the sshd machine.
* You will notice a new dir created in your home : /home/foo/.ssh/
The public and private keys just generated stored viz :
/home/foo/.ssh/
---------------
private key : /home/foo/.ssh/id_dsa
public key : /home/foo/.ssh/id_dsa.pub
* That's all on the client side !
Server-side Config
[ganesh]
==================
1. Login as root.
2. # service sshd start
3. # su - 'foo'
4. # mkdir .ssh
5. # cd /home/foo/.ssh/
6. Copy & Rename the file : /home/foo/.ssh/id_dsa.pub from 'brahma' [Client]
to /home/foo/.ssh/authorized_keys on 'ganesh' using scp or ftp or whatever!
Lets see the contents of foo on brahma w/o logging in
a. # ssh brahma ls
Now lets copy the file /home/foo/.ssh/id_dsa.pub from 'brahma'
here and rename it as authorized_keys
b. scp brahma:.ssh/id_dsa.pub authorized_keys
7. Make sure the perms of /home/foo/.ssh/authorized_keys file on server 'ganesh'
is 600 i.e. R/W only by foo
# chmod 600 authorized_keys
8. Make sure dir /home/foo/.ssh/ has perms of 700
chmod 700 /home/foo/.ssh/
Alert !!! ---> Make sure 7 and 8 are satisfied otherwise ssh will not work

Execution :
=========
1. Login from client [brahma] to server [ganesh] as foo.
# ssh -l foo ganesh
2. You will now be prompted for your paraphrase.
* This will be matched with your local [brahma] private key and not the
password of foo on ganesh. [/home/foo/.ssh/id_dsa]
* If it matches a request will be sent to the SSH server running on
"ganesh:22".
* The SSH client on the local machine brahma contacts the sshd daemon on the
remote SSH server [ganesh].
* The client tells the server that a user 'foo' wants to connect.
* The server then examines who made the request - 'foo'
* It will check whether 'foo' is a VLU in /etc/passwd.
* If OK, then it will create a challenge using the public key file you had
copied to foo's home on the server, before, from foo's home on brahma :
/home/foo/.ssh/authorized_keys
Remember we had renamed it ?
* If an entry is there for a public key corresponding to the user, the server
generates a random message, constructs an MD5 message digest and encrypts it
with the user's public key - which is now the above file
* This is then sent to the client [brahma].
* The client looks in this identification file aka private key. Since only
the client has the corresponding private key, which is :
[/home/foo/.ssh/id_dsa] on brahma
it can only decrypt the message. This results in the message digest.
* Now the client computes a checksum of the message digest and sends it back to
the server.
* The server then computes the checksum of the message digest it had sent to the
client. If this checksum and the checksum received from the client are the
same, then the client can be trusted to have the correct private key, and the
authentication procedure is completed.
* You normally give foo's local login passwd on server to access FTP etc.
But here that is never asked.
* Never once are you prompted for any password at all.
* Hence, sshd never uses passwords to login and that is one huge leap
as far as security consciousness is concerned !

======================
Case III
ssh-agent* and ssh-add*
=======================
* How about starting a SSH session, fully secure and never having to enter a
password or even the passphrase too ?
* Well, weird as it sounds security-wise, this is exactly what the ssh-agent
does on the client
* Now try this :
Client
[brahma]
========
1. Login as foo
2. Append the following line to and relogin as foo:
/home/foo./.bash_profile
========================
eval `ssh-agent`
or from the cmd line : # eval $(ssh-agent)
You should now see a message like : Agent pid [number]
* The authentication agent must be running and must be an ancestor of the
current process for ssh-add to work. You need the shell's eval cmd for this.
* ssh-agent executes several commands, creates an PID file and sets some
system env variables.
3. Re-login and the ssh-agent will now be running as 'foo'
4. Now do this :
# ssh-add ----> will load SSH2 keys - The DSA ones
or
# ssh-add .ssh/id_rsa ----> will load SSH1 keys - The RSA ones
Enter the paraphrase you had entered the first time you made the private
keys on the client.
If it matches, you will get the following message :
Identity added : /home/foo/.ssh/id_rsa (/home/foo/.ssh/id_rsa)
5. Try this now :
# ssh -l foo ganesh
And you are in - without password authentication, but totally secure !
* Luckily, ssh-agent doesn't remember the information after you logout.
Otherwise, once a passphrase was entered with ssh-add, the security of a
protected passphrase would be pointless if somebody broke into your system.
* So after you logout, you will have to do a 'ssh-add' for the session
* The agent is only valid for the duration of the session

scp*
Copy files securely

* SSH gives you access to a set of commands and a shell on a remote machine.
By itself, it does not enable you to copy files, it however provides the
'scp'command.
- You are foo, logged in to Client brahma
- You wish to copy a file foo1 from your home on the ssh server
ganesh to your home on the remote client brahma or wherever
you are currently logged in
ganesh brahma
[ssh server] [client]
============= ========
/home/foo : /home/foo :
========== ==========
-> Copy file foo1 from ganesh
# ls # ls
# foo1 foo2 # scp ganesh:foo1 . [dot is mandatory]
# ls
# foo1
-> Copy file /etc/hosts from ganesh
# scp ganesh:/etc/hosts .
# ls
# foo1 hosts
# ls
-> Copy file foo1 to ganesh's /tmp
# scp foo1 ganesh:/tmp

-> Copy file foo3 to foo's home on ganesh
# scp foo3 ganesh:
# cd .ssh/
----> foo's own config file # vi config
for global use Host *gbln
/etc/ssh/ssh_config HostName ganesh.bom.labs.net
User foo
ForwardAgent yes
Now use will be able to do this :
# scp foo3 gbln:
* 'scp' assumes your home directory on the server to be your current working
directory, so if you are using relative paths for the server, they have to
be relative to the location of your home dir on that machine.
* Using the -r switch for 'scp', you can also copy directories recursively.
* 'scp' also allows you to copy files between two remote machines other
than your own, of course.
* Now you might be tempted to try something like this:
You open an SSH connection to ganesh.bom.labs.net. Once you are
logged in, you type
# scp brahma:b1 .
to copy the local file 'b1' to the remote server you are currently logged
in. Most likely you will get a message like :
ssh: secure connection to [brahma machine] refused
What has happened is that you executed the remote version of 'scp', and
it tried to connect to a non-existant SSH server running on your machine
which is brahma !!
MOTS :
Remember to run 'scp' always from a local terminal, unless your machine
[brahma] also runs an SSH server.

sftp*
Copy files securely with sftp

* If you prefer a more 'ftp-ish' approach, try 'sftp'
* 'sftp' establishes an SSH tunneled FTP connection to a server and allows you
to use most of the standard FTP command set.
* Since version 2.0.7, the popular graphical FTP client - gftp - supports
sftp-transfers, which makes up for sftp's somewhat limited feature set.
[we are using gftp-2.0.14-2 in RHL9]
[foo@brahma foo]$ sftp ganesh
You will be asked for the paraphrase :
sftp>
* The sshd server starts up the sftp server auto on connect by the sftp
client.
This sftp-server is : /usr/libexec/openssh/ftp-server
'sftp' will activate this server automatically upon connect, and you'll need
no extra permissions on the remote server.

Configuring the OpenSSH -
Server and Client


Configuring the The OpenSSH client - /usr/bin/ssh

Configuring The Client : Global client config file : /etc/ssh/ssh_config
Per user config file : $HOME/.ssh/config
[by def: dir / file nonexistant]
OpenSSH knows three configuration levels:
* command line options
* User configuration file
* System-wide configuration file ('/etc/ssh/ssh_config').
* Options given on the command line prevail over configuration file options
* Options given in the user's configuration file prevail over those in the
system-wide configuration file.
* All command line options are available as configuration file options.
* Since there is no user config file installed by default and hence, no
$HOME/.ssh/ dir, copy and rename '/etc/ssh/ssh_config' to '~/.ssh/config'
(or edit '/etc/ssh/ssh_config' as 'root').
* The standard config file looks like this:
[lots of explanations and possible options listed]
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
* The config file is read sequentially, i.e. the first setting that matches a
pattern 'wins'.
* Let's say you have an account at ganesh.bom.labs.net and your account name
is 'foo'.
* Furthermore you want to use the 'ssh-agent' - 'ssh-add' combo (see before) as
well as data compression to speed up transfers.
* And since you are too lazy to type the full hostname every time, you want to
use 'gbln' as an abbreviation for 'ganesh.bom.labs.net'
* Your config file should then look like this:
Host *gbln
HostName ganesh.bom.labs.net
User foo
ForwardAgent yes
Compression yes
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
* Next time, as foo, you enter :
# ssh gbln
SSH will look up the full hostname, use your user name to login and
authenticate using the key managed by the 'ssh-agent'. It can't get much
easier than that, can it?
* SSH connections to all other hosts will still use the 'paranoid' default
settings, the configured accounts only those paranoid settings which haven't
been explicitly turned off in their configuration or on the command line.
* In the example above, an SSH connection to ganesh.bom.labs.net will have these
options set to 'yes': 'ForwardAgent' and 'Compression', these options,
however, will still be set to 'no' unless overridden by command line arguments
: 'ForwardX11' and 'FallBackToRsh'.
* Further options you might want to have a look at include:

CheckHostIP yes
This option performs an
additional IP address check on the remote host to prevent
DNS spoofing.

CompressionLevel
The compression level
ranges from '1' (fast) to '9' (best). Default is '6'.

ForwardX11 yes
You will need this option
to run remote X applications locally.

LogLevel DEBUG
This option comes in
handy when you've got trouble with your SSH connection. The
default setting is INFO.

===================================================
Configuring the The OpenSSH server - /usr/sbin/sshd
===================================================
* SSH server configuration file : /etc/ssh/sshd_config
* Note that OpenSSH does not have different configuration files for SSH 1.x
and 2.x.
* Among the default options you might want to have a look at, are :
PermitRootLogin yes : A preferable option might be PermitRootLogin
without-password which disables 'root' logins from
machines without a matching key pair.
Setting this option to 'no' disables 'root' logins
completely and you'll have to use su from a user
account.
X11Forwarding no Change this option to 'yes' to allow your users to
run X apps on your machine.
Furthermore, disabling this option doesn't improve
your server's security since users can always
install their own forwarders
PasswordAuthentication yes
Setting this option to 'no' will only allow SSH
logins using the key mechanism. Cleartext passwords
tunnelled thru SSH will not be allowed.
This might annoy users who are logging in from
different machines frequently but is a boost to
server security.
(password-based authentication schemes are weak)
Subsystem sftp /usr/libexec/openssh/sftp-server
This is def ftp server bcos users may not like the
cryptic syntax of scp.
Install the 'sftpserv' rpm, which is a SSH tunneled version
of FTP ('sftpserv' is part of the sftp package).
Since users are familiar with ftp, this pkg is exactly like
that and is a worthwhile thing to install.
Do not forget to change the path above to
'/usr/bin/sftpserv'
after install the new server.
Moreover, the popular graphical "gftp" program supports
transfers via 'sftp' since version 2.0.7 (which makes up for the missing features in pure 'sftp').