=========================================================================== Ssh perms on .ssh 700, authorized keys 644, home dir 755 =========================================================================== ssh tunnelling ssh tunnelling is an excellent way to tunnel insecure protocols through a secure communication channel. In this example, I'll tunnel POP3 traffic using ssh. Traditional POP3 traffic, including username and password information, travels clear-text across the network. OpenSSH is used in the following examples. To tunnel POP3 traffic using ssh: 1. Make sure an ssh client is installed on your machine and an ssh server is installed on the POP3 server. 2. Create a local ssh tunnel on your machine (port 1234 for this example) to the POP3 server's port 110. You will need to be the root user to bind to "privileged" ports (< 1024). ssh -f -N -L 1234:localhost:110 user@POP3_server 3. Test the tunnel. telnet localhost 1234 You should see the POP3 server's banner information. 4. Configure your mail client to access your mail via POP3 using mail server localhost and port 1234. "Reverse" ssh tunnel It is possible to create a "reverse" ssh tunnel. The reverse tunnel will allow you to create an ssh tunnel from your work computer to your home computer, for example, and then login to your work machine from your home machine even if your work firewall does not permit ssh traffic initiated from your home machine! For this to work, an ssh server must be installed on your work and home computer, and ssh (TCP port 22) must be allowed outbound from your work computer to your home computer. ssh -R remote_port:localhost:22 your_home_computer ex. ssh -R 2048:localhost:22 home.computer.com At home, you would then run ssh -p 2048 localhost to log into your work computer via ssh. Here is a script I run every 5 minutes through the cron facility on my work system to make sure the reverse ssh tunnel to my home system is up and running. It is useful in case my_home_system is rebooted. #!/bin/sh # $COMMAND is the command used to create the reverse ssh tunnel COMMAND='ssh -N -R 31337:localhost:22 my_home_system' # Is the tunnel up? CHECK_TUNNEL=`ps -eo args | grep "$COMMAND" | grep -v grep` # If the tunnel is not up, create the tunnel if [ -z "$CHECK_TUNNEL" ] ; then $COMMAND fi =========================================================================== To preference a particular key, use the -i private_key_file option on the command line: mydesktop$ ssh -i ~/.ssh/special_ssh_key ssh-server Enter passphrase for key '/home/xahria/.ssh/special_ssh_key': Another option is to create an entry in your ~/.ssh/config file to indicate the key to use: mydesktop$ cat ~/.ssh/config Host ssh-server IdentityFile ~/.ssh/special_ssh_key mydesktop$ ssh ssh-server Enter passphrase for key '/home/xahria/.ssh/special_ssh_key': =========================================================================== "Man-in-the-middle" errors when using ssh rm that host entry from ~user/.ssh/known_hosts =========================================================================== Cannot ssh to host as root: vi /usr/local/etc/sshd_config #uncomment "#PermitRootLogin yes" then restart sshd =========================================================================== To be able to ssh node without a passwd NOTE: ssh must be running on hosts As user user on localnode ssh-keygen # Don't use a phrase cp ~user/ssh/identity.pub authorized_keys telnet remotenode #as user cd .ssh vi authorized_keys Append authorized_keys line from localnode into this file - make sure it is a single continuous line. Note: for windows run the c:\ssh\ssh-keygen and append it to the ~user/.ssh/authorized_keys. NOTE: The ssh-keygen should only be run when you wish to create a new key to populate to all nodes. Do NOT run it just for fun otherwise you must either restore a previous version or push the file out to all affected nodes. Think of the authorized_keys as an .rhosts entry. If you want to rsh (ssh) to another node, the other node must have you in its .rhosts (authorized_keys) file. If you have multiple hosts, then append your entry to the authorized_keys file. Now you can as the user on localnode ssh remotenode ==================================================================== When ssh'ing to a new host, keep ssh from prompting for "yes" to add to known_hosts. #enter the key via a script without answering "yes" to add hosts, run another, but plain, "ssh HOSTNAME" to get in "finalized". ssh-keyscan HOSTNAME >> ~/.ssh/known_hosts ssh HOSTNAME date ==================================================================== ssh-keygen -R HOSTNAME #remove a host from known_hosts ssh-keyscan HOSTNAME #list the public key ssh-keyscan -H HOSTNAME #list the public key, hash ==================================================================== Q.) Ssh doesn't behave as expected. A.) ssh -v node If it complains about directory permissions, change your home dir to 755 and the authorized_keys to 644 Or you may have a bad entry in the known_hosts (especially if a host was renamed). In this case, delete the entry from your known_hosts and try ssh again (it will prompt to add a new entry, allow it to). =========================================================================== Goal: to be able to ssh in as user from windows to remotehost host w/o a passwd 1.) Open winssh (does the automatic install) 2.) cd c:\ssh; ssh-keygen.exe 3.) ftp remotehost; cd ~user/.ssh; put identity.pub 4.) On remotehost:mv ~user/.ssh/identity.pub authorized_keys ==================================================================== Note: When you run ssh-keygen it creates a key in the ~/.ssh/identity.pub file that you then copy to your local authorized_keys file. You can simply cut/paste the key into the authorized_keys file on the box you want to log into. Make sure you watch the key pasting - you want a continuous line/line wrap and not 3 or four separate lines (look for end-of-line). ==================================================================== ssh via alternate ports port 80 on localhost to 8080 on remote host ssh -N -L 8080:localhost:80 x.x.x.x ssh via a proxy on port 80 on localhost to 8080 on remote host ssh -N -l proxy-user -L 8080:localhost:80 x.x.x.x ==================================================================== Cyclades-TS Ssh is a command interface and protocol often used by network administrators to connect securely to a remote computer. Ssh replaces its non-secure counterpart rsh and rlogin. There are two versions of the protocol, ssh and ssh2. The Cyclades-TS offers both. The command to start an ssh client session from a UNIX workstation is: ssh -t @ = :ttySnn or :socket_port or :ip_addr or :serverfarm Note: serverfarm is a physical port alias. It can be configured in the file pslave.conf. An example: username: cyclades TS1000 IP address: 192.168.160.1 Appendix A - New User Background Information User Guide 218 host name: ts1000 servername for port 1: file_server ttyS1 is addressed by IP 10.0.0.1 or socket port 7001. The various ways to access the server connected to the port are: ssh -t cyclades:ttyS1@ts1000 ssh -t cyclades:7001@ts1000 ssh -t cyclades:10.0.0.1@ts1000 ssh -t cyclades:file_server@ts1000 ssh -t -l cyclades:10.0.0.1ts1000 ssh -t -l cyclades:7001 ts1000 For openssh clients, version 3.1p1 or later ssh2 is the default. In that case, the -1 flag is used for ssh1. ssh -t cyclades:7001@ts1000 (openssh earlier than 3.1p1 - Cyclades-TS V_1.3.1 and earlier -> ssh1 will be used) ssh -t -2 cyclades:7001@ts1000 (openssh earlier than 3.1p1 - Cyclades-TS V_1.3.1 and earlier -> ssh2 will be used) ssh -t cyclades:7001@ts1000 (openssh 3.1p1 or later - Cyclades-TS V_1.3.2 or later/AlterPath Console Server version 2.1.0 or later -> ssh2 will be used) ssh -t -1 cyclades:7001@ts1000 (openssh 3.1p1 or later - Cyclades-TS V_1.3.2 or later/AlterPath Console Server version 2.1.0 or later -> ssh1 will be used) To log in to a port that does not require authentication, the username is not necessary: ssh -t -2 :ttyS1@ts1000 Note: In this case, the file sshd_config must be changed in the following way: PermitRootLogin Yes PermitEmptyPassword Yes Configuring sshds client authentication using SSH Protocol version 1 Step 1: Only RhostsAuthentication yes in sshd_config. One of these: hostname or ipaddress in /etc/hosts.equiv or /etc/ssh/ shosts.equiv hostname or ipaddress and username in ~/.rhosts or ~/.shosts and IgnoreRhosts no in sshd_config Client start-up command: ssh -t (if the ssh client is running under a session belonging to a username present both in the workstations database and the TSs database). Client start-up command: ssh -t -l (if the ssh client is running under a session belonging to a username present only in the workstations database. In this case, the indicated would have to be a username present in the TSs database). Step 2: Only RhostsRSAAuthentication yes in sshd_config. One of the RhostsAuthentication settings, described in Step 1. Client machines host key ($ETC/ssh_host_key.pub) copied into the TS/tmp/ known_hosts file. The client hostname plus the information inside this file must be Note: For security reasons, some ssh clients do not allow just this type of authentication. To access the serial port, the TS must be configured for local authentication. No root user should be used as username. appended in one single line inside the file /etc/ssh/ ssh_known_hosts or ~/.ssh/ known_hosts and IgnoreUserKnownHosts no inside sshd_config. The following commands can be used for example: echo n client_hostname >> /etc/ssh/ssh_known_hosts or ~/.ssh/ known_hosts cat /tmp/known_hosts >> /etc/ssh/ssh_known_hosts or ~/.ssh/ known_hosts client start-up command: ssh -t Step 3: Only RSAAuthentication yes in sshd_config. Removal of the TSs *.equiv, ~/.?hosts, and *known_hosts files. Client identity created by ssh-keygen and its public part (~/.ssh/identity.pub) copied into TSs ~/.ssh/authorized_keys. Client start-up command: ssh -t . Step 4: Only PasswdAuthentication yes in sshd_config. Removal of the TSs *.equiv, ~/.?hosts, *known_hosts, and *authorized_keys files. Client startup command: ssh t -l or ssh t l . Configuring sshds client authentication using SSH Protocol version 2 Only PasswdAuthentication yes in sshd_config DSA Authentication is the default. (Make sure the parameter PubkeyAuthentication is enabled.) Client DSA identity created by ssh-keygen -d and its public part (~/.ssh/id_dsa.pub) copied into the TSs ~/.ssh/authorized_keys2 file. Note: client_hostname should be the DNS name. To access the serial port, the TS must be configured for local authentication. No root user should be used as username. Password Authentication is performed if DSA key is not known to the TS. Client start-up command: ssh -2 -t . Note: All files ~/* or ~/.ssh/* must be owned by the user and readable only by others. All files created or updated must have their full path and file name inside the file config_files and the command saveconf must be executed before rebooting the TS. ====================================================================