SSH section

Security

to improve security you should have the following defined in sshd_config:

• ignorerhosts yes
• rhostsauthentication no
• rhostsrsaauthentication no
• rsaauthentication yes
• passwordauthentication no
• permitemptypasswords no
• uselogin no

the only way to log on to the destination host is: a file ~login1/.ssh/authorized_keys must exist.
in this file the public identity from the source host and user ~login2/.ssh/identity.pub must be contained.
otherwise a connection is refused. i strongly recommend not using the rsh/rlogin compatibility configuration as it is encrypted but insecure.

to create the identity file (user based) run the ssh-keygen command and follow the instructions.
after creating the identity files copy the ~/.ssh/identity.pub file from the source machine to the
~/.ssh/authorized_keys file on the target machine.

tcp forwarding

as with x-windows it is theoretically possible to forward any tcp based service through ssh. this allows for
example to retrieve pop mail through a ssh tunnel which secures the password string that otherwise is beeing sent in "clear text".

pop3

create a forwarding for port 110 and the destination host should be your pop3 server and the port 110. then log in, direct your pop3 client to fetch mail from "localhost" and there you have it.

file transfer

how do i transfer files securely with ssh ?

'scp' was designed for copying files between hosts securely. if you still want to use ftp, you can do it. first log
into the remote machine with 'ssh' with:

ssh -l3321:remotehost:21 remotehost

(where remotehost is the other machine name, and 3321 is an arbitrary port above the 1024 mark). 
then you can 'ftp localhost 3321' to log into the remote machine via ftp over a secure link. 
you'll have to use passive mode to actually transfer data, so if your server or client doesn't support it, 
you're stuck with 'scp'.

example: a subdirectory called 'tmp' on my local machine that i want to copy to the directory '/scratch' on a
remote host:

% tar cf - tmp | ssh remote_host '(cd /scratch; tar xvpf -)'
 % 
 #  if you wish to retrieve files from a remote host, do:
 % ssh remote_host 'tar cf - {file|dir ...}' | tar xvpf -

there is a mirror script for ssh that can be found on ftp://ftp.bizsystems.com/pub/secure/.

you might even want to check out rsync (my personal favourite). rsync can be found on ftp://samba.anu.edu.au/pub/rsync/rsync.html. rsync is very handy because it easily allows to use ssh as the transport layer.

per-erik martin has a unix program for setting up a secure ftp channel, using ssh.  
Look for http://www.docs.uu.se/~pem/hacks/ftpsshd-1.1.2.tar.gz.

X-Windows

In case you want to "tunnel" X-Windows through ssh you should be aware that with a ssh login the DISPLAY variable is set to the correct value. Do not change this value. Otherwise X11 forwarding will not succed. The X11Forwarding parameter in /etc/sshd_config should be set to yes. If you use compression with ssh you are able to get a better performance over serial or ISDN links.

X11 forwarding

For a background information, you should read Ulrich Flegel's paper,mentioned in http://wwwinfo.cern.ch/dis/security/x/problems.html.

There are several security risks associated with Xforwarding, even with no access to the SSHD machine. Here are two obvious ones that come to my mind.

1. if your home directory on the machine where SSHD runs is shared (e.g. with NFS, AFS...) then the magic secret giving access to your X server and stored in the ~/.Xauthority file will go on the network in clear.
2. if you hop from the machine where SSHD runs to another one, you may also expose your secret:
3. - tools like xrsh will pass the ~/.Xauthority in clear
4. - X clients started on remote machines will also send the secret in clear to the machine where SSHD runs

Config file problems

Can I use multiple lines for allow/deny entries ?

The sshd(8) manpage does not explicitly state anywhere whether or not multiple entries are supported, however upon examination of the source, the daemon reads it's config file in a line-by-line loop in "void read_server_config()" located in ssh-1.2.22/servconf.c . Here additional entries are added as long as there is room in the internal list, e.g. as many entries as MAX_ALLOW_HOSTS and MAX_DENY_HOSTS permit (each default to 256 entries).

The AllowHosts and DenyHosts internal lists are loaded into the sshd daemon at daemon startup and held in internal lists until it dies or someone tells it to re-read sshd_conf. noteably, any ordering implied in the sshd_config file of DenyHosts *relative to* AllowHosts is *not* preserved in the daemon's internal lists.

Permission denied

If you get a "permisson denied" error message and don't know how to cope with that, try using the -v switch of
either ssh or slogin:

[hh@desaster hh]$ slogin -l internet workspace
Permission denied.

[hh@desaster hh]$ slogin -v -l internet workspace
SSH Version 1.2.22 [mips-sgi-irix6.2], protocol version 1.5.
Standard version.  Does not use RSAREF.
desaster: Reading configuration data /etc/ssh_config
desaster: ssh_connect: getuid 1110 geteuid 0 anon 1
desaster: Connecting to workspace [192.129.41.210] port 22.
desaster: Connection established.
desaster: Remote protocol version 1.5, remote software version 1.2.22
desaster: Waiting for server public key.
desaster: Received server public key (1152 bits) and host key (1024 bits).
desaster: Host 'workspace' is known and matches the host key.
desaster: Initializing random; seed file /usr/people/hh/.ssh/random_seed
desaster: Encryption type: idea
desaster: Sent encrypted session key.
desaster: Received encrypted confirmation.
desaster: No agent.
desaster: Trying RSA authentication with key 'hh@desaster'
desaster: Remote: Bad file modes for /home/internet
desaster: Server refused our key.

In this case the home directory of the user internet on the destination machine workspace had dangerous file 
permissions [777]. Ssh refuses to make connections to the machine because anyone could possibly alter the 
~/.ssh directory that carries the keyfiles. 

 
             
            

SSH over SMB

I want to connect from a Windows 95 box to a Samba server over a SSH secure tunnel. How do I do it? What services do I need to enable on the Win95 box? What services do I need to disable? Which ports should I forward?

On the Win95 box, make sure that file & print sharing is turned off. In the \windows\lmhosts file (if you don't
already have one, copy it from \windows\lmhosts.sam), alias the SMB server you want to connect to as 127.0.0.1. Be sure to specify #DOM and #PRE. Browsing is out, but shares can be accessed by drive mapping and by "\\server\share" from the Start/Run menu.

I'm not sure if this will work without #PRE, and #PRE will screw up mapping the same server name when not using SSH, so if you needed this ability, you could choose a different, arbitrary name for ssh mapping, although this may confuse users. Set up "local" forwarding of (one or more of) ports 137, 138, and 139 to the same ports on the Samba server, then to connect to the share as \\127.0.0.1\myshare.

As for the ports 137 is used for netbios nameservice over IP, 138 is used for data and 139 are used for file & print service connection control.