SSH Install v24

Version 2.
Bowden Systems Inc.

Norcross, GA 30092 http://www.bsi2.com
Notice
The information contained in this document is subject to change without notice.
BOWDEN SYSTEMS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MANUAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Bowden Systems shall not be liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Warranty
A copy of the specific warranty terms applicable to your BSI product can be obtained from the BSI Corporate Office.
Printing History
The printing date will change when a new edition is printed. Minor changes may be made at reprint without changing the printing date. The manual part number will change when extensive changes are made. Manual updates may be issued between additions to correct errors or document product changes. To ensure that you receive these updates or new editions, contact the BSI Corporate Office. October 2001 . . . Edition 1 February 2002 . . . Edition 2 June 2003....Editon 3 July 2004...Edition4 Feb 2008...Edition 5 March 2008...Edition 5a Bowden Systems, Inc. 3500 Parkway Lane, Suite 370 Norcross, GA 30092, USA email:sales@bsi2.com web:www.bsi2.com 2001- 2008 Bowden Systems, Inc.
NSK-SSH, sftp-server-guardian, scmd is a trademark of Bowden Systems Inc. Nonstop, TEDIT, TACL, Guardian 90, 6530, PATHWAY are trademarks of HP. Mr-win6530 is a trademark of Conforte. Cail6530 is a trademark of Cail.
Preface
This manual explains how to install, configure, and use NSK-SSH software for the HP NonStop server. This includes setting up the components of the software which are the ipssh, sshd, and prngd.
Audience and Prerequisites

This manual is intended for system managers and assumes that the user has experience with OSS, GUARDIAN, TCPIP, PTCPIP and SCF.
Prerequisite Equipment
This manual also assumes that the users host is S-Series running GUARDIAN G06.22 or higher, GUARDIAN H-Series running H06.05 or higher, or GUARDIAN J-Series J06.02 or higher. This software works with TCPIP V4 and TCPIP V6 tcpip stacks.
iii
1. OVERVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. INSTALLING THE SOFTWARE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BASIC SETUP OF SSH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. ADVANCED SETUP OF SSH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 a. TELNET ISOLATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 b. KERNEL SUBSYSEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. CHECKING YOUR SESSION ACCESS VIA PC CLIENT. . . . . . . . . . . . . . . . . . 17 6. CHECKING YOUR SESSION ACCESS VIA UNIX CLIENT. . . . . . . . . . . . . . . . 19 7. KNOWN PROBLEMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. INFORMATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 APPENDIX A - MAN PAGES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 prngd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ipssh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ssh-keygen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 ssh-keyscan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 sshd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 sftp-server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 sftp-server-guardian. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 scmd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 sftp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 scp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ssh-add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ssh-agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 ssh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 APPENDIX B - REQUIRED FILES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 sshd_config FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 ssh_config FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 APPENDIX C - TELNET ISOLATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 start_ssh_2_cpu_2stack.sh - SSHD using two IP stacks. . . . . . . . . . . . . . . . . . . . 101 APPENDIX D - ZZKRN FILES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 ipztc00a - IPSSH ON CPU 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 start_ipssh_ztc0a.sh - IPSSH ON CPU 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
ipztc00b - IPSSH ON CPU 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 start_ipssh_ztc0b.sh - IPSSH ON CPU 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 ranztc0a -PRNGD ON CPU 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 start_random_ztc00a.sh - PRNGD ON CPU 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 ranztc0a -PRNGD ON CPU 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 start_random_ztc0b.sh - PRNGD ON CPU 01. . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 sdztc00a -SSHD ON CPU 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 start_sshd_ztc00a.sh - SSHD ON CPU 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 sdztc00a -SSHD ON CPU 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 start_sshd_ztc00b.sh - SSHD ON CPU 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
OVERVIEW
This is a release of the NSK-SSH V2.4 that is based on OpenSSH 2.9.9p2 with 3.4.x security enhancements and PRNGD 0.9.15 for the G06.22/H06.05/J06.02 operating system. The NSK-SSH has been updated to fix various problem the the random number generator and has move to using TCPIP for the communications between the random number generator and the SSH process. Now you can have up to 4 random number generators per TCPIP V4 OR V6 stack or up to 64 with PTCPIP using the round-robin method of access . The random number generator does not require any external programs or files for generating its random numbers. In this release, we also added a new command to address problem with executing remote commands from the system. This new command is called scmd and allows you to execute remote commands from the NonStop system. We also have added an sftp-server for the guardian file system. This allows you to access the guardian file system just like the unix file system. This provides compatibility with programs such as FileZilla. This release has also been verified to work with Mr-Win6530. We now also have the ability to set up all the components of this release in the KERNEL (ZZKRN) subsystem for full fault resilance. This also include the ability to access an isolated TCPIP stack which has telnet running on it for the telnet requirment of SSH. This was created do to the need of users that have PCI requirments of not having TELNET running on the system or FTP. This release will allow you to access the NonStop system in a secure manor for session and ftp access. This software works with alias and standard GUARDIAN users. You should install this software using the SUPER.SUPER or root user id. This installation document assumes that you have OSS, and TCP/IP installed and configured on your system. You no longer need to have the OSS local socket program running. This document will tell you how to install and configure NSK-SSH software for access to the system and provide a reference for the MAN pages included with the NSK-SSH software. If you require more detailed information on SSH, you should consult SSH The Secure Shell by Daniel J. Barrett & Richard E. Silverman. This can be purchased from the Oreilly web site (www.oreilly.com).
NSK-SSH V2.4
Page 1
March 31, 2008
Note: This page is left blank for double sided printing.
NSK-SSH V2.4
Page 2
March 31, 2008
INSTALLING THE SOFTWARE

You must be the root user or super.super to install this software. To install the software that was downloaded from the web site, do the following: For the S-Series:
export PATH=$PATH:/bin/unsupported:/bin zcat SSH_GO622_V24.tar.Z | pax -rvf -
For the H-Series and J-Series operating system:

export PATH=$PATH:/bin/unsupported:/bin zcat SSH_H0605_V24.tar.Z | pax -rvf -
Note that zcat is in the /bin/unsupported directory. Note that the above tar file may have a version indicator on it. This will install the software into the following directories:
/etc/ /etc/ssh /usr/local/ssh /usr/local/random
Now you are ready to set up the, IPSSH, SSH and PRNGD software.
NSK-SSH V2.4
Page 3
March 31, 2008
NSK-SSH V2.4
Page 4
March 31, 2008
BASIC SETUP OF SSH

To set up your system so that you use the SSH software, you should do the following: 1. You should have the following products installed on your system: a. b. c. d. e. f. g. OSS Installed and Configured. TCPIP V4 or V6 Installed and Configured OSS Sockets Started on each processor. TCPIP configure for OSS. TELNET servr running on the TCPIP stack LOCAL LOOP BACK STARTED for TCPIP stack REMOVE ANY OPENSSH ssh software on your system as this will cause problems with installing and startup up the Bowden Systems version of SSH,
You will need the following information: a. The ip address and stack process name you will use for SSH access. b. Know how to use the text editor vi. c. SSH Client Software ( Mr-Win6530, Cail6530, Putty, Unix SSH)
2. Verify that you have the services and protocols file in the /etc directory. If you do not have these files, then you can copy the files services.bsi to services and protocols.bsi to protocols. IMPORTANT FOR TELNET ACCESS cd /etc cp services.bsi services cp protocols.bsi protocols Note that the service that the sshd program is looking for is the telent service. If you alreay have a services file, then you need to make sure that has the following line: telnet 23/tcp
NSK-SSH V2.4
Page 5
March 31, 2008
If the services program does not have this line, then you need to add it using vi.
NOTE IF YOU DO NOT HAVE A /etc/services FILE, THE TELNET ACCESS TO SSH WILL NOT WORK. 3. Set your PATH and MANPATH variables. export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin export PATH=$PATH:/usr/local/ssh/install export MANPATH=$MANPATH:/usr/local/ssh/man export MANPATH=$MANPATH:/usr/local/random/man Note that these can be place in /etc/profile or in your private home directory file .profile. 4. Set the correct file settings on the installed files. a. Move to the install directory cd /usr/local/ssh/install b. Execute a script to change the file setting sh -v ./ssh_install_chmod.sh 5. Verify that the define =TCPIP^PROCESS^NAME is already set. If you are using the default tcpip process name $ZTC0, then it is not necessary to do this step. But if you are using some other tcpip process name, do the following: info_define all To add the define, do the following: add_define =TCPIP^PROCESS^NAME file=\$ZTC1 Note that this is an example. You should use what ever tcpip process name is defined on your system, or that you want to random number generator to use.
NSK-SSH V2.4
Page 6
March 31, 2008
6. Start up the Random number generator (PRNG). This must be started before any SSH software can be used. !!!! IMPORTANT STEP NOT TO FORGET !!!! a. Move to the install directory cd /usr/local/ssh/install b. Execute a script to startup the random number generator. sh -v ./start_random.sh This will start the random number generator on local sockets connection 127.0.0.1 port 790. The script executes the following: run cpu=0 -gpri= 144 prngd tcp/localhost:790 7. Generate the system keys. Note that this may take a while. Execute a script to generate the system wide keys. sh -v ./ssh_install_makekeys.sh This will generate the following files in the /etc/ssh/ directory: ssh_host_key - Host Private Key ssh_host_key.pub - Host Public Key ssh_host_rsa_key - RSA Private Key ssh_host_rsa_key.pub - RSA Public Key ssh_host_dsa_key - DSA Private Key ssh_host_dsa_key.pub - DSA Public Key 8. Modify the system wide configuration to the specify the IP address that the SSHD program will use. This step is optional. This is only needed if you ssh to listen again a specific address. To make this change, do the following:
vi /etc/ssh/sshd_config
Find the line: ListenAddress 0.0.0.0 and change the 0.0.0.0 to the ipaddress of your system and save the file. Note if you are using TCPIP V4 then you should set this to 127.0.0.1 for the two cpu or greater configuraiton.
NSK-SSH V2.4
Page 7
March 31, 2008
9. If you are starting the Bowden NSK-SSH software on a system that has the Comforte SSH software on it and configured to use the port 22 on $ztc0, then you need to stop this software, before you can startup the NSK-SSH software. scf> assume process $zzkrn scf>names You should look for #ssh-ztc0. If this is running, then you need to stop it. scf> abort #ssh-ztc0 This will abort the process and then you can start up the NSK-SSH software. 10. If you want to start SSHD on two cpus scipt to step 10. If you want to start ssh on one cpu, then continue reading. To start the sshd program do the following: run -cpu=0 -gpri=125 /usr/local/ssh/sbin/sshd This will start the sshd server and it will listen on port 22 for any connection. If you only run one SSHD server, then you should not change the ListenAddress to 127.0.0.1 and change it to the real address of the stack. If there is more than one address associated with the stack then, you should leave it set to 0.0.0.0 If you want to start the program in the debug mode to see what it is doing, do the following: /usr/local/ssh/sbin/sshd -d -d -d This will allow one session to be processed and then the program will exit when the request is finished. The sshd program will process all request (session, scp, ssh and sftp).
NSK-SSH V2.4
Page 8
March 31, 2008
10. Starting SSH on two cpus using regular TCPIP or P/TCPIP in Failover mode If you want to distribute the load of your SSH process over two cpus. You can execute the file start_ssh_2_cpu.sh or do the following: 1. Using the startup file: cd /usr/local/ssh/install sh -v ./start_ssh_2_cpu.sh 2. Starting it manually. a. Start the SSHD process on port 700 and 701. run -cpu=0 -gpri=120 /usr/local/ssh/sbin/sshd -p 700 run -cpu=1 -gpri=120 /usr/local/ssh/sbin/sshd -p 701 b. Start the primary IPSSH ($ISX) process. run -cpu=0 /usr/local/ssh/sbin/ipssh sleep 5 c. Start the backup IPSSH ($ISY) process. run -cpu=1 /usr/local/ssh/sbin/ipssh -wait 0 11. Starting SSH on two cpus using P/TCPIP with round-robin configuration. If you want to distribute the load of your SSH process over two cpus. Note that on most systems, the TCPIP V6 software is configured in fail-over mode and not configurated for round-robin, we put this startup file in as example of how to run the SSHD server on a system that is uses that configuration. You can execute the file start_ssh_2_cpu.sh or do the following: 1. Using the startup file: cd /usr/local/ssh/install sh -v ./start_ssh_ptcpip_2cpu.sh 2. Starting it manually. a. Start the SSHD processes on port 22. run -cpu=0 /usr/local/ssh/sbin/sshd run -cpu=1 /usr/local/ssh/sbin/sshd
NSK-SSH V2.4
Page 9
March 31, 2008
Note that you can use this configuraiton on TCPIP V4 if there is more than one IP addres define to the TCPIP stack and it is not in the FAIL-OVER configuraiton.
NSK-SSH V2.4
Page 10
March 31, 2008
ADVANCED SETUP OF SSH

In this section, we will talk about advanced set up of the SSH software including the KERNEL subsystem and TELNET isolation.
TELNET ISOLATION
For those of you that want to stop all of your telnet and ftp processes on the system, we have a solution that allows you to do this execpt for an isolated TCPIP stack with telnet running on the loop back port. The idea is the run the TCPIP process on your systems that is not attached to any hardware and only use the loop back port. This #LOOP0 is started and a TELSRV process is started against this and no listner process. With this configuration, our SSHD process can use this isolated stack for telnet access. To use this feature, you need specify the following environment variable before starting the SSHD process: TCPIP_TELNET_STACK This is equal to the process name of the TCPIP stack that is isolated. In our script call start_sshd_2cpu_2stack.sh, we use the TCPIP process name $ztc99, so this variable is set to: export TCPIP_TELNET_STACK=\$ztc99 To do this do the following (Note this works on all release of the Guardian OS including H-series and J-series: 1. Start up the TCPIP V4 stack at tacl: TCPIP/name $ZTC99,PRI 190,CPU 0,TERM $ZHOME/0 2. Start the #LOOP0 port on the stack. scf> assume process $ztc99 scf> aler subnet #loop0, ipaddress 127.1 scf> start subnet * scf> exit
NSK-SSH V2.4
Page 11
March 31, 2008
3. Start up the TELSRV process add define =TCPIP^PROCESS^NAME,FILE $ZTC99 param TCPIP^PROCESS^NAME $ZTC99 param ZTNT^TRANSPORT^NAME $ZTC99 TELSERV/NAME $ZTN99,CPU 0,NOWAIT,PRI 170/23 Note that the 23 on the TELSERV command is the port to listen to. Now at this point, you should be able to access the TELNET server locally: TELNET 127.0.0.1 23 WELCOME TO test.bsi1.com [PORT $ZTC99 #23 WINDOW $ZTN99.#PTYAAAA] TELSERV - T9553D40 - (15SEP2000) - (IPMADG)
Available Services: TACL EXIT Enter Choice> If this works, now you are ready to add the TCPIP_TELNET_STACK, to your SSHD start file and restart the SSHD servers
NSK-SSH V2.4
Page 12
March 31, 2008
KERNEL SUBSYSTEM
We have included in this setup the install directory the scripts for setting up the SSHD software using the standard TCPIP V4 or V6 software using the ipssh, prngd, and sshd process running as persistant processes in the ZZKRN file. What you need to do this, is the following: cd /usr/local/ssh/install/zzkrn cp ZZKRNSD.100 /G/system/nosubvol/ZZKRNSD gtacl>logon super.super volume /G/system/nosubvol fup alter zzkrnsd,code 100 run zzkrnsd, $*.*.*,vol $system This will install the subvolume $system.zzkrnsd on your system. Now, you only need Note that you need you need to change 127.0.0.1. This is to install the files in the zzkrn subsystem. to be root or super.super to do this and your /etc/sshd.config file to listen on port the ListenAddress configuration line.
scf> assume proces $zzkrn scf> volume $system.zzkrnsd The obey files adds the process service and starts up the service. scf> scf> scf> scf> scf> scf> obey obey obey obey obey obey ranztc0a ranztc0b sdztc0a sdztc0b ipztc00a ipztc00b start start start start start start up up up up up up cpu cpu cpu cpu cpu cpu 0 1 0 1 0 1 random generator port 790 random generator port 791 sshd process port 700 sshd process port 701 ipssh1 process port 22 ipssh1 process port 22
Now check the status of the serivces scf> status They should all be running. In the zzkrn subsystem, you have added the following servies: $ZZKRN.#IPSSH-ZTC00A $ZZKRN.#RANDOM-ZTC00A $ZZKRN.#IPSSH-ZTC00B $ZZKRN.#RANDOM-ZTC00B
NSK-SSH V2.4
Page 13
March 31, 2008
$ZZKRN.#SSHD-ZTC00A
$ZZKRN.#SSHD-ZTC00B
if you want to stop a service, all you need do is the following: scf> scf> scf> scf> scf> scf> scf> assume process $zzkrn abort #IPSSH-ZTC00A abort #IPSSH-ZTC00B abort #SSHD-ZTC00A abort #SSHD-ZTC00B abort #RANDOM-ZTC00A abort #RANDOM-ZTC00B
The purpose of putting the files under this subsystem is to restart the process if one every stops or a CPU dies. Note that when you abort the software, the process running in the script does not stop. It is only when you restart the software, that process will be restarted. When your system is started up, you must have a script to start up the SSH software in the correct order or it will not start at system startup. This script is the following: assume process $zzkrn start #RANDOM-ZTC00A start #RANDOM-ZTC00B start #SSHD-ZTC00A start #SSHD-ZTC00B start #IPSSH-ZTC00A start #IPSSH-ZTC00B
For each startup script, there are two process names used, these names are the following: #RANDOM-ZTC00 - script name $ob000 - process name $RD000 #RANDOM-ZTC01 - script name $ob001 - process name $RD001 #SSHD-ZTC00A - script name $ob020 - process name $sd000 #SSHD-ZTC00B - script name $ob021 - process name $sd001 #IPSSH-ZTC00A - script name $ob10 - process name $ip000 #IPSSH-ZTC00B - script name $ob11 - process name $ip001
NSK-SSH V2.4
Page 14
March 31, 2008
Porting Differences
This section will talk very briefly about the differences between this port of NSKSSH and what you get would from Open Source. The major difference of this port from the standard SSH and Prngd port is how sessions are accessed and how we access the random number generator. This is not a part of the standard. We added a new command to handle remote command execution, because of problem with the select function not support the tty device, and support for the guardian file system via sftp. This was not a problem in standard SSH. Under the standard model of SSH, all sessions are accessed using the master/slave pty configurations. Since the OSS environment does not support ptys, we use the telnet subsystem as the pty generator. When NSK-SSH request a pty, we request access on the 127.0.0.1 port 23. We also have the ability to make this request to another TCPIP stack that is not attached to any Ethernet hardware and is only running TELSRV. This allows all TELSRV services to be stop. If you request that a pty is not allocated, the sshd program will access the users default shell script as the standard SSH port does. This port of SSH understands about ALIAS users and does it password authentication against the safeguard database. The standard SSH software does not know any thing about this. This port of SSH uses the tcpip access to random number generator to increase performance, reliablity, and scalability. This also reduces connect time when performning any action that requires a random number. Which in the case for all commands on SSH. This port of SSH and PRNGD has been fault tested to make sure that it works when a CPU fails. We also increase the capacity of the random number generator to handle large request loads. We added a distributor to the release so that it is possible to support round-robin access using the standard TCPIP software and scale the ssh software and random number generator software across multiple cpus.
NSK-SSH V2.4
Page 15
March 31, 2008
NSK-SSH V2.4
Page 16
March 31, 2008
CHECKING YOUR SESSION ACCESS VIA PC CLIENT

At this point, you have done the basic setup for the SSH software. In this section, we will be discussing how to access your system to establish session. You will need an SSH client for your PC, Mac, or Unix system to start a session. In this example we are using, MacSSH, but this will apply to Windows software too. 1. Select your host and select Secure Shell
2. Enter your user name and password:
NSK-SSH V2.4
Page 17
March 31, 2008
3. Get the system access prompt. Note that depending on what type of system, you are executing the sshd software on, it may take a while for the session to connect. This has to do with the encryption of the session.
At this point, you can access the NonStop as you always have. Just login in an start working.
NSK-SSH V2.4
Page 18
March 31, 2008
CHECKING YOUR SESSION ACCESS VIA UNIX CLIENT

If you have other unix systems, that have SSH installed, you can access the HP NonStop using ssh. To start a session remotely on the HP NonSTop do the following: $ssh joshua@test.bsi1.com joshuas password:
WELCOME TO test.bsi1.com [PORT $ZTC0 #23 WINDOW $ZTN0.#PTYW1DX] TELSERV - T9553D40 - (15SEP2000) - (IPMADG)
Available Services: TACL EXIT Enter Choice>
If you want to execute a remote commad, do the following: $ssh joshua@test.bsi1.com /bin/ls joshuas password: test.pl test1.pl test2.pl test3.pl test5.pl test_message $ If you want to copy a file from the unix system to the NSK, do the following: $scp test.pl joshua@test.bsi1.com:test.pl joshuas password:
NSK-SSH V2.4
Page 19
March 31, 2008
If you want to logon directly to TACL, do the following: $ssh joshua@test.bsi1.com /bin/gtacl joshuas password: TACL 1> Note that you wil not beable to execute any oss commands with this tacl session because you are not using the standard telnet tty session attributes.
NSK-SSH V2.4
Page 20
March 31, 2008
KNOWN PROBLEMS
We added the scmd program to allow remote command access to a system. This currently only supports commands that do not require any interaction with the user. This will be fixed in next release. Should you find any problems with this software, you should send an email message to support@bsi2.com.
NSK-SSH V2.4
Page 21
March 31, 2008
INFORMATION
If you need any help with this, please send an email message to support@bsi2.com. Any correspondence regarding this software can be sent to the following address: Bowden Systems, Inc. 3500 Parkway Lane, Suite 370 Norcross, GA 30092 USA +1 866-901-9450 toll free +1 770-441-9450 direct +1 770-441-9449 fax web: www.bsi2.com email:sales@bsi2.com
Copyright (c) 2001-2008 Bowden Systems, Inc. All Rights Reserved
NSK-SSH V2.4
Page 22
March 31, 2008
APPENDIX A - MAN PAGES prngd

PRNGD(8) NAME prngd - random number generator daemon SYNOPSIS prngd [options] (/path/to/socket1 | tcp/localhost:port | tcp/ip:addr:port) [(/path/to/socket2 | tcp/localhost:port | tcp/ip:addr:port)] ... OPTIONS -f or -fg do not fork -d or --debug debugging on -c or --cmdfile cmdpath use cmdpath for entropy commands [/etc/prngd.conf] -s or --seedfile seedpath use seedpath as seedfile [/etc/prngd-seed] -n or --no-seedfile no seedfile, keep pool in memory only -m or --mode mode use mode for sockets [0777] -k or --kill kill daemon on other side -v or --version print version and exit DESCRIPTION prngd is a daemon that provides the random number functionality on the NonStop system using either using local sockets or a tcpip port connection. The default port that SSH uses for port access is 790 to 793 and the default local socket is /dev/egd-pool. The ports 790 to 793 are against the localhost (127.0.0.1) and will use the define =TCPIP^PROCESS^NAME to get the currently defined TCPIP process stack name. The option tcp/ip:addr:port allows the random number generator to liston on specified address instead of the loopback address. System Reference Manual PRNGD(8)
NSK-SSH V2.4
Page 23
March 31, 2008
STARTING DAEMON To start the prngd program using localhost port 708: prngd -gpri=144 tcp/localhost:790 To start the prngd program using tcp/ip option port 708: prngd -gpri=144 tcp/ip:192.168.1.210:790 To start the prngd program using the local socket /dev/egd-pool prngd -gpri=170 /dev/egd-pool The SSH program will attempt to use the localhost ports first and then try the local socket next. You can configure one prngd program to service both tcp and local socket if you like: prngd /dev/egd-pool tcp/localhost:790 tcp/localhost:791 But you may want to configure the localhost port 790 as the primary and 791 or /dev/egd-pool as the backup. If you are running P/TCPIP then you can have more than one random number generator using only port 790. If you are using using regular TCPIP, then a primary and back is good choice. run -cpu=0 -gpri=144 run -cpu=1 -gpri=144 or run -cpu=1 -gpri=170 prngd /dev/egd-pool You could run the TCPIP random number generator port 790 on cpu 0 and port 791 or the Local Socket random number generator on cpu 1. If any one of the CPU's fail, you will still have a random number generator available on the system. As a note, if there is not a random number generator available, most of SSH functions will not work. If you are using Parallel TCPIP with round robin, then you can start up multiple random number generators using the same port number to spead the laod to multiple CPU's. run -cpu=0 -gpri=144 prngd tcp/localhost:790 run -cpu=1 -gpri=144 prngd tcp/localhost:790 This will CPU 1 and CPU 0 the load of the random number generator. prngd tcp/localhost:790 prngd tcp/localhost:791
NSK-SSH V2.4
Page 24
March 31, 2008
STOPPING DAEMON You can stop the prngd daemon with the following command: If TCPIP: prngd --kill tcp/localhost:790 If Local Socket prngd --kill /dev/egd-pool
Or just use the kill command. SEEDING DAEMON The random number generator software is locate in the /usr/local/random directory. In the directory /usr/local/random/etc there is a file call prngd-seed. This file is 1 megabyte random number that can be used a the first seed when starting prngd for the first time. The current seed in the /etc directory is base on this file, but has been written over by the prngd program. It has been found that if prngd is not properly seed, it will stop generating random numbers. To use this seed file: cp /usr/local/random/etc/prngd-seed /etc/prngd-seed and restart the program. PERFORMANCE We have notice that the random number generator using TCPIP requires less cpu overhead than one using the local sockets interface. The program also produces an EMS message when closing a connection. NOTES prngd runs as a named process. Do not use /G/ directories for entropy generation. This can result in system performance problems and cause the random number generator to take excessive cpu time. prngd will not return any random information if it runs out of entropy. This will result in processes waiting on this information. SSH has been program to try 5 times and then will go to the next generator viable and try 5 times also. If this fails the program executing will abend.
NSK-SSH V2.4
Page 25
March 31, 2008
NSK-SSH V2.4
Page 26
March 31, 2008
ipssh
IPSSH(1) NAME IPSSH SYNOPSIS ipssh - TCPIP Multiplexer for SSH IPSSH IPSSH(1)
[-remote port] [-ports no] [-burst rate] [-interval rate] [-debug] [-wait no] [-D]
DESCRIPTION The ipssh programs allows you to distribute ip traffic to multiple ports on a system. This much like the parrallel tcpip product execpt that it will exeucte on any Nonstop system. Ipssh listens on port 22 and distributes its ip load to port 700 and 701. If you have more than two cpus, it is possible to distribute load to those also. Ipssh only forwards to the local 127.0.0.1 interface. The options are as follows: -remote port is the remote port to forward the connection. This defaults to 700. -ports number is the number of ports to connect to. Each port is of set by one. (e.g. port 700,701,702,..,etc). The default is 2. connection rate for burst conditions. This is the number of connections that can be accepted during the interval. The default is 5.
-burst
rate
-interval rate interval in milliseconds. (1 = .01 seconds) The default is 100 or 1 sec. -instance no the instance of ipssh processes. If you have more one ipssh process on the system, you need to set this to number. The default is zero. this is maximumu number of ipssh processes that will be allowed exist at one time. When this maximum reach all, the main ipssh process wait until a child completes before continuing. The default is 25. displays debuging information. time to wait before checking if you can bind to the port. The default is 30 seconds. If you enter 0, the time is set to 1 second
-maxload no
-debug -wait no
NSK-SSH V2.4
Page 27
March 31, 2008
-qlen no
number of connection to listen for on the port. The default is 5. indicates that ipssh is to be run waited, so it will not fork and create a process name
-D
To change the default TCPIP process from $ZTC0, you must change the define =TCPIP^PROCESS^NAME.The primary process name is /G/ISX ($ISX) and the backup process name is /G/ISY ($ISY).
NSK-SSH V2.4
Page 28
March 31, 2008
ssh-keygen
SSH-KEYGEN(1) NAME ssh-keygen - authentication key generation, management and conversion SYNOPSIS ssh-keygen [-q] [-b bits] [-t type] [-N new_passphrase] [-C comment] [-f output_keyfile] ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile] ssh-keygen -i [-f input_keyfile] ssh-keygen -e [-f input_keyfile] ssh-keygen -y [-f input_keyfile] ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile] ssh-keygen -l [-f input_keyfile] ssh-keygen -B [-f input_keyfile] ssh-keygen -D reader ssh-keygen -U reader [-f input_keyfile] DESCRIPTION ssh-keygen generates, manages and converts authentication keys for ssh(1). ssh-keygen defaults to generating a RSA1 key for use by SSH prottocol version 1. Specifying the -t option instead creates a key for use by SSH protocol version 2. Normally each user wishing to use SSH with RSA or DSA authentication runs this once to create the authentication key in $HOME/.ssh/identity, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa. Additionally, the system administrator may use this to generate host keys, as seen in /etc/rc. Normally this program generates the key and asks for a file in which to store the private key. The public key is stored in a file with the same name but ``.pub'' appended. The program also asks for a passphrase. The passphrase may be empty to indicate no passphrase (host keys must have an empty passphrase), or it may be a string of arbitrary length. Good passphrases are 10-30 characters long and are not simple sentences or otherwise easily guessable (English prose has only 1-2 bits of entropy per character, and provides very bad passphrases). The passphrase can be changed later by using the -p option. There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key must be generated and copied to the corresponding public key to other machines. For RSA1 keys, there is also a comment field in the key file that is only System Reference Manual SSH-KEYGEN(1)
NSK-SSH V2.4
Page 29
March 31, 2008
for convenience to the user to help identify the key. The comment can tell what the key is for, or whatever is useful. The comment is initialized to `ùser@host'' when the key is created, but can be changed using the -c option. After a key is generated, instructions below detail where the keys should be placed to be activated. The options are as follows: -b bits Specifies the number of bits in the key to create. Minimum is 512 bits. Generally 1024 bits is considered sufficient, and key sizes above that no longer improve security but make things slower. The default is 1024 bits. -c Requests changing the comment in the private and public key files. The program will prompt for the file containing the private keys, for the passphrase if the key has one, and for the new comment. -e This option will read a private or public OpenSSH key file and print the key in a `SECSH Public Key File Format' to stdout. This option allows exporting keys for use by several commercial SSH implementations.
-f filename Specifies the filename of the key file. -i This option will read an unencrypted private (or public) key file in SSH2-compatible format and print an OpenSSH compatible private (or public) key to stdout. ssh-keygen also reads the `SECSH Public Key File Format'. This option allows importing keys from several commercial SSH implementations. Show fingerprint of specified private or public key file. Requests changing the passphrase of a private key file instead of creating a new private key. The program will prompt for the file containing the private key, for the old passphrase, and twice for the new passphrase. Silence ssh-keygen. Used by /etc/rc when creating a new key. This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.
-l -p
-q -y
-t type
NSK-SSH V2.4
Page 30
March 31, 2008
Specifies the type of the key to create. The possible values are ``rsa1'' for protocol version 1 and ``rsa'' or ``dsa'' for protocol version 2. The default is ``rsa1''. -B Show the bubblebabble digest of specified private or public key file.
-C comment Provides the new comment. -D reader Download the RSA public key stored in the smartcard in reader. -N new_passphrase Provides the new passphrase. -P passphrase Provides the (old) passphrase. -U reader Upload an existing RSA private key into the smartcard in reader. FILES $HOME/.ssh/identity Contains the protocol version 1 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessed by ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made. $HOME/.ssh/identity.pub Contains the protocol version 1 RSA public tion. The contents of this file should be $HOME/.ssh/authorized_keys on all machines to log in using RSA authentication. There contents of this file secret. $HOME/.ssh/id_dsa Contains the protocol version 2 DSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessed by ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.
key for authenticaadded to where the user wishes is no need to keep the
NSK-SSH V2.4
Page 31
March 31, 2008
$HOME/.ssh/id_dsa.pub Contains the protocol version 2 DSA public key for authentication. The contents of this file should be added to $HOME/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret. $HOME/.ssh/id_rsa Contains the protocol version 2 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessed by ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made. $HOME/.ssh/id_rsa.pub Contains the protocol version 2 RSA public key for authentication. The contents of this file should be added to $HOME/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret. DEFINES SUPPORTED This program supports the TCPIP^PROCESS^NAME define. This will allow you to execute the software against other tcpip process stacks in addition to the standard process stack($ZTCO).
SEE ALSO ssh(1),
ssh-add(1),
ssh-agent(1),
sshd(8)
J. Galbraith, and R. Thayer, SECSH Public Key File Format, draft-ietfsecsh-publickeyfile-01.txt, March 2001, work in progress material.
NSK-SSH V2.4
Page 32
March 31, 2008
ssh-keyscan
SSH-KEYSCAN(1) NAME ssh-keyscan - gather ssh public keys SYNOPSIS ssh-keyscan [-v46] [-p port] [-T timeout] [-t type] [-f file] [host | addrlist namelist] [...] DESCRIPTION ssh-keyscan is a utility for gathering the public ssh host keys of a number of hosts. It was designed to aid in building and verifying ssh_known_hosts files. ssh-keyscan provides a minimal interface suitable for use by shell and perl scripts. ssh-keyscan uses non-blocking socket I/O to contact as many hosts as possible in parallel, so it is very efficient. The keys from a domain of 1,000 hosts can be collected in tens of seconds, even when some of those hosts are down or do not run ssh. For scanning, one does not need login access to the machines that are being scanned, nor does the scanning process involve any encryption. The options are as follows: -p port Port to connect to on the remote host. -T timeout Set the timeout for connection attempts. If timeout seconds have elapsed since a connection was initiated to a host or since the last time anything was read from that host, then the connection is closed and the host in question considered unavailable. Default is 5 seconds. -t type Specifies the type of the key to fetch from the scanned hosts. The possible values are ``rsa1'' for protocol version 1 and ``rsa'' or ``dsa'' for protocol version 2. Multiple values may be specified by separating them with commas. The default is ``rsa1''. -f filename Read hosts or addrlist namelist pairs from this file, one per line. If - is supplied instead of a filename, ssh-keyscan will read hosts or addrlist namelist pairs from the standard input. System Reference Manual SSH-KEYSCAN(1)
NSK-SSH V2.4
Page 33
March 31, 2008
-v
Verbose mode. Causes ssh-keyscan to print debugging messages about its progress. Forces ssh-keyscan to use IPv4 addresses only. Forces ssh-keyscan to use IPv6 addresses only.
-4 -6
DEFINES SUPPORTED This program supports the TCPIP^PROCESS^NAME define. This will allow you to execute the software against other tcpip process stacks in addition to the standard process stack($ZTCO). SECURITY If a ssh_known_hosts file is constructed using ssh-keyscan without verifying the keys, users will be vulnerable to attacks. On the other hand, if the security model allows such a risk, ssh-keyscan can help in the detection of tampered keyfiles or man in the middle attacks which have begun after the ssh_known_hosts file was created. EXAMPLES Print the rsa1 host key for machine hostname: ssh-keyscan hostname Find all hosts from the file ssh_hosts which have new or different keys from those in the sorted file ssh_known_hosts: ssh-keyscan -t rsa,dsa -f ssh_hosts | \ sort -u - ssh_known_hosts | diff ssh_known_hosts FILES Input format: 1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4 Output format for rsa1 keys: host-or-namelist bits exponent modulus Output format for rsa and dsa keys: host-or-namelist keytype base64-encoded-key Where keytype is either ``ssh-rsa'' or ``ssh-dsa''. /etc/ssh/ssh_known_hosts
NSK-SSH V2.4
Page 34
March 31, 2008
BUGS It generates "Connection closed by remote host" messages on the consoles of all the machines it scans if the server is older than version 2.9. This is because it opens a connection to the ssh port, reads the public key, and drops the connection as soon as it gets the key. SEE ALSO ssh(1),
sshd(8)
AUTHORS David Mazieres <dm@lcs.mit.edu> wrote the initial version, and Wayne Davison <wayned@users.sourceforge.net> added support for protocol version 2.
NSK-SSH V2.4
Page 35
March 31, 2008
NSK-SSH V2.4
Page 36
March 31, 2008
sshd
SSHD(8) NAME sshd - NSK-SSH SSH daemon SYNOPSIS sshd [-deiqtD46] [-b bits] [-f config_file] [-g login_grace_time] [-h host_key_file] [-k key_gen_time] [-p port] [-u len] DESCRIPTION sshd (SSH Daemon) is the daemon program for ssh(1). Together these programs replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. The programs are intended to be as easy to install and use as possible. sshd is the daemon that listens for connections from clients. It is normally started at load time from /usr/local/ssh/. It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange. This implementation of sshd supports both SSH protocol version 1 and 2 simultaneously. sshd works as follows. SSH protocol version 1 Each host has a host-specific RSA key (normally 1024 bits) used to identify the host. Additionally, when the daemon starts, it generates a server RSA key (normally 768 bits). This key is normally regenerated every hour if it has been used, and is never stored on disk. Whenever a client connects the daemon responds with its public host and server keys. The client compares the RSA host key against its own database to verify that it has not changed. The client then generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the server. Both sides then use this random number as a session key which is used to encrypt all further communications in the session. The rest of the session is encrypted using a conventional cipher, currently Blowfish or 3DES, with 3DES being used by default. The client selects the encryption algorithm to use from those offered by the server. Next, the server and the client enter an authentication dialog. The client tries to authenticate itself using .rhosts authentication, .rhosts authentication combined with RSA host authentication, RSA challenge-response authentication, or password based authentication. System Manager's Manual SSHD(8)
NSK-SSH V2.4
Page 37
March 31, 2008
Rhosts authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file if desired. System security is not improved unless rshd(8), rlogind(8), and rexecd(8) are disabled (thus completely disabling rlogin(1) and rsh(1) into the machine). SSH protocol version 2 Version 2 works similarly: Each host has a host-specific key (RSA or DSA) used to identify the host. However, when the daemon starts, it does not generate a server key. Forward security is provided through a DiffieHellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher, currently 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, or 256 bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-sha1 or hmac-md5). Protocol version 2 provides a public key based user (PubkeyAuthentication) or client host (HostbasedAuthentication) authentication method, conventional password authentication and challenge response based methods. Command execution and data forwarding If the client successfully authenticates itself, a dialog for preparing the session is entered. At this time the client may request things like allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP connections, or forwarding the authentication agent connection over the secure channel. Finally, the client either requests a shell or execution of a command. The sides then enter session mode. In this mode, either side may send data at any time, and such data is forwarded to/from the shell or command on the server side, and the user terminal in the client side. When the user program terminates and all forwarded X11 and other connections have been closed, the server sends command exit status to the client, and both sides exit. sshd can be configured using command-line options or a configuration file. Command-line options override values specified in the configuration file. sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name it was started as, i.e., /usr/local/ssh/sbin/sshd.
NSK-SSH V2.4
Page 38
March 31, 2008
The options are as follows: -b bits Specifies the number of bits in the ephemeral protocol version 1 server key (default 768). -d Debug mode. The server sends verbose debug output to the system log, and does not put itself in the background. The server also will not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3. When this option is specified, sshd will send the output to the standard error instead of the system log.
-e
-f configuration_file Specifies the name of the configuration file. The default is /etc/ssh/sshd_config. sshd refuses to start if there is no configuration file. -g login_grace_time Gives the grace time for clients to authenticate themselves (default 600 seconds). If the client fails to authenticate the user within this many seconds, the server disconnects and exits. A value of zero indicates no limit. -h host_key_file Specifies the file from which the host key is read (default /etc/ssh/ssh_host_key). This option must be given if sshd is not run as root (as the normal host file is normally not readable by any one but root). It is possible to have multiple host key files for the different protocol versions and host key algorithms. -i Specifies that sshd is being run from inetd. sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of seconds. Clients would have to wait too long if the key was regenerated every time. However, with small key sizes (e.g., 512) using sshd from inetd may be feasible.
-k key_gen_time Specifies how often the ephemeral protocol version 1 server key is regenerated (default 3600 seconds, or one hour). The motivation for regenerating the key fairly often is that the key is not stored anywhere, and after about an hour, it becomes impossible to recover the key for decrypting intercepted communications even if the machine is cracked into or physically seized. A value of
NSK-SSH V2.4
Page 39
March 31, 2008
zero indicates that the key will never be regenerated. -p port Specifies the port on which the server listens for connections (default 22). -q Quiet mode. Nothing is sent to the system log. Normally the beginning, authentication, and termination of each connection is logged. Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change. This option is used to specify the size of the field in the utmp structure that holds the remote host name. If the resolved host name is longer than len, the dotted decimal value will be used instead. This allows hosts with very long host names that overflow this field to still be uniquely identified. Specifying -u0 indicates that only dotted decimal addresses should be put into the utmp file. -u0 is also be used to prevent sshd from making DNS requests unless the authentication mechanism or configuration requires it. Authentication mechanisms that may require DNS include RhostsAuthentication, RhostsRSAAuthentication, HostbasedAuthentication and using a from="pattern-list" option in a key file. When this option is specified sshd will not detach and does not become a daemon. This allows easy monitoring of sshd. Forces sshd to use IPv4 addresses only. Forces sshd to use IPv6 addresses only.
-t
-u len
-D
-4 -6
RANDOM NUMBER GENERATOR SSHD requires the use of a random number generator for its operation. It currently looks on the ports of 790 to 793 of address 127.0.0.1 for a random number generator. If it does not find this, it then looks for the name pipe /dev/egd-pool. If it does not find that, it fails the random number request. TCP_RND_ADDR TCP_RND_PORT0 TCP_RND_PORT1 These environment variables allow you to change the starting and ending port and the default IP address to access for the random number generator request. In general, you need at least one
NSK-SSH V2.4
Page 40
March 31, 2008
generator for each TCPIP stack that SSHD is running on. If your system is heavly used for SSH request, then you might need more than one and you can assign the extra ones to port 791 to 793. TELNET ISOLATION For those of you that want to stop all of your telnet and ftp processes on the system, we have a solution that allows you to do this execpt for an isolated TCPIP stack with telnet running on the loop back port. The idea is the run the TCPIP process on your systems that is not attached to any hardware and only use the loop back port. This #LOOP0 is started and a TELSRV process is started against this and no listner process. With this configuration, our SSHD process can use this isolated stack for telnet access. To use this feature, you need specify the following environment variable before starting the SSHD process: TCPIP_TELNET_STACK This is equal to the process name of the TCPIP stack that is isolated. In our script call start_sshd_2cpu_2stack.sh, we use the TCPIP process name $ztc99, so this variable is set to: export TCPIP_TELNET_STACK=\$ztc99 ZZKRN PERSISTANT PROCESS SETUP We have included in this setup the install directory the scripts for setting up the SSHD software using the standard TCPIP V4 or V6 software using the ipssh, prngd, and sshd process running as persistant processes in the ZZKRN file. What you need to do this, is the following: cd /usr/local/ssh/install/zzkrn cp ZZKRNSD.100 /G/system/nosubvol/ZZKRNSD gtacl> <logon tacl> volume /G/system/nosubvol fup alter zzkrnsd,code 100 run zzkrnsd, $*.*.*,vol $system This will install the subvolume $system.zzkrnsd on your system. Now, you only need to install the files in the zzkrn subsystem. Note that you need to be root or super.super to do this and
NSK-SSH V2.4
Page 41
March 31, 2008
you need to change your /etc/sshd.config file to listen on port 127.0.0.1. This is the ListenAddress configuration line. scf> assume proces $zzkrn scf> volume $system.zzkrnsd The obey files adds the process service and starts up the service. scf> scf> scf> scf> scf> scf> obey obey obey obey obey obey ranztc0a ranztc0b sdztc0a sdztc0b ipztc00a ipztc00b start start start start start start up up up up up up cpu cpu cpu cpu cpu cpu 0 1 0 1 0 1 random generator port 790 random generator port 791 sshd process port 700 sshd process port 701 ipssh1 process port 22 ipssh1 process port 22
Now check the status of the serivces scf> status They should all be running. In the zzkrn subsystem, you have added the following servies: $ZZKRN.#IPSSH-ZTC00A $ZZKRN.#RANDOM-ZTC00A $ZZKRN.#SSHD-ZTC00A $ZZKRN.#IPSSH-ZTC00B $ZZKRN.#RANDOM-ZTC00B $ZZKRN.#SSHD-ZTC00B
if you want to stop a service, all you need do is the following: scf> scf> scf> scf> scf> scf> scf> assume process $zzkrn abort #IPSSH-ZTC00A abort #IPSSH-ZTC00B abort #SSHD-ZTC00A abort #SSHD-ZTC00B abort #RANDOM-ZTC00A abort #RANDOM-ZTC00B
The purpose of putting the files under this subsystem is to restart the process if one every stops or a CPU dies. CONFIGURATION FILE sshd reads configuration data from /etc/ssh/sshd_config (or the file specified with -f on the command line). The file contains keywordargument pairs, one per line. Lines starting with `#' and empty lines are interpreted as comments.
NSK-SSH V2.4
Page 42
March 31, 2008
The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive): AFSTokenPassing Specifies whether an AFS token may be forwarded to the server. Default is ``yes''. AllowGroups This keyword can be followed by a list of group names, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. `*' and `?' can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default login is allowed regardless of the group list. AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ``yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. AllowUsers This keyword can be followed by a list of user names, separated by spaces. If specified, login is allowed only for users names that match one of the patterns. `*' and `?' can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default login is allowed regardless of the user name. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. AuthorizedKeysFile Specifies the file that contains the public keys that can be used for user authentication. AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection set-up. The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is ``.ssh/authorized_keys'' Banner In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. The contents of the specified file are sent to the remote user before authentication is allowed. This option is only available for protocol version 2.
NSK-SSH V2.4
Page 43
March 31, 2008
ChallengeResponseAuthentication Specifies whether challenge response authentication is allowed. All authentication styles from login.conf(5) are supported. The default is ``yes''. Ciphers Specifies the ciphers allowed for protocol version 2. Multiple ciphers must be comma-separated. The default is `àes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour.'' ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only. ClientAliveCountMax Sets the number of client alive messages (see above) which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from Keepalive (below). The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by Keepalive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. The default value is 3. If ClientAliveInterval (above) is set to 15, and ClientAliveCountMax is left at the default, unresponsive ssh clients will be disconnected after approximately 45 seconds. DenyGroups This keyword can be followed by a number of group names, separated by spaces. Users whose primary group or supplementary group list matches one of the patterns aren't allowed to log in. `*' and `?' can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default login is allowed regardless of the group list. DenyUsers This keyword can be followed by a number of user names, separated by spaces. Login is disallowed for user names that match one of the patterns. `*' and `?' can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default login is allowed regardless of the user
NSK-SSH V2.4
Page 44
March 31, 2008
name. GatewayPorts Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd binds remote port forwardings to the loopback addresss. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should bind remote port forwardings to the wildcard address, thus allowing remote hosts to connect to forwarded ports. The argument must be ``yes'' or ``no''. The default is ``no''. HostbasedAuthentication Specifies whether rhosts or /etc/hosts.equiv authentication together with successful public key client host authentication is allowed (hostbased authentication). This option is similar to RhostsRSAAuthentication and applies to protocol version 2 only. The default is ``no''. HostKey Specifies the file containing the private host keys (default /etc/ssh/ssh_host_key) used by SSH protocol versions 1 and 2. Note that sshd will refuse to use a file if it is group/world-accessible. It is possible to have multiple host key files. ``rsa1''keys are used for version 1 and ``dsa'' or ``rsa'' are used for version 2 of the SSH protocol. IgnoreRhosts Specifies that .rhosts and .shosts files will not be used in RhostsAuthentication, RhostsRSAAuthentication or HostbasedAuthentication. /etc/hosts.equiv and /etc/ssh/shosts.equiv are still used. The default is ``yes''. IgnoreUserKnownHosts Specifies whether sshd should ignore the user's $HOME/.ssh/known_hosts during RhostsRSAAuthentication or HostbasedAuthentication. The default is ``no''. KeepAlive Specifies whether the system should send keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if keepalives are not sent, sessions may hang indefinitely on the server, leaving ``ghost'' users and consuming server resources.
NSK-SSH V2.4
Page 45
March 31, 2008
The default is ``yes'' (to send keepalives), and the server will notice if the network goes down or the client host reboots. This avoids infinitely hanging sessions. To disable keepalives, the value should be set to ``no'' in both the server and the client configuration files. KerberosAuthentication Specifies whether Kerberos authentication is allowed. This can be in the form of a Kerberos ticket, or if PasswordAuthentication is yes, the password provided by the user will be validated through the Kerberos KDC. To use this option, the server needs a Kerberos servtab which allows the verification of the KDC's identity. Default is ``yes''. KerberosOrLocalPasswd If set then if password authentication through Kerberos fails then the password will be validated via any additional local mechanism such as /etc/passwd. Default is ``yes''. KerberosTgtPassing Specifies whether a Kerberos TGT may be forwarded to the server. Default is ``no'', as this only works when the Kerberos KDC is actually an AFS kaserver. KerberosTicketCleanup Specifies whether to automatically destroy the user's ticket cache file on logout. Default is ``yes''. KeyRegenerationInterval In protocol version 1, the ephemeral server key is automatically regenerated after this many seconds (if it has been used). The purpose of regeneration is to prevent decrypting captured sessions by later breaking into the machine and stealing the keys. The key is never stored anywhere. If the value is 0, the key is never regenerated. The default is 3600 (seconds). ListenAddress Specifies the local addresses sshd should listen on. ing forms may be used: ListenAddress host|IPv4_addr|IPv6_addr ListenAddress host|IPv4_addr:port ListenAddress [host|IPv6_addr]:port If port is not specified, sshd will listen on the address and all prior Port options specified. The default is to listen on all local addresses. Multiple ListenAddress options are permitted. Ad-
The follow-
NSK-SSH V2.4
Page 46
March 31, 2008
ditionally, any Port options must precede this option for non port qualified addresses. LoginGraceTime The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 600 (seconds). LogLevel Gives the verbosity level that is used when logging messages from sshd. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. The default is INFO. Logging with level DEBUG violates the privacy of users and is not recommended. MACs Specifies the available MAC (message authentication code) algorithms. The MAC algorithm is used in protocol version 2 for data integrity protection. Multiple algorithms must be comma-separated. The default is ``hmac-md5,hmac-sha1,hmac-ripemd160,hmacsha1-96,hmac-md5-96''.
MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10. Alternatively, random early drop can be enabled by specifying the three colon separated values ``start:rate:full'' (e.g., "10:30:60"). sshd will refuse connection attempts with a probability of ``rate/100'' (30%) if there are currently ``start'' (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches ``full'' (60). PAMAuthenticationViaKbdInt Specifies whether PAM challenge response authentication is allowed. This allows the use of most PAM challenge response authentication modules, but it will allow password authentication regardless of whether PasswordAuthentication is disabled. The default is ``no''. PasswordAuthentication Specifies whether password authentication is allowed. fault is ``yes''.
The de-
PermitEmptyPasswords When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The default is ``no''.
NSK-SSH V2.4
Page 47
March 31, 2008
PermitRootLogin Specifies whether root can login using ssh(1). The argument must be ``yes'', ``without-password'', ``forced-commands-only'' or ``no''. The default is ``yes''. If this option is set to ``without-password'' password authentication is disabled for root. If this option is set to ``forced-commands-only'' root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root. If this option is set to ``no'' root is not allowed to login. PidFile Specifies the file that contains the process identifier of the sshd daemon. The default is /var/run/sshd.pid. Port Specifies the port number that sshd listens on. The default is 22. Multiple options of this type are permitted. See also ListenAddress.
PrintLastLog Specifies whether sshd should print the date and time when the user last logged in. The default is ``yes''. PrintMotd Specifies whether sshd should print /etc/motd when a user logs in interactively. (On some systems it is also printed by the shell,
/etc/profile, or equivalent.) Protocol
The default is ``yes''.
Specifies the protocol versions sshd should support. The possible values are ``1'' and ``2''. Multiple versions must be commaseparated. The default is ``2,1''. PubkeyAuthentication Specifies whether public key authentication is allowed. The default is ``yes''. Note that this option applies to protocol version 2 only. ReverseMappingCheck Specifies whether sshd should try to verify the remote host name and check that the resolved host name for the remote IP address
NSK-SSH V2.4
Page 48
March 31, 2008
maps back to the very same IP address.
The default is ``no''.
RhostsAuthentication Specifies whether authentication using rhosts or /etc/hosts.equiv files is sufficient. Normally, this method should not be permitted because it is insecure. RhostsRSAAuthentication should be used instead, because it performs RSA-based host authentication in addition to normal rhosts or /etc/hosts.equiv authentication. The default is ``no''. This option applies to protocol version 1 only. RhostsRSAAuthentication Specifies whether rhosts or /etc/hosts.equiv authentication together with successful RSA host authentication is allowed. The default is ``no''. This option applies to protocol version 1 only. RSAAuthentication Specifies whether pure RSA authentication is allowed. The default is ``yes''. This option applies to protocol version 1 only. ServerKeyBits Defines the number of bits in the ephemeral protocol version 1 server key. The minimum value is 512, and the default is 768. StrictModes Specifies whether sshd should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is ``yes''. Subsystem Configures an external subsystem (e.g., file transfer daemon). Arguments should be a subsystem name and a command to execute upon subsystem request. The command sftp-server(8) implements the ``sftp'' file transfer subsystem. By default no subsystems are defined. Note that this option applies to protocol version 2 only. SyslogFacility Gives the facility code that is used when logging messages from sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH. UseLogin Specifies whether login(1) is used for interactive login sessions. The default is ``no''. Note that login(1) is never used
NSK-SSH V2.4
Page 49
March 31, 2008
for remote command execution. Note also, that if this is enabled, X11Forwarding will be disabled because login(1) does not know how to handle xauth(1) cookies. X11DisplayOffset Specifies the first display number available for sshd's X11 forwarding. This prevents sshd from interfering with real X11 servers. The default is 10. X11Forwarding Specifies whether X11 forwarding is permitted. The default is ``no''. Note that disabling X11 forwarding does not improve security in any way, as users can always install their own forwarders. X11 forwarding is automatically disabled if UseLogin is enabled. XAuthLocation Specifies the location of the xauth(1) program. /usr/bin/X11/xauth. Time Formats sshd command-line arguments and configuration file options that specify time may be expressed using a sequence of the form: time[qualifier], where time is a positive integer value and qualifier is one of the following: <none> s | S m | M h | H d | D w | W seconds seconds minutes hours days weeks
The default is
Each member of the sequence is added together to calculate the total time value. Time format examples: 600 10m 1h30m 600 seconds (10 minutes) 10 minutes 1 hour 30 minutes (90 minutes)
NSK-SSH V2.4
Page 50
March 31, 2008
LOGIN PROCESS When a user successfully logs in, sshd does the following: 1. If the login is on a tty, and no command has been specified, prints last login time and /etc/motd (unless prevented in the configuration file or by $HOME/.hushlogin; see the FILES section). If the login is on a tty, records login time. Checks /etc/nologin; if it exists, prints contents and quits (unless root). Changes to run with normal user privileges. Sets up basic environment. Reads $HOME/.ssh/environment if it exists. Changes to user's home directory. If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth. The ``rc'' files are given the X11 authentication protocol and cookie in standard input. Runs user's shell or command.
2. 3.
4. 5. 6. 7. 8.
9.
AUTHORIZED_KEYS FILE FORMAT $HOME/.ssh/authorized_keys is the default file that lists the public keys that are permitted for RSA authentication in protocol version 1 and for public key authentication (PubkeyAuthentication) in protocol version 2. AuthorizedKeysFile may be used to specify an alternative file. Each line of the file contains one key (empty lines and lines starting with a `#' are ignored as comments). Each RSA public key consists of the following fields, separated by spaces: options, bits, exponent, modulus, comment. Each protocol version 2 public key consists of: options, keytype, base64 encoded key, comment. The options fields are optional; its presence is determined by whether the line starts with a number or not (the option field never starts with a number). The bits, exponent, modulus and comment fields give the RSA key for protocol version 1; the comment field is not used for anything (but may be convenient for the user to identify the key). For protocol version 2 the keytype is ``ssh-dss'' or ``ssh-rsa''. Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). You don't want to type them in; instead, copy the identity.pub, id_dsa.pub or the id_rsa.pub file and
NSK-SSH V2.4
Page 51
March 31, 2008
edit it. The options (if present) consist of comma-separated option specifications. No spaces are permitted, except within double quotes. The following option specifications are supported (note that option keywords are case-insensitive): from="pattern-list" Specifies that in addition to RSA authentication, the canonical name of the remote host must be present in the comma-separated list of patterns (`*' and `?' serve as wildcards). The list may also contain patterns negated by prefixing them with `!'; if the canonical host name matches a negated pattern, the key is not accepted. The purpose of this option is to optionally increase security: RSA authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key). command="command" Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If a 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash. This option might be useful to restrict certain RSA keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP/IP and/or X11 forwarding unless they are explicitly prohibited. Note that this option applies to shell, command or subsystem execution. environment="NAME=value" Specifies that the string is to be added to the environment when logging in using this key. Environment variables set this way override other default environment values. Multiple options of
this type are permitted. no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. This might be used, e.g., in connection with the command option.
NSK-SSH V2.4
Page 52
March 31, 2008
no-X11-forwarding Forbids X11 forwarding when this key is used for authentication. Any X11 forward requests by the client will return an error. no-agent-forwarding Forbids authentication agent forwarding when this key is used for authentication. no-pty Prevents tty allocation (a request to allocate a pty will fail).
permitopen="host:port" Limit local ``ssh -L'' port forwarding such that it may only connect to the specified host and port. IPv6 addresses can be specified with an alternative syntax: host/port. Multiple permitopen options may be applied separated by commas. No pattern matching is performed on the specified hostnames, they must be literal domains or addresses. Examples 1024 33 12121...312314325 ylo@foo.bar from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323 SSH_KNOWN_HOSTS FILE FORMAT The /etc/ssh/ssh_known_hosts, and $HOME/.ssh/known_hosts files contain host public keys for all known hosts. The global file should be prepared by the administrator (optional), and the per-user file is maintained automatically: whenever the user connects from an unknown host its key is added to the per-user file. Each line in these files contains the following fields: hostnames, bits, exponent, modulus, comment. The fields are separated by spaces. Hostnames is a comma-separated list of patterns ('*' and '?' act as wildcards); each pattern in turn is matched against the canonical host name (when authenticating a client) or against the user-supplied name (when authenticating a server). A pattern may also be preceded by `!' to indicate negation: if the host name matches a negated pattern, it is not accepted (by that line) even if it matched another pattern on the line. Bits, exponent, and modulus are taken directly from the RSA host key; they can be obtained, e.g., from /etc/ssh/ssh_host_key.pub. The optional comment field continues to the end of the line, and is not used.
NSK-SSH V2.4
Page 53
March 31, 2008
Lines starting with `#' and empty lines are ignored as comments. When performing host authentication, authentication is accepted if any matching line has the proper key. It is thus permissible (but not recommended) to have several lines or different host keys for the same names. This will inevitably happen when short forms of host names from different domains are put in the file. It is possible that the files contain conflicting information; authentication is accepted if valid information can be found from either file. Note that the lines in these files are typically hundreds of characters long, and you definitely don't want to type in the host keys by hand. Rather, generate them by a script or by taking /etc/ssh/ssh_host_key.pub and adding the host names at the front. Examples closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....= FILES /etc/ssh/sshd_config Contains configuration data for sshd. This file should be writable by root only, but it is recommended (though not necessary) that it be world-readable. /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key These three files contain the private parts of the host keys. These files should only be owned by root, readable only by root, and not accessible to others. Note that sshd does not start if this file is group/world-accessible. /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub, /etc/ssh/ssh_host_rsa_key.pub These three files contain the public parts of the host keys. These files should be world-readable but writable only by root. Their contents should match the respective private parts. These files are not really used for anything; they are provided for the convenience of the user so their contents can be copied to known hosts files. These files are created using ssh-keygen(1). /etc/ssh/moduli Contains Diffie-Hellman groups used for the "Diffie-Hellman Group Exchange". /var/run/sshd.pid Contains the process ID of the sshd listening for connections (if
NSK-SSH V2.4
Page 54
March 31, 2008
there are several daemons running concurrently for different ports, this contains the pid of the one started last). The content of this file is not sensitive; it can be world-readable. $HOME/.ssh/authorized_keys Lists the public keys (RSA or DSA) that can be used to log into the user's account. This file must be readable by root (which may on some machines imply it being world-readable if the user's home directory resides on an NFS volume). It is recommended that it not be accessible by others. The format of this file is described above. Users will place the contents of their identity.pub, id_dsa.pub and/or id_rsa.pub files into this file, as described in ssh-keygen(1). /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts These files are consulted when using rhosts with RSA host authentication or protocol version 2 hostbased authentication to check the public key of the host. The key must be listed in one of these files to be accepted. The client uses the same files to verify that it is connecting to the correct remote host. These files should be writable only by root/the owner. /etc/ssh/ssh_known_hosts should be world-readable, and $HOME/.ssh/known_hosts can but need not be world-readable. /etc/nologin If this file exists, sshd refuses to let anyone except root log in. The contents of the file are displayed to anyone trying to log in, and non-root connections are refused. The file should be world-readable. /etc/hosts.allow, /etc/hosts.deny If compiled with LIBWRAP support, tcp-wrappers access controls may be defined here as described in hosts_access(5). $HOME/.rhosts This file contains host-username per line. The given user on the to log in without password. The rshd. The file must be writable mended that it not be accessible
pairs, separated by a space, one corresponding host is permitted same file is used by rlogind and only by the user; it is recomby others.
If is also possible to use netgroups in the file. Either host or user name may be of the form +@groupname to specify all hosts or all users in the group. $HOME/.shosts For ssh, this file is exactly the same as for .rhosts. However, this file is not used by rlogin and rshd, so using this permits
NSK-SSH V2.4
Page 55
March 31, 2008
access using SSH only. /etc/hosts.equiv This file is used during .rhosts authentication. In the simplest form, this file contains host names, one per line. Users on those hosts are permitted to log in without a password, provided they have the same user name on both machines. The host name may also be followed by a user name; such users are permitted to log in as any user on this machine (except root). Additionally, the syntax ``+@group'' can be used to specify netgroups. Negated entries start with `-'. If the client host/user is successfully matched in this file, login is automatically permitted provided the client and server user names are the same. Additionally, successful RSA host authentication is normally required. This file must be writable only by root; it is recommended that it be world-readable. Warning: It is almost never a good idea to use user names in hosts.equiv. Beware that it really means that the named user(s) can log in as anybody, which includes bin, daemon, adm, and other accounts that own critical binaries and directories. Using a user name practically grants the user root access. The only valid use for user names that I can think of is in negative entries. Note that this warning also applies to rsh/rlogin. /etc/ssh/shosts.equiv This is processed exactly as /etc/hosts.equiv. However, this file may be useful in environments that want to run both rsh/rlogin and ssh. $HOME/.ssh/environment This file is read into the environment at login (if it exists). It can only contain empty lines, comment lines (that start with `#'), and assignment lines of the form name=value. The file should be writable only by the user; it need not be readable by anyone else. $HOME/.ssh/rc If this file exists, it is run with /bin/sh after reading the environment files but before starting the user's shell or command. If X11 spoofing is in use, this will receive the "proto cookie" pair in standard input (and DISPLAY in environment). This must call xauth(1) in that case. The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environ-
NSK-SSH V2.4
Page 56
March 31, 2008
ment. This file will probably contain some initialization code followed by something similar to: if read proto cookie; then echo add $DISPLAY $proto $cookie | xauth -q fi If this file does not exist, /etc/ssh/sshrc is run, and if that does not exist either, xauth is used to store the cookie. This file should be writable only by the user, and need not be readable by anyone else. /etc/ssh/sshrc Like $HOME/.ssh/rc. This can be used to specify machine-specific login-time initializations globally. This file should be writable only by root, and should be world-readable.
SEE ALSO scp(1), sftp(1), ssh(1), login.conf(5), moduli(5),
ssh-add(1), ssh-agent(1), sftp-server(8)
ssh-keygen(1),
NSK-SSH V2.4
Page 57
March 31, 2008
NSK-SSH V2.4
Page 58
March 31, 2008
sftp-server
SFTP-SERVER(8) NAME sftp-server - SFTP server subsystem SYNOPSIS sftp-server DESCRIPTION sftp-server is a program that speaks the server side of SFTP protocol to stdout and expects client requests from stdin. sftp-server is not intended to be called directly, but from sshd(8) using the Subsystem option. See sshd(8) for more information. DEFINES SUPPORTED This program supports the TCPIP^PROCESS^NAME define. This will allow you to execute the software against other tcpip process stacks in addition to the standard process stack($ZTCO). SEE ALSO sftp(1), System Manager's Manual SFTP-SERVER(8)
ssh(1),
sshd(8)
T. Ylonen, and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secshfilexfer-00.txt, January 2001, work in progress material. AUTHORS Markus Friedl <markus@openbsd.org> HISTORY sftp-server first appeared in OpenBSD 2.8 .
NSK-SSH V2.4
Page 59
March 31, 2008
NSK-SSH V2.4
Page 60
March 31, 2008
sftp-server-guardian
SFTP-SERVER(8) NAME sftp-server-guardian - SFTP server subsystem for guardian access SYNOPSIS sftp-server-guardian DESCRIPTION sftp-server-guardian is a program that speaks the server side of SFTP protocol to stdout and expects client requests from stdin. sftp-server-guardian is not intended to be called directly, but from sshd(8) using the Subsystem option. See sshd(8) for more information. The sftp-server-guardian support reading and writing files directly to the guardian filesystem using the standard unix syntax. For example, if you wish to access the $system.system file system, using the sftp-server-guardian you would use the /system/system option. This make the sftp-server-guardian subsystem compatible with graphical user interfaces such as FileZilla. This subsystem does not have access to files residing on another node. Eventhough this feature was designed into the subsystem, there was no way to allow this via a graphical interface and unix filesystem syntax. As with all guardian filenames, you must limit your filenames to 8 characters. If the filename is too long you will get an error. If the filename has a .txt file on it, it will be stored as an edit file. SEE ALSO sftp(1), System Manager's Manual SFTP-SERVER(8)
ssh(1),
sshd(8)
T. Ylonen, and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secshfilexfer-00.txt, January 2001, work in progress material. AUTHORS Bowden Systems Inc <sales@bsi2.com> HISTORY sftp-server-guardian first appeared in 2005.
NSK-SSH V2.4
Page 61
March 31, 2008
NSK-SSH V2.4
Page 62
March 31, 2008
scmd
SCMD(1) System Reference Manual SCMD(1)
NAME scmd - secure command (remote command execution) SYNOPSIS scmd [-v] user@host cmd DESCRIPTION scmd is a command front-end for ssh. If cmd is more than one command, it should be enclosed in double or single quotes. -v used for displaying detail ssh information on stderr.
ENVIRONMENT VARIABLES If you need to use the SCMD program in a batch file and do not want to prompt for a password, there are two environment variables that may be set that will allow this to happen. GNOTTY 1 - Set this to indicate no password prompt GNOTTYPWD password - Set this to the password for the public key or user id HISTORY This program was written to solve the select problem for ssh in OSS. SEE ALSO ssh(1)
NSK-SSH V2.4
Page 63
March 31, 2008
NSK-SSH V2.4
Page 64
March 31, 2008
sftp
SFTP(1) NAME sftp - Secure file transfer program SYNOPSIS sftp [-1Cv] [-b batchfile] [-F ssh_config] [-o ssh_option] [-s subsystem | sftp_server] [-S program] host sftp [[user@]host[:file [file]]] sftp [[user@]host[:dir[/]]] DESCRIPTION sftp is an interactive file transfer program, similar to ftp(1), which performs all operations over an encrypted ssh(1) transport. It may also use many features of ssh, such as public key authentication and compression. sftp connects and logs into the specified host, then enters an interactive command mode. The second usage format will retrieve files automatically if a non-interactive authentication method is used; otherwise it will do so after successful interactive authentication. The last usage format allows the sftp client to start in a remote directory. The options are as follows: -1 Specify the use of protocol version 1. System Reference Manual SFTP(1)
-b batchfile Batch mode reads a series of commands from an input batchfile instead of stdin. Since it lacks user interaction it should be used in conjunction with non-interactive authentication. sftp will abort if any of the following commands fail: get, put, rename, ln, rm and lmkdir. -C Enables compression (via ssh's -C flag).
-F ssh_config Specifies an alternative per-user configuration file for ssh. This option is directly passed to ssh(1). -o ssh_option Can be used to pass options to ssh in the format used in the ssh(1) configuration file. This is useful for specifying options for which there is no separate sftp command-line flag. For exam-
NSK-SSH V2.4
Page 65
March 31, 2008
ple, to specify an alternate port use: sftp -oPort=24. -s subsystem | sftp_server Specifies the SSH2 subsystem or the path for an sftp server on the remote host. A path is useful for using sftp over protocol version 1, or when the remote sshd does not have an sftp subsystem configured. -S program Name of the program to use for the encrypted connection. program must understand ssh(1) options. -v Raise logging level. This option is also passed to ssh.
The
ENVIRONMENT VARIABLES If you need to use the SFTP program in a batch file and do not want to prompt for a password, there are two environment variables that may be set that will allow this to happen. GNOTTY 1 - Set this to indicate no password prompt GNOTTYPWD password - Set this to the password for the public key or user id INTERACTIVE COMMANDS Once in interactive mode, sftp understands a set of commands similar to those of ftp(1). Commands are case insensitive and pathnames may be enclosed in quotes if they contain spaces. bye cd path Change remote directory to path. lcd path Change local directory to path. chgrp grp path Change group of file path to grp. grp must be a numeric GID. chmod mode path Change permissions of file path to mode. chown own path Change owner of file path to own. own must be a numeric UID. exit Quit sftp. Quit sftp.
NSK-SSH V2.4
Page 66
March 31, 2008
get [flags] remote-path [local-path] Retrieve the remote-path and store it on the local machine. If the local path name is not specified, it is given the same name it has on the remote machine. If the -P flag is specified, then the file's full permission and access time are copied too. help Display help text.
lls [ls-options [path]] Display local directory listing of either path or current directory if path is not specified. lmkdir path Create local directory specified by path. ln oldpath newpath Create a symbolic link from oldpath to newpath. lpwd Print local working directory.
ls [path] Display remote directory listing of either path or current directory if path is not specified. lumask umask Set local umask to umask. mkdir path Create remote directory specified by path. put [flags] local-path [local-path] Upload local-path and store it on the remote machine. If the remote path name is not specified, it is given the same name it has on the local machine. If the -P flag is specified, then the file's full permission and access time are copied too. pwd quit Display remote working directory. Quit sftp.
rename oldpath newpath Rename remote file from oldpath to newpath. rmdir path Remove remote directory specified by path. rm path
NSK-SSH V2.4
Page 67
March 31, 2008
Delete remote file specified by path. symlink oldpath newpath Create a symbolic link from oldpath to newpath. ! command Execute command in local shell. ! ? Escape to local shell. Synonym for help.
AUTHORS Damien Miller <djm@mindrot.org> SEE ALSO scp(1),
ssh(1),
ssh-add(1),
ssh-keygen(1),
sftp-server(8),
sshd(8)
T. Ylonen, and S. Lehtinen, SSH File Transfer Protocol, draft-ietf-secshfilexfer-00.txt, January 2001, work in progress material.
NSK-SSH V2.4
Page 68
March 31, 2008
scp
SCP(1) NAME scp - secure copy (remote file copy program) SYNOPSIS scp [-pqrvBC46] [-F ssh_config] [-S program] [-P port] [-c cipher] [-i identity_file] [-o ssh_option] [[user@]host1:]file1 [...] [[user@]host2:]file2 DESCRIPTION scp copies files between hosts on a network. It uses ssh(1) for data transfer, and uses the same authentication and provides the same security as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if they are needed for authentication. Any file name may contain a host and user specification to indicate that the file is to be copied to/from that host. Copies between two remote hosts are permitted. The options are as follows: -c cipher Selects the cipher to use for encrypting the data transfer. option is directly passed to ssh(1). System Reference Manual SCP(1)
This
-i identity_file Selects the file from which the identity (private key) for RSA authentication is read. This option is directly passed to ssh(1). -p Preserves modification times, access times, and modes from the original file. Recursively copy entire directories. Verbose mode. Causes scp and ssh(1) to print debugging messages about their progress. This is helpful in debugging connection, authentication, and configuration problems. Selects batch mode (prevents asking for passwords or passphrases). Disables the progress meter.
-r -v
-B
-q
NSK-SSH V2.4
Page 69
March 31, 2008
-C
Compression enable. pression.
Passes the -C flag to ssh(1) to enable com-
-F ssh_config Specifies an alternative per-user configuration file for ssh. This option is directly passed to ssh(1). -P port Specifies the port to connect to on the remote host. Note that this option is written with a capital `P', because -p is already reserved for preserving the times and modes of the file in rcp(1). -S program Name of program to use for the encrypted connection. must understand ssh(1) options.
The program
-o ssh_option Can be used to pass options to ssh in the format used in the ssh(1) configuration file. This is useful for specifying options for which there is no separate scp command-line flag. For example, forcing the use of protocol version 1 is specified using scp -oProtocol=1. -4 -6 Forces scp to use IPv4 addresses only. Forces scp to use IPv6 addresses only.
ENVIRONMENT VARIABLES If you need to use the SCP program in a batch file and do not want to prompt for a password, there are two environment variables that may be set that will allow this to happen. GNOTTY 1 - Set this to indicate no password prompt GNOTTYPWD password - Set this to the password for the public key or user id AUTHORS Timo Rinne <tri@iki.fi> and Tatu Ylonen <ylo@cs.hut.fi> HISTORY scp is based on the rcp(1) program in BSD source code from the Regents of the University of California. SEE ALSO rcp(1), sshd(8)
sftp(1),
ssh(1),
ssh-add(1),
ssh-agent(1),
ssh-keygen(1),
NSK-SSH V2.4
Page 70
March 31, 2008
ssh-add
SSH-ADD(1) NAME ssh-add - adds RSA or DSA identities to the authentication agent SYNOPSIS ssh-add [-lLdD] [file ...] ssh-add -s reader ssh-add -e reader DESCRIPTION ssh-add adds RSA or DSA identities to the authentication agent, sshagent(1). When run without arguments, it adds the file $HOME/.ssh/identity. Alternative file names can be given on the command line. If any file requires a passphrase, ssh-add asks for the passphrase from the user. The passphrase is read from the user's tty. ssh-add retries the last passphrase if multiple identity files are given. The authentication agent must be running and must be an ancestor of the current process for ssh-add to work. The options are as follows: -l Lists fingerprints of all identities currently represented by the agent. Lists public key parameters of all identities currently represented by the agent. Instead of adding the identity, removes the identity from the agent. Deletes all identities from the agent. System Reference Manual SSH-ADD(1)
-L
-d
-D
-s reader Add key in smartcard reader. -e reader Remove key in smartcard reader.
NSK-SSH V2.4
Page 71
March 31, 2008
FILES $HOME/.ssh/identity Contains the protocol version 1 RSA authentication identity of the user. This file should not be readable by anyone but the user. Note that ssh-add ignores this file if it is accessible by others. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file. This is the default file added by ssh-add when no other files have been specified. $HOME/.ssh/id_dsa Contains the protocol version 2 DSA authentication identity of the user. $HOME/.ssh/id_rsa Contains the protocol version 2 RSA authentication identity of the user. DEFINES SUPPORTED This program supports the TCPIP^PROCESS^NAME define. This will allow you to execute the software against other tcpip process stacks in addition to the standard process stack($ZTCO). ENVIRONMENT DISPLAY and SSH_ASKPASS If ssh-add needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh-add does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh-add from a .Xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)
SEE ALSO ssh(1),
ssh-agent(1),
ssh-keygen(1),
sshd(8)
NSK-SSH V2.4
Page 72
March 31, 2008
ssh-agent
SSH-AGENT(1) NAME ssh-agent - authentication agent SYNOPSIS ssh-agent [-c | -s] [-d] [command [args ...]] ssh-agent [-c | -s] -k DESCRIPTION ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1). The options are as follows: -c Generate C-shell commands on stdout. This is the default if SHELL looks like it's a csh style of shell. Generate Bourne shell commands on stdout. This is the default if SHELL does not look like it's a csh style of shell. Kill the current agent (given by the SSH_AGENT_PID environment variable). Debug mode. fork. When this option is specified ssh-agent will not System Reference Manual SSH-AGENT(1)
-s
-k
-d
If a commandline is given, this is executed as a subprocess of the agent. When the command dies, so does the agent. The agent initially does not have any private keys. Keys are added using ssh-add(1). When executed without arguments, ssh-add(1) adds the $HOME/.ssh/identity file. If the identity has a passphrase, ssh-add(1) asks for the passphrase (using a small X11 application if running under X11, or from the terminal if running without X). It then sends the identity to the agent. Several identities can be stored in the agent; the agent can automatically use any of these identities. ssh-add -l displays the identities currently held by the agent.
NSK-SSH V2.4
Page 73
March 31, 2008
The idea is that the agent is run in the user's local PC, laptop, or terminal. Authentication data need not be stored on any other machine, and authentication passphrases never go over the network. However, the connection to the agent is forwarded over SSH remote logins, and the user can thus use the privileges given by the identities anywhere in the network in a secure way. There are two main ways to get an agent setup: Either the agent starts a new subcommand into which some environment variables are exported, or the agent prints the needed shell commands (either sh(1) or csh(1) syntax can be generated) which can be evalled in the calling shell. Later ssh(1) looks at these variables and uses them to establish a connection to the agent. A unix-domain socket is created (/tmp/ssh-XXXXXXXX/agent.<pid>), and the name of this socket is stored in the SSH_AUTH_SOCK environment variable. The socket is made accessible only to the current user. This method is easily abused by root or another instance of the same user. The SSH_AGENT_PID environment variable holds the agent's PID.
The agent exits automatically when the command given on the command line terminates. DEFINES SUPPORTED This program supports the TCPIP^PROCESS^NAME define. This will allow you to execute the software against other tcpip process stacks in addition to the standard process stack($ZTCO). FILES $HOME/.ssh/identity Contains the protocol version 1 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file. This file is not used by ssh-agent but is normally added to the agent using ssh-add(1) at login time. $HOME/.ssh/id_dsa Contains the protocol version 2 DSA authentication identity of the user. $HOME/.ssh/id_rsa Contains the protocol version 2 RSA authentication identity of the user.
NSK-SSH V2.4
Page 74
March 31, 2008
/tmp/ssh-XXXXXXXX/agent.<pid> Unix-domain sockets used to contain the connection to the authentication agent. These sockets should only be readable by the owner. The sockets should get automatically removed when the agent exits.
SEE ALSO ssh(1),
ssh-add(1),
ssh-keygen(1),
sshd(8)
NSK-SSH V2.4
Page 75
March 31, 2008
NSK-SSH V2.4
Page 76
March 31, 2008
ssh
SSH(1) NAME ssh - NSK SSH client (remote login program) SYNOPSIS ssh [-l login_name] hostname | user@hostname [command] ssh [-afgknqstvxACNPTX1246] [-b bind_address] [-c cipher_spec] [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec] [-o option] [-p port] [-F configfile] [-L port:host:hostport] [-R port:host:hostport] [-D port] hostname | user@hostname [command] DESCRIPTION ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. ssh connects and logs into the specified hostname. The user must prove his/her identity to the remote machine using one of several methods deM-pending on the protocol version used: SSH protocol version 1 First, if the machine the user logs in from is listed in /etc/hosts.equiv or /etc/ssh/shosts.equiv on the remote machine, and the user names are the same on both sides, the user is immediately permitted to log in. Second, if .rhosts or .shosts exists in the user's home directory on the remote machine and contains a line containing the name of the client machine and the name of the user on that machine, the user is permitted to log in. This form of authentication alone is normally not allowed by the server because it is not secure. The second authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. It means that if the login would be permitted by $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or /etc/ssh/shosts.equiv, and if additionally the server can verify the client's host key (see /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts in the FILES section), only then login is permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing. [Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be System Reference Manual SSH(1)
NSK-SSH V2.4
Page 77
March 31, 2008
disabled if security is desired.] As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.
ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This stores the private key in $HOME/.ssh/identity and the public key in $HOME/.ssh/identity.pub in the user's home directory. The user should then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional $HOME/.rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication. The most convenient way to use RSA authentication may be with an authentication agent. See ssh-agent(1) for more information. If other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network. SSH protocol version 2 When a user connects using the protocol version 2 different authentication methods are available. Using the default values for PreferredAuthentications, the client will try to authenticate first using the hostbased method; if this method fails public key authentication is attempted, and finally if this method fails keyboard-interactive and password authentication are tried. The public key method is similar to RSA authentication described in the
NSK-SSH V2.4
Page 78
March 31, 2008
previous section and allows the RSA or DSA algorithm to be used: The client uses his private key, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to sign the session identifier and sends the result to the server. The server checks whether the matching public key is listed in $HOME/.ssh/authorized_keys and grants access if both the key is found and the signature is correct. The session identifier is derived from a shared Diffie-Hellman value and is only known to the client and the server. If public key authentication fails or is not available a password can be sent encrypted to the remote host for proving the user's identity. Additionally, ssh supports hostbased or challenge response authentication. Protocol 2 provides additional mechanisms for confidentiality (the traffic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity (hmac-md5, hmac-sha1). Note that protocol 1 lacks a strong mechanism for ensuring the integrity of the connection. Login session and remote execution When the user's identity has been accepted by the server, the server either executes the given command, or logs into the machine and gives the user a normal shell on the remote machine. All communication with the remote command or shell will be automatically encrypted. If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters noted below. If no pseudo tty has been allocated, the session is transparent and can be used to reliably transfer binary data. On most systems, setting the escape character to ``none'' will also make the session transparent even if a tty is used. The session terminates when the command or shell on the remote machine exits and all X11 and TCP/IP connections have been closed. The exit status of the remote program is returned as the exit status of ssh. Escape Characters When a pseudo terminal has been requested, ssh supports a number of functions through the use of an escape character. A single tilde character can be sent as ~~ or by following the tilde by a character other than those described below. The escape character must always follow a newline to be interpreted as special. The escape character can be changed in configuration files using the EscapeChar configuration directive or on the command line by the -e option.
NSK-SSH V2.4
Page 79
March 31, 2008
The supported escapes (assuming the default `~') are: ~. ~^Z ~# ~& Disconnect Background ssh List forwarded connections Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate (protocol version 1 only) Display a list of escape characters Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it)
~? ~R
X11 and TCP forwarding If the ForwardX11 variable is set to ``yes'' (or, see the description of the -X and -x options described later) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files. The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a ``proxy'' X server on the server machine for forwarding the connections over the encrypted channel. ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain). If the user is using an authentication agent, the connection to the agent is automatically forwarded to the remote side unless disabled on the command line or in a configuration file. Forwarding of arbitrary TCP/IP connections over the secure channel can be specified either on the command line or in a configuration file. One possible application of TCP/IP forwarding is a secure connection to an electronic purse; another is going through firewalls.
NSK-SSH V2.4
Page 80
March 31, 2008
Server authentication ssh automatically maintains and checks a database containing identifications for all hosts it has ever been used with. Host keys are stored in $HOME/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent a trojan horse from getting the user's password. Another purpose of this mechanism is to prevent man-in-the-middle attacks which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option (see below) can be used to prevent logins to machines whose host key is not known or has changed. The options are as follows: -a -A Disables forwarding of the authentication agent connection. Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.
-b bind_address Specify the interface to transmit from on machines with multiple interfaces or aliased addresses. -c blowfish|3des|des Selects the cipher to use for encrypting the session. 3des is used by default. It is believed to be secure. 3des (triple-des) is an encrypt-decrypt-encrypt triple with three different keys. blowfish is a fast block cipher, it appears very secure and is much faster than 3des. des is only supported in the ssh client for interoperability with legacy protocol 1 implementations that do not support the 3des cipher. Its use is strongly discouraged due to cryptographic weaknesses. -c cipher_spec Additionally, for protocol version 2 a comma-separated list of ciphers can be specified in order of preference. See Ciphers for more information. -e ch|^ch|none Sets the escape character for sessions with a pty (default: `~'). The escape character is only recognized at the beginning of a line. The escape character followed by a dot (`.') closes the connection, followed by control-Z suspends the connection, and followed by itself sends the escape character once. Setting the
NSK-SSH V2.4
Page 81
March 31, 2008
character to ``none'' disables any escapes and makes the session fully transparent. -f Requests ssh to go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background. This implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm. Allows remote hosts to connect to local forwarded ports.
-g
-i identity_file Selects the file from which the identity (private key) for RSA or DSA authentication is read. Default is $HOME/.ssh/identity in the user's home directory. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). -I smartcard_device Specifies which smartcard device to use. The argument is the device ssh should use to communicate with a smartcard used for storing the user's private RSA key. -k Disables forwarding of Kerberos tickets and AFS tokens. This may also be specified on a per-host basis in the configuration file.
-l login_name Specifies the user to log in as on the remote machine. This also may be specified on a per-host basis in the configuration file. -m mac_spec Additionally, for protocol version 2 a comma-separated list of MAC (message authentication code) algorithms can be specified in order of preference. See the MACs keyword for more information. -n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.) Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).
-N
NSK-SSH V2.4
Page 82
March 31, 2008
-o option Can be used to give options in the format used in the configuration file. This is useful for specifying options for which there is no separate command-line flag. -p port Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file. -P Use a non-privileged port for outgoing connections. This can be used if a firewall does not permit connections from privileged ports. Note that this option turns off RhostsAuthentication and RhostsRSAAuthentication for older servers. Quiet mode. suppressed. Causes all warning and diagnostic messages to be Only fatal errors are displayed.
-q
-s
May be used to request invocation of a subsystem on the remote system. Subsystems are a feature of the SSH2 protocol which facilitate the use of SSH as a secure transport for other applications (eg. sftp). The subsystem is specified as the remote command. Force pseudo-tty allocation. This can be used to execute arbiM-trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty. Disable pseudo-tty allocation. Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increases the verbosity. Maximum is 3. Disables X11 forwarding. Enables X11 forwarding. This can also be specified on a per-host
-t
-T -v
-x -X
basis in a configuration file. -C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP/IP connections). The compression algorithm is the same used by gzip(1), and the ``level'' can be controlled by the CompressionLevel option (see below). Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the con-
NSK-SSH V2.4
Page 83
March 31, 2008
figuration files; see the Compression option below. -F configfile Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is $HOME/.ssh/config. -L port:host:hostport Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine. Port forwardings can also be specified in the configuration file. Only root can forward privileged ports. IPv6 addresses can be specified with an alternative syntax: port/host/hostport -R port:host:hostport Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine. Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. IPv6 addresses can be specified with an alternative syntax: port/host/hostport -D port Specifies a local ``dynamic'' application-level port forwarding. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 protocol is supported, and ssh will act as a SOCKS4 server. Only root can forward priviM-leged ports. Dynamic port forwardings can also be specified in the configuration file. -1 -2 -4 Forces ssh to try protocol version 1 only. Forces ssh to try protocol version 2 only. Forces ssh to use IPv4 addresses only.
NSK-SSH V2.4
Page 84
March 31, 2008
-6
Forces ssh to use IPv6 addresses only.
CONFIGURATION FILES ssh obtains configuration data from the following sources in the following order: command line options, user's configuration file ($HOME/.ssh/config), and system-wide configuration file (/etc/ssh/ssh_config). For each parameter, the first obtained value will be used. The configuration files contain sections bracketed by ``Host'' specifications, and that section is only applied for hosts that match one of the patterns given in the specification. The matched host name is the one given on the command line. Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end. The configuration file has the following format: Empty lines and lines starting with `#' are comments. Otherwise a line is of the format ``keyword arguments''. Configuration options may be separated by whitespace or optional whitespace and exactly one `='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp and sftp -o option. The possible keywords and their meanings are as follows (note that keywords are case-insensitive and arguments are case-sensitive): Host Restricts the following declarations (up to the next Host keyword) to be only for those hosts that match one of the patterns given after the keyword. `*' and `?' can be used as wildcards in the patterns. A single `*' as a pattern can be used to provide global defaults for all hosts. The host is the hostname argument given on the command line (i.e., the name is not converted to a canonicalized host name before matching).
AFSTokenPassing Specifies whether to pass AFS tokens to remote host. The argument to this keyword must be ``yes'' or ``no''. This option applies to protocol version 1 only. BatchMode If set to ``yes'', passphrase/password querying will be disabled. This option is useful in scripts and other batch jobs where no user is present to supply the password. The argument must be ``yes'' or ``no''. The default is ``no''.
NSK-SSH V2.4
Page 85
March 31, 2008
BindAddress Specify the interface to transmit from on machines with multiple interfaces or aliased addresses. Note that this option does not work if UsePrivilegedPort is set to ``yes''. CheckHostIP If this flag is set to ``yes'', ssh will additionally check the host IP address in the known_hosts file. This allows ssh to detect if a host key changed due to DNS spoofing. If the option is set to ``no'', the check will not be executed. The default is ``yes''. Cipher Specifies the cipher to use for encrypting the session in protocol version 1. Currently, ``blowfish'', ``3des'', and ``des'' are supported. des is only supported in the ssh client for inM-teroperability with legacy protocol 1 implementations that do not support the 3des cipher. Its use is strongly discouraged due to cryptographic weaknesses. The default is ``3des''.
Ciphers Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple ciphers must be comma-separated. The deM-fault is `àes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc''
ClearAllForwardings Specifies that all local, remote and dynamic port forwardings specified in the configuration files or on the command line be cleared. This option is primarily useful when used from the ssh command line to clear port forwardings set in configuration files, and is automatically set by scp(1) and sftp(1). The argument must be ``yes'' or ``no''. The default is ``no''. Compression Specifies whether to use compression. The argument must be ``yes'' or ``no''. The default is ``no''. CompressionLevel Specifies the compression level to use if compression is enabled. The argument must be an integer from 1 (fast) to 9 (slow, best). The default level is 6, which is good for most applications. The meaning of the values is the same as in gzip(1). Note that this option applies to protocol version 1 only. ConnectionAttempts Specifies the number of tries (one per second) to make before
NSK-SSH V2.4
Page 86
March 31, 2008
falling back to rsh or exiting. The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1. DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. The argument must be a port number. Currently the SOCKS4 protocol is supported, and ssh will act as a SOCKS4 server. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports. EscapeChar Sets the escape character (default: `~'). The escape character can also be set on the command line. The argument should be a single character, `^' followed by a letter, or ``none'' to disable the escape character entirely (making the connection transparent for binary data). FallBackToRsh Specifies that if connecting via ssh fails due to a connection refused error (there is no sshd(8) listening on the remote host), rsh(1) should automatically be used instead (after a suitable warning about the session being unencrypted). The argument must be ``yes'' or ``no''. The default is ``no''. ForwardAgent Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. The argument must be ``yes'' or ``no''. The default is ``no''. ForwardX11 Specifies whether X11 connections will be automatically redirected over the secure channel and DISPLAY set. The argument must be ``yes'' or ``no''. The default is ``no''. GatewayPorts Specifies whether remote hosts are allowed to connect to local forwarded ports. By default, ssh binds local port forwardings to the loopback addresss. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that ssh should bind local port forwardings to the wildcard address, thus allowing remote hosts to connect to forwarded ports. The argument must be ``yes'' or ``no''. The default is ``no''. GlobalKnownHostsFile
NSK-SSH V2.4
Page 87
March 31, 2008
Specifies a file to use for the global host key database instead of /etc/ssh/ssh_known_hosts. HostbasedAuthentication Specifies whether to try rhosts based authentication with public key authentication. The argument must be ``yes'' or ``no''. The default is ``no''. This option applies to protocol version 2 only and is similar to RhostsRSAAuthentication. HostKeyAlgorithms Specifies the protocol version 2 host key algorithms that the client wants to use in order of preference. The default for this option is: ``ssh-rsa,ssh-dss'' HostKeyAlias Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files. This option is useful for tunneling ssh connections or for multiple servers running on a single host. HostName Specifies the real host name to log into. This can be used to specify nicknames or abbreviations for hosts. Default is the name given on the command line. Numeric IP addresses are also permitted (both on the command line and in HostName specifications). IdentityFile Specifies the file from which the user's RSA or DSA authentication identity is read (default $HOME/.ssh/identity in the user's home directory). Additionally, any identities represented by the authentication agent will be used for authentication. The file name may use the tilde syntax to refer to a user's home directory. It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence. KeepAlive Specifies whether the system should send keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. The default is ``yes'' (to send keepalives), and the client will notice if the network goes down or the remote host dies. This is important in scripts, and many users want it too. To disable keepalives, the value should be set to ``no'' in both
NSK-SSH V2.4
Page 88
March 31, 2008
the server and the client configuration files. KerberosAuthentication Specifies whether Kerberos authentication will be used. gument to this keyword must be ``yes'' or ``no''.
The ar-
KerberosTgtPassing Specifies whether a Kerberos TGT will be forwarded to the server. This will only work if the Kerberos server is actually an AFS kaserver. The argument to this keyword must be ``yes'' or
``no''. LocalForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be a port number, and the second must be host:port. IPv6 addresses can be specified with an alternative syntax: host/port. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports. LogLevel Gives the verbosity level that is used when logging messages from ssh. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. The default is INFO. MACs Specifies the MAC (message authentication code) algorithms in order of preference. The MAC algorithm is used in protocol version 2 for data integrity protection. Multiple algorithms must be comma-separated. The default is ``hmac-md5,hmac-sha1,hmacripemd160,hmac-sha1-96,hmac-md5-96''.
NumberOfPasswordPrompts Specifies the number of password prompts before giving up. The argument to this keyword must be an integer. Default is 3. PasswordAuthentication Specifies whether to use password authentication. The argument to this keyword must be ``yes'' or ``no''. The default is ``yes''. Port Specifies the port number to connect on the remote host. is 22. Default
PreferredAuthentications Specifies the order in which the client should try protocol 2 authentication methods. This allows a client to prefer one method
NSK-SSH V2.4
Page 89
March 31, 2008
(e.g. keyboard-interactive) over another method (e.g. password) The default for this option is: ``hostbased,publickey,keyboardinteractive,password'' Protocol Specifies the protocol versions ssh should support in order of preference. The possible values are ``1'' and ``2''. Multiple versions must be comma-separated. The default is ``2,1''. This means that ssh tries version 2 and falls back to version 1 if version 2 is not available. ProxyCommand Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with /bin/sh. In the command string, `%h' will be substituted by the host name to connect and `%p' by the port. The command can be basically anything, and should read from its standard input and write to its standard output. It should eventually connect an sshd(8) server running on some machine, or execute sshd -i somewhere. Host key management will be done using the HostName of the host being connected (defaulting to the name typed by the user). Note that CheckHostIP is not available for connects with a proxy command. PubkeyAuthentication Specifies whether to try public key authentication. The argument to this keyword must be ``yes'' or ``no''. The default is
``yes''. This option applies to protocol version 2 only. RemoteForward Specifies that a TCP/IP port on the remote machine be forwarded over the secure channel to the specified host and port from the local machine. The first argument must be a port number, and the second must be host:port. IPv6 addresses can be specified with an alternative syntax: host/port. Multiple forwardings may be specified, and additional forwardings can be given on the command line. Only the superuser can forward privileged ports. RhostsAuthentication Specifies whether to try rhosts based authentication. Note that this declaration only affects the client side and has no effect whatsoever on security. Disabling rhosts authentication may reduce authentication time on slow connections when rhosts authentication is not used. Most servers do not permit RhostsAuthentication because it is not secure (see RhostsRSAAuthentication). The argument to this keyword must be ``yes'' or ``no''. The deM-fault is ``yes''. This option applies to protocol version 1 only.
NSK-SSH V2.4
Page 90
March 31, 2008
RhostsRSAAuthentication Specifies whether to try rhosts based authentication with RSA host authentication. The argument must be ``yes'' or ``no''. The default is ``yes''. This option applies to protocol version 1 only. RSAAuthentication Specifies whether to try RSA authentication. The argument to this keyword must be ``yes'' or ``no''. RSA authentication will only be attempted if the identity file exists, or an authentication agent is running. The default is ``yes''. Note that this option applies to protocol version 1 only. ChallengeResponseAuthentication Specifies whether to use challenge response authentication. The argument to this keyword must be ``yes'' or ``no''. The default is ``yes''. SmartcardDevice Specifies which smartcard device to use. The argument to this keyword is the device ssh should use to communicate with a smartcard used for storing the user's private RSA key. By default, no device is specified and smartcard support is not activated. StrictHostKeyChecking If this flag is set to ``yes'', ssh will never automatically add host keys to the $HOME/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against trojan horse attacks, however, can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained, or connections to new hosts are frequently made. This option forces the user to manually add all new hosts. If this flag is set to ``no'', ssh will automatically add new host keys to the user known hosts files. If this flag is set to `àsk'', new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must be ``yes'', ``no'' or `àsk''. The default is `àsk''. UsePrivilegedPort Specifies whether to use a privileged port for outgoing connections. The argument must be ``yes'' or ``no''. The default is ``no''. Note that this option must be set to ``yes'' if RhostsAuthentication and RhostsRSAAuthentication authentications are needed with older servers.
NSK-SSH V2.4
Page 91
March 31, 2008
User
Specifies the user to log in as. This can be useful when a different user name is used on different machines. This saves the trouble of having to remember to give the user name on the command line.
UserKnownHostsFile Specifies a file to use for the user host key database instead of $HOME/.ssh/known_hosts. UseRsh Specifies that rlogin/rsh should be used for this host. It is possible that the host does not at all support the ssh protocol. This causes ssh to immediately execute rsh(1). All other options (except HostName) are ignored if this has been specified. The argument must be ``yes'' or ``no''.
XAuthLocation Specifies the location of the xauth(1) program. /usr/bin/X11/xauth.
The default is
ENVIRONMENT ssh will normally set the following environment variables: DISPLAY The DISPLAY variable indicates the location of the X11 server. It is automatically set by ssh to point to a value of the form ``hostname:n'' where hostname indicates the host where the shell runs, and n is an integer >= 1. ssh uses this special value to forward X11 connections over the secure channel. The user should normally not set DISPLAY explicitly, as that will render the X11 connection insecure (and will require the user to manually copy any required authorization cookies). HOME LOGNAME Synonym for USER; set for compatibility with systems that use this variable. MAIL PATH Set to the path of the user's mailbox. Set to the default PATH, as specified when compiling ssh. Set to the path of the user's home directory.
SSH_ASKPASS If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .Xsession or related script.
NSK-SSH V2.4
Page 92
March 31, 2008
(Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.) SSH_AUTH_SOCK Identifies the path of a unix-domain socket used to communicate with the agent. SSH_CLIENT Identifies the client end of the connection. The variable contains three space-separated values: client ip-address, client port number, and server port number. SSH_ORIGINAL_COMMAND The variable contains the original command line if a forced command is executed. It can be used to extract the original arguments. SSH_TTY This is set to the name of the tty (path to the device) associated with the current shell or command. If the current session has no tty, this variable is not set. TZ The timezone variable is set to indicate the present timezone if it was set when the daemon was started (i.e., the daemon passes the value on to new connections). Set to the name of the user logging in.
USER
Additionally, ssh reads $HOME/.ssh/environment, and adds lines of the format ``VARNAME=value'' to the environment. NONSTOP ADDITIONAL OPTIONS If you need to use the SSH program in a batch file and do not want to prompt for a password, there are two environment variables that may be set that will allow this to happen. GNOTTY 1 - Set this to indicate no password prompt GNOTTYPWD password - Set this to the password for the public key or user id FILES $HOME/.ssh/known_hosts Records host keys for all hosts the user has logged into that are not in /etc/ssh/ssh_known_hosts. See sshd(8). $HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa Contains the authentication identity of the user. They are for protocol 1 RSA, protocol 2 DSA, and protocol 2 RSA, respectively.
NSK-SSH V2.4
Page 93
March 31, 2008
These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). Note that ssh ignores a private key file if it is accessible by othM-ers. It is possible to specify a passphrase when generating the key; the passphrase will be used to encrypt the sensitive part of this file using 3DES. $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub Contains the public key for authentication (public part of the identity file in human-readable form). The contents of the $HOME/.ssh/identity.pub file should be added to $HOME/.ssh/authorized_keys on all machines where the user wishes to log in using protocol version 1 RSA authentication. The contents of the $HOME/.ssh/id_dsa.pub and $HOME/.ssh/id_rsa.pub file should be added to $HOME/.ssh/authorized_keys on all machines where the user wishes to log in using protocol version 2 DSA/RSA authentication. These files are not sensitive and can (but need not) be readable by anyone. These files are never used automatically and are not necessary; they are only provided for the convenience of the user. $HOME/.ssh/config This is the per-user configuration file. The format of this file is described above. This file is used by the ssh client. This file does not usually contain any sensitive information, but the recommended permissions are read/write for the user, and not accessible by others. $HOME/.ssh/authorized_keys Lists the public keys (RSA/DSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. In the simplest form the format is the same as the .pub identity files. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others. /etc/ssh/ssh_known_hosts Systemwide list of known host keys. This file should be prepared by the system administrator to contain the public host keys of all machines in the organization. This file should be worldreadable. This file contains public keys, one per line, in the following format (fields separated by spaces): system name, public key and optional comment field. When different names are used for the same machine, all such names should be listed, separated by commas. The format is described on the sshd(8) manual page. The canonical system name (as returned by name servers) is used by sshd(8) to verify the client host when logging in; other names
NSK-SSH V2.4
Page 94
March 31, 2008
are needed because ssh does not convert the user-supplied name to a canonical name before checking the key, because someone with access to the name servers would then be able to fool host authentication. /etc/ssh/ssh_config Systemwide configuration file. This file provides defaults for those values that are not specified in the user's configuration file, and for those users who do not have a configuration file. This file must be world-readable. $HOME/.rhosts This file is used in .rhosts authentication to list the host/user pairs that are permitted to log in. (Note that this file is also used by rlogin and rsh, which makes using this file insecure.) Each line of the file contains a host name (in the canonical form returned by name servers), and then a user name on that host, separated by a space. On some machines this file may need to be world-readable if the user's home directory is on a NFS partition, because sshd(8) reads it as root. Additionally, this file must be owned by the user, and must not have write permissions for anyone else. The recommended permission for most machines is read/write for the user, and not accessible by others. Note that by default sshd(8) will be installed so that it requires successful RSA host authentication before permitting .rhosts authentication. If the server machine does not have the client's host key in /etc/ssh/ssh_known_hosts, it can be stored in $HOME/.ssh/known_hosts. The easiest way to do this is to connect back to the client from the server machine using ssh; this will automatically add the host key to $HOME/.ssh/known_hosts. $HOME/.shosts This file is used exactly the same way as .rhosts. The purpose for having this file is to be able to use rhosts authentication with ssh without permitting login with rlogin(1) or rsh(1). /etc/hosts.equiv This file is used during .rhosts authentication. It contains canonical hosts names, one per line (the full format is described on the sshd(8) manual page). If the client host is found in this file, login is automatically permitted provided client and server user names are the same. Additionally, successful RSA host authentication is normally required. This file should only be writable by root. /etc/ssh/shosts.equiv This file is processed exactly as /etc/hosts.equiv. This file may be useful to permit logins using ssh but not using rsh/rlogin.
NSK-SSH V2.4
Page 95
March 31, 2008
/etc/ssh/sshrc Commands in this file are executed by ssh when the user logs in just before the user's shell (or command) is started. See the sshd(8) manual page for more information. $HOME/.ssh/rc Commands in this file are executed by ssh when the user logs in just before the user's shell (or command) is started. See the sshd(8) manual page for more information. $HOME/.ssh/environment Contains additional definitions for environment variables, see section ENVIRONMENT above.
SEE ALSO rlogin(1), keygen(1),
rsh(1), scp(1), sftp(1), telnet(1), sshd(8)
ssh-add(1),
ssh-agent(1),
ssh-
T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH Protocol Architecture, draft-ietf-secsh-architecture-09.txt, July 2001, work in progress material.
NSK-SSH V2.4
Page 96
March 31, 2008
APPENDIX B - FILES sshd_config FILE

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/ssh/bin # This is the sshd server system-wide configuration file. # for more information. Port 22 #Protocol 2,1 ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging # Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 See sshd(8)
NSK-SSH V2.4
Page 97
March 31, 2008
HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # Uncomment to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem Subsystem sftp sftp-g /usr/local/ssh/libexec/sftp-server /usr/local/ssh/libexec/sftp-server-guardian
NSK-SSH V2.4
Page 98
March 31, 2008
ssh_config FILE
# This is ssh client systemwide configuration file. See ssh(1) for more # information. This file provides defaults for users, and the values can # be changed in per-user configuration files or on the command line. # # # # # # # Configuration data is parsed as follows: 1. command line options 2. user-specific file 3. system-wide file Any configuration value is only changed the first time it is set. Thus, host-specific definitions should be at the beginning of the configuration file, and defaults at the end.
# Site-wide defaults for various options # Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking yes # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_rsa # Port 22 # Protocol 2,1 # Cipher blowfish # EscapeChar ~
NSK-SSH V2.4
Page 99
March 31, 2008
NSK-SSH V2.4
Page 100
March 31, 2008
APPENDIX C - TELNET ISOLATION FILES start_ssh_2_cpu_2stack.sh FILE
############################################ # Start SSH with IPSSH across two cpus ## ## Start the SSH process on port 700 and 701 export TCPIP_TELNET_STACK=\$ztc99 run -cpu=0 sshd -p 700 run -cpu=1 sshd -p 701 ## Start the primary IPSSH ($ISX) process run -cpu=0 ipssh sleep 5 ## Start the backup IPSSH ($ISY) process run -cpu=1 ipssh -wait 0 # Startup complete
NSK-SSH V2.4
Page 101
March 31, 2008
NSK-SSH V2.4
Page 102
March 31, 2008
APPENDIX D - ZZKRN FILES ipztc00a FILE

allow 10 errors assu process $zzkrn delete process IPSSH-ztc00a add process IPSSH-ztc00a, & name $ob010, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 0, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_ipssh_ztc0a.sh <- >>/dev/null 2>/dev/null" start process IPSSH-ztc00a
start_ipssh_ztc0a.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the IPSSH in CPU 0 using zzkrn # echo "Starting IPSSH on PORT 22" # kill -s SIGGUARDIAN /G/ip000 run -name=/G/ip000 -cpu=0 -gpri=155 -term=/G/zhome ipssh1 -D wait 0 #
NSK-SSH V2.4
Page 103
March 31, 2008
ipztc00b FILE
allow 10 errors assu process $zzkrn delete process IPSSH-ztc00b add process IPSSH-ztc00b, & name $ob011, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 1, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_ipssh_ztc0b.sh <- >>/dev/null 2>/dev/null" start process IPSSH-ztc00b
start_ipssh_ztc0b.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the IPSSH in CPU 1 using zzkrn # echo "Starting IPSSH on PORT 22" # # Note that the wait 0 is used just incase the other ipssh process # has been started and is on port 22. If the other ipssh process # dies, this process will take over. # kill -s SIGGUARDIAN /G/ip001 run -name=/G/ip001 -cpu=1 -gpri=155 -term=/G/zhome ipssh1 -D -wait 0 #
NSK-SSH V2.4
Page 104
March 31, 2008
ranztc0a FILE
allow 10 errors assu process $zzkrn delete process RANDOM-ztc00a add process RANDOM-ztc00a, & name $ob000, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 0, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_random_ztc00a.sh <- >>/dev/null 2>/dev/null" start process RANDOM-ztc00a
start_random_ztc00a.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the Random Number Generater in CPU 0 using zzkrn # echo "Starting Random Number Generator TCPIP 790" # kill -s SIGGUARDIAN /G/rb000 run -name=/G/rb000 -cpu=0 -gpri=144 -term=/G/zhome prngd -f tcp/localhost:790 #
NSK-SSH V2.4
Page 105
March 31, 2008
ranztc0b FILE
llow 10 errors assu process $zzkrn delete process RANDOM-ztc00b add process RANDOM-ztc00b, & name $ob001, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 1, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_random_ztc00b.sh <- >>/dev/null 2>/dev/null" start process RANDOM-ztc00b
start_random_ztc0b.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the Random Number Generater in CPU 1 using zzkrn # echo "Starting Random Number Generator TCPIP 791" # kill -s SIGGUARDIAN /G/rb001 run -name=/G/rb001 -cpu=1 -gpri=144 -term=/G/zhome prngd -f tcp/localhost:791 #
NSK-SSH V2.4
Page 106
March 31, 2008
sdztc00a FILE
allow 10 errors assu process $zzkrn delete process SSHD-ztc00a add process SSHD-ztc00a, & name $ob020, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 0, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_sshd_ztc00a.sh <- >>/dev/null 2>/dev/null" start process SSHD-ztc00a
start_sshd_ztc00a.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the SSHD in CPU 0 using zzkrn # echo "Starting SSHD on PORT 700" # kill -s SIGGUARDIAN /G/sd000 run -name=/G/sd000 -cpu=0 -gpri=154 -term=/G/zhome sshd -D -p 700 #
NSK-SSH V2.4
Page 107
March 31, 2008
sdztc00b FILE
allow 10 errors assu process $zzkrn delete process SSHD-ztc00b add process SSHD-ztc00b, & name $ob021, & AUTORESTART 10,& HOMETERM $zhome,& primarycpu 1, & outfile $zhome, & startmode manual,& userid 255,255,& program $system.system.osh,& startupmsg & "-c /usr/local/ssh/install/start_sshd_ztc00b.sh <- >>/dev/null 2>/dev/null" start process SSHD-ztc00b
start_sshd_ztc00b.sh FILE
export PATH=$PATH:/usr/local/ssh/bin:/usr/local/ssh/sbin export PATH=$PATH:/usr/local/random/bin add_define =tcpip^process^name class=map file=\$ztc0 # # Start the SSHD in CPU 1 using zzkrn # echo "Starting SSHD on PORT 701" # kill -s SIGGUARDIAN /G/sd001 run -name=/G/sd001 -cpu=1 -gpri=154 -term=/G/zhome sshd -D -p 701 #
NSK-SSH V2.4
Page 108
March 31, 2008
INSTALL NOTES:
NSK-SSH V2.4
Page 109
March 31, 2008
NSK-SSH V2.4
Page 110
March 31, 2008

SSH Install v24

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SSH Install v24

Încărcat de

Drepturi de autor:

Formate disponibile

Version 2.

Bowden Systems Inc.

Audience and Prerequisites

March 31, 2008

Note: This page is left blank for double sided printing.

March 31, 2008

INSTALLING THE SOFTWARE

For the H-Series and J-Series operating system:

March 31, 2008

Note: This page is left blank for double sided printing.

March 31, 2008

BASIC SETUP OF SSH

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

ADVANCED SETUP OF SSH

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

Note: This page is left blank for double sided printing.

March 31, 2008

CHECKING YOUR SESSION ACCESS VIA PC CLIENT

2. Enter your user name and password:

March 31, 2008

March 31, 2008

CHECKING YOUR SESSION ACCESS VIA UNIX CLIENT

Available Services: TACL EXIT Enter Choice>

March 31, 2008

March 31, 2008

March 31, 2008

Copyright (c) 2001-2008 Bowden Systems, Inc. All Rights Reserved

March 31, 2008

APPENDIX A - MAN PAGES prngd

March 31, 2008

March 31, 2008

March 31, 2008

Note: This page is left blank for double sided printing.

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

SEE ALSO ssh(1),

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

Note: This page is left blank for double sided printing.

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008

March 31, 2008