www.vsa-services.com

SSH Port forwarding:

My mail server can only relay mails for its own network and the office private net (on an NAT). So how do I relay mail when I am outside? Assuming the "outside" location allows ssh to my server, on the laptop, I run:

ssh -L 10025:indus:25 anand@indus

which connects port 10025 on the laptop to the port 25 (SMTP) on the server named indus

Now, I set my mail client to use SMTP server localhost, port 10025. The mail will be tunneled through SSH and relayed by indus. This can be somewhat automated to work from configuration files: [~/.ssh/config]

host indus localforward 10025 localhost:25

and ofcourse, KMail can use any preconfigured SMTP server to send email. Just click and hold down the send button. (Compare this with Outlook, :-) ) 

Disconnected SSH sessions:

From ROCKS mailing list:

set tcpkeepalive to yes in /etc/ssh/sshd_config and restarted ssh with service sshd restart. If you are using the csh/tcsh shell, add this to your .cshrc

unset autologout
set | grep auto

you'll see

autologout 60

The problems you quote below are from a user coming in from a Windows box vs a Linux box. In that case, the difference is between a DISPLAY variable being set or not. Without a DISPLAY variable, the csh/tcsh is going to default to timing out after 60 minutes. When a DISPLAY variable is set, the autologout does not occur.

Is there any firewall in between? eg: cisco : ssh timeout 60

> What doess your ssh and sshd config file have for:
>
> ServerAliveInterval
> ServerAliveCountMax
> ClientAliveInterval
>

I had similar problems with ssh from my home network and we also had reports  from users we have off campus that their ssh connections would freeze.  Indeed, setting the above parameters solves the problems.  I put this in my ~/.ssh/config:

ServerAliveCountMax 3
ServerAliveInterval 10

The downside is that you loose the network fault tolerance so minor glitches in the connectivity might disconnect you, but in general these parameters have solved the problem for us.

SSH with rsh-style host-based authentication:

Yes, I know it is bad, but if you need it, it is possible and here is how: Cluster: x86, Centos4.4 1. Create /etc/ssh/ssh_known_hosts , I copied the file from /root/.ssh/ to /etc/ssh ( and I got it by running ssh-keyscan) 2. Create the user's .rhosts file as usual:

cat .rhosts
head
c00
c01
c02

Don't forget to

chmod 600 .rhosts

, otherwise causing unnecessary grief. (ps: 644 also works) 2. Edit /etc/ssh/sshd_config. Make the following changes:

# change hostbased auth to yes
HostbasedAuthentication yes

# we will maintain the central knownhosts in /etc/ssh so safe to ignore users version of the file
IgnoreUserKnownHosts yes

#read users .rhosts file, change from yes to no
IgnoreRhosts no

# the default sequence is pubkey,passwd,hostbased
# so see the ssh_config to change the sequence
PasswordAuthentication yes

#If you wish turn off gssapi and x11 fwd
GSSAPIAuthentication no
X11Forwarding no

3. Edit /etc/ssh/ssh_config, make the following changes:

Host *
        GSSAPIAuthentication no
        HostbasedAuthentication yes
# next line is a new directive, not found in default ssh_config
        EnableSSHKeysign yes
        PreferredAuthentications hostbased,publickey,password,keyboard-interactive
        NoHostAuthenticationForLocalhost yes
        PasswordAuthentication yes

Setup /etc/hosts.equiv as usual.

cat /etc/hosts.equiv
head
c00
c01
c02

Propogate ssh_config, sshd_config, ssh_known_hosts, /etc/hosts hosts.equiv to all nodes and try logging in:

ssh node00 -v

Watch the messages and fix any problems reported (file permissions, etc)

Configuring RSH for password-less access:

Read the passwordless-keyless-rhosts based ssh auth. Do you still need to run rsh?

Think again. If yes, The following setup was tested on SUSE Linux. Install rsh client package Install rsh-server package
Edit /etc/xinetd.d/rsh change
disable=yes to no and
restart xinetd
Test rsh first. rsh localhost hostname

RSH fails for all users+root, from any host to any host, including localhost.

Create ~/.rhosts as follows: localhost root hostname-any root

Copy the file to all machines. Remember to restart nscd if running, else rsh fails with "permission denied" error.

Now, rsh works password-less for only root account between all machines. And rsh does not work for any normal user.

edit /etc/hosts.equiv add localhost remote-host1 remote-host2

Now rsh should work for any user. --- The following steps are unnecessary, but recommended by documentation at other sites---

edit /etc/hosts.allow add the following:

in.rshd : ALL : ALLOW

Ensure to append rsh to /etc/securetty on all nodes else "permission denied" messages will be returned

More notes: Change a line in
/etc/pam.d/rlogin to;
auth sufficient pam_securetty.so

by default it will be set to "required". rsh and rlogin are usually under xinetd control so you also need to add the -h flag on the server startup line to allow root rsh.

You should also restrict rsh and rlogin to your local cluster subnet with the "only_from" option.
Here's my rsh file in /etc/xinet.d

service shell {
         socket_type     = stream
         protocol        = tcp
         flags           = NAMEINARGS
         wait            = no
         user            = root
         group           = root
         log_on_success  += USERID
         log_on_failure  += USERID
         only_from               = 192.168.1.0/24
         server          = /usr/sbin/tcpd
         server_args     = /usr/sbin/in.rshd -haL
         disable         = no 
} 

You could also put restrictions in /etc/hosts.allow and deny since xinetd will use tcp wrappers if it's configured