Remote Access

To access a remote site with SSH public key authentication We highly recommend that for users logging into their Cambridge account from a remote site they use ssh, rather than telnet. As a result of telnet's vulnerability we have we have disabled telnet access from outside Cambridge to any machine in the IoA Science Cluster. Most of the Sun workstations do not accept incoming ssh protocol 1 connections, only ssh protocol 2 connections.

Telnet will send your password in clear text across the Internet, and hence is vulnerable to any network sniffers installed by a hacker on a network through which your telnet connection passes. It is quite certain that this already happened to a number of local users when logging in from Chile or Hawaii. With the sniffed password, the hacker was able to log into our site and place network sniffer on the local network and begin capturing many more passwords. A remote host running ssh can be accessed with:

ssh remote_host

where remote_host is the fully qualified host name (e.g. for host mraos this is mraos.ra.phy.cam.ac.uk), or its IP number. This command assumes that you have the same username on both systems, but in the case where this is not so:

ssh -l remote_username remote_host

where remote_username is obviously your username on the remote host. Note, if this is your first access to the remote host, then you're unlikely to have its public key, and hence ssh will inform you of this e.g. The authenticity of host 'mraos.ra.phy.cam.ac.uk (131.111.48.8)' can't be established. RSA key fingerprint is 5c:5b:17:2f:55:57:be:3e:04:41:90:62:2f:2a:ac:97. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'mraos.ra.phy.cam.ac.uk,131.111.48.8' (RSA) to the list of known hosts. The public key of the remote host has been added to the file ~/.ssh/known_hosts in your account. As a result this message will not be displayed in future ssh connections to this host. As shown in a section above, you can generate your own public key(s) between your different accounts using ssh-keygen, and overcome the problem regarding the lack of the public key of the remote host. Copy the newly generated public key from the account on one system to the ~/.ssh/authorized_keys file on the other. Transfering public keys between accounts can simply be done via email, as the public key (e.g. ~/.ssh/identity.pub for ssh 1 protocol) is just a long line of text, which can then be extracted from the mail message (make sure to preserve its line length) and added to the appropriate file.

Using sftp sftp, and scp (discussed below) both come into their own for file transfers between user accounts at different institutions. sftp (Secure File Transfer) is a ftp-like client that runs over an ssh tunnel, and that can be used in file transfer over the network. It does not use the FTP daemon (ftpd or wu-ftpd) for connections, allowing a significant improvement in the system security. sftp does not support anonymous logins. A user account is required on the remote end. sftp and scp do not require any dedicated daemon since the two programs connect to sshd servers. Let's suppose that you would connect via sftp to your account myname on host1. In order to do that use the command:

sftp myname@host1

When sftp is ready to accept commands, it will display a prompt sftp>. In the sftp manual page there are a complete list of the commands which the user can use: quit Quits from the application cd directory Changes the current remote working directory. lcd directory Changes the current local working directory. ls [ -R ] [ -l ] [ file ... ] Lists the names of the files on the remote server. lls [ -R ] [ -l ] [ file ... ] Same as ls, but operates on the local files. get [ file ... ] Transfers the specified files from the remote end to the local end. Directories are recursively copied with their contents. put [ file ... ] Transfers the specified files from the local end to the remote end. Directories are recursively copied with their contents. mkdir dir (rmdir dir) Tries to create (destroy) the directory specified in dir. e.g. while logged into cass06 get /etc/inet/hosts from cass56: cass06% sftp cass56 Connecting to cass56... username@cass56's password: sftp> pwd Remote working directory: /home/username sftp> cd /etc/inet sftp> pwd Remote working directory: /etc/inet sftp> ls ... -rw-r--r-- 1 root other 140 Jan 14 09:42 hosts ... sftp> get hosts Fetching /etc/inet/hosts to hosts sftp> lls hosts

sftp> quit

When things go wrong server key changed If you see something like @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the host key has just been changed. Please contact your system administrator. Add correct host key in /home/usernme/.ssh/known_hosts to get rid of this message. Agent forwarding is disabled to avoid attacks by corrupted servers. X11 forwarding is disabled to avoid attacks by corrupted servers. This indicates that the host public key that your client believes is valid for the server you're trying to connect to doesn't match the host key that the server is using. As the message indicates, it either means someone is trying to subvert your connection, or that a system administrator has for some reason changed the host key for the server. You should at this point contact the administrator of the server in question to find out what is happening. server key not yet known If you see something like Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? this just means that your client doesn't yet know a host key for the server you're connecting to. If you believe it is unlikely that anyone is going to choose precisely this time to attempt to intercept and spoof your attempt to connect to the server in question, then saying yes at this point will result in the server host public key being added to your (but not the client machine's) list of known hosts. ssh or sftp connection is closed by remote site after 30-60 minutes Some sites run a version of ssh that periodically forces another run of the key-exchange phase, and this attempt to rekey kills the connection from Sun's SSH. You may get a message such as: dispatch protocol error: type 20 plen 140 If you run into this problem, which may prevent you from transferring large files, try using the OpenSSH client (openssh or opensftp), as the rekeying message is not sent to OpenSSH clients. anything else If you find any other misfeatures in the installed ssh programs please contact helpdesk, giving as much detail as possible.