Secure Shell ssh

Installation

Secure shell is the exclusive way to get into the secure environment of the HWW machines. Commands like telnet, ftp as well as the r-cmds are NOT allowed and therefore are rejected by the firewall.
Access to HWW platforms via ssh will definitely be restricted to ssh V2 ONLY!!

On HWW platforms the ssh software is installed. The user is responsible for installation of ssh on his platform.

The source of OpenSSH is available from

• HOME page of OpenSSH Alternatives for other platforms like MS Windows can also be found on this site.
  

For details on the licensing see the external link HOME page of OpenSSH

For details on the licensing see the copyright notice. Please read first the files README and INSTALL.

How to install ssh is described in the file INSTALL, there you'll also find a list of already tested platforms. To avoid any problems, especially in the security area, you should at least install ssh version 5.1 or later. The commands described at the beginning

./configure --disable-suid-ssh (Install ssh without suid bit)
make
make install

are sufficient in most cases. If you cannot use the ssh-client without suid-root bit for any reason, you will have to use the -P option with the ssh command and the -L option with the scp command to access HWW platforms.

Tips and hints

if you can't get a connection

this may have 3 causes:

1. Your workstation is not known by the firewall. Please call Mr. D. Raith (685-87224) or Mr. Rolf A. Supper (685-87225)
2. The HWW platform, you're trying to connect to, is currently not running. Please check the appropriate [[ http://www.hlrs.de/systems/platforms/status/ status]] page for your platform.
3. Your ssh client is setuid root. Please remove setuid root bit or use -P (for ssh) resp. -L option (for scp).

If you encounter any problems while connecting with ssh, please use -v option to get more detailed messages from ssh.

Filetransfer without password (scp) using Protocol version 2

Login via ssh resp. Filetransfer via scp is also possible without having to enter a password. Authentification is done via a public/private key pair. The following steps have to be accomplished:

(system1 is the machine from which you logon to the target system system2)

    System1 > ssh-keygen -d
    Generating public/private dsa key pair.
    Enter file in which to save the key ($HOME/.ssh/id_dsa): <RETURN>
    Enter passphrase (empty for no passphrase): <RETURN>
    Enter same passphrase again: <RETURN>
    Your identification has been saved in $HOME/.ssh/id_dsa.
    Your public key has been saved in $HOME/.ssh/id_dsa.pub.
    The key fingerprint is:
    2f:5c:18:e7:g0:3b:fb:52:g3:22:1d:3d:a4:cf:b1:57 $LOGNAME@$HOSTNAME

    System1 > cd $HOME/.ssh
    System1 > scp id_dsa.pub System2:sys1.pub
    System1 > chmod 700 $HOME/.ssh

    System2 > cd $HOME/.ssh
    System2 > cat $HOME/sys1.pub >> authorized_keys2
    System2 > chmod 700 $HOME/.ssh

The key generation with ssh-keygen has only to be done once. The public key in the file $HOME/.ssh/identity.pub can be used for as many systems as needed.

Further information regarding ssh can be found at external link http://www.cs.hut.fi/ssh/ or at external link DATA FELLOWS - F-Secure SSH A good alternative for Windows platforms is external link putty

ssh-x509 Certificate based ssh access

This access method is currently implemented for testing and evaluation purposes. Following Systems provide this service. (clr3fr1.hww.de (nehalem cluster) frbw.dgrid.hlrs.de (BW-Grid cluster) Be aware you need a special version of ssh-client with x509 support.

here is the instruction for MAC OS:

Fuer die openssh mit x509 Zertifikate wird das
Zertifikat selbst und ein privater Key benoetigt.
Unter MacOSX:
=============
z.B. habe ich vom DFN ein Zertifake beantragt und zugestellt bekommen.
Der Kram befindet sich in der Schluesselbundverwaltung.
Auf der Linken Seite befinden sich Schluessel - dort drauf klicken und 
man bekommt eine Liste von Schluesseln und Zertifikaten.
So nun den Richtigen Schluessel auswaehlen und den Privaten Schluessel 
als p12 exportieren. (hier sind Passwoerter noetig)
Dann das eigentliche Zertifikate als p12 exportieren.

1.) Aus dem exportierten privaten p12 Schluessel wird ein pem gemacht:
    openssl pkcs12 -in userkey.p12 -nocerts -out userkey.pem
2.) Aus dem exportieren p12 Zertifikat wird ebenso ein pem gemacht:
    openssl pkcs12 -in DFN-Zertifikate.p12 -nokeys -out usercert.pem
3.) Aus 1.) u 2.) wird jetzt ein ssh ident file generiert:
    cat userkey.pem usercert.pem > id_x509
    mit "vi id_x509" die Zeilen die zum "Bag Attributes" gehoeren loeschen 
    und die Rechte auf 400 setzen.
4.) Jetzt kann man daraus den public key erzeugen:
    ./software/sshx509/bin/ssh-keygen -y -f ./id_x509 > id_x509.pub
    (hier ist die gepatchte openssh noetig und das passwort des privaten
     schluessels)
5.) Fuer die serverseite benoetigt man nun noch das authorized_keys File:
    Distinguished_Name=`openssl x509 -noout -subject -in usercert.pem -nameopt RFC2253`
    KeyType="x509v3-sign-rsa" or "x509v3-sign-dss" (siehe id_x509.pub)
    echo $KeyType $Distinguished_Name > x509_authorized_keys
    Das erzeugte File x509_authorized_keys dem Admin des servers geben.


Login:
======
../software/sshx509/bin/ssh -i id_x509 -p 443 -l hpcbk cl3fr1.hww.de
(das passwort des privaten schluessels benoetigt)