CS Dept SSH Frequently Asked Questions

  1. I followed the directions and it didn't work. What should I do?

    Check the following:

    • Is your ~/.ssh/authorized_keys file writable only by your user (i.e. 644 permissions)? If your ~/.ssh directory writable only by your user (i.e. 755 permissions)? Note that group writability on these files is not permitted by ssh.

    • Did you cut & paste the public entry when you copied it into ~/.ssh/authorized_keys? Each entry in that file must be on a single line. Delete any extra newlines and try again.

    • If your remote machine is a unix or linux machine:

      • The private key must be in a file named id_rsa, or else you must tell ssh where it is (using the -i option). Note that this file must be readable only by your user (i.e. 600 permissions).
  2. Can I use ssh1 to connect to the department?

    No, ssh1 has been disabled. Please use ssh2.

  3. Can I use ssh2 to connect to the department?

    Yes, in fact ssh1 is no longer supported.

  4. How do I transfer files to/from the department using ssh?

    Use scp. Rsync and cvs also know how to use an ssh connection to transfer files. There are probably other choices, too.

  5. What machine(s) should/can I connect to?

    The only machine you can connect to from outside the department is ssh.cs.brown.edu. This machine is a dedicated portal to reach into the department via ssh.

  6. How can I ssh between machines?

    Just as you need a ssh key to ssh from outside the department through ssh.cs.brown.edu to your machine of choice, you must also authenticate yourself when sshing between departmental machines. One way to authenticate yourself is with a Kerberos ticket. You obtain Kerberos tickets by logging in to any Linux machine, unlocking a screensaver, or running the kinit command; once you have a Kerberos ticket, you can ssh between departmental machines without entering passwords. Kerberos tickets expire after 8 hours.

  7. Warning Message: Authenticity of Host can't be established
  8. The first time you connect to a host via ssh, where the login requires a passphrase for authentication, you will see a message similar to:

     $ ssh bosch
     The authenticity of host 'bosch (' can't be established.
     RSA key fingerprint is 9f:b7:5c:51:b7:37:b0:5e:d2:18:bf:02:b9:6a:1a:3b.
     Are you sure you want to continue connecting (yes/no)?

    This is just a warning message stating that the host is unknown. If you are sure that the host you are connecting to is correct, then type "yes" to continue connecting. It should then print a warning similar to:

     Warning: Permanently added 'bosch,' (RSA) to the list of
     known hosts.

    By typing yes above, you are telling the machine to add the remote host to your collection of known hosts. You should only see this warning once per host, during the initial ssh connection. The next time you connect, you will just be prompted for your passphrase.

  9. I used to be able to connect, but now get an error message
  10. A machine's host_key is generated at install time. Hence, whenever we need to re-install a machine in the department, its host_key is going to change. If you have connected the recently re-installed machine in the past, then you will probably get an error similar to

     Someone could be eavesdropping on you right now (man-in-the-middle attack)!
     It is also possible that the RSA host key has just been changed.
     The fingerprint for the RSA key sent by the remote host is
     Please contact your system administrator.
     Add correct host key in /home/jcarberr/.ssh/known_hosts to get rid of this message.
     Offending key in /home/jcarberr/.ssh/known_hosts:34
     RSA host key for cslab9a has changed and you have requested strict checking.
     Host key verification failed.

    The line stating "Offending key in /home/jcarberr/.ssh/known_hosts:34" provides the key to solving this problem. In this case, you should delete line 34 in the file "/home/jcarberr/.ssh/known_hosts". This is the old host_key and ssh will not let you connect when it has conflicting host information. After deleting line 34, you should try connecting again. This time, you should be prompted to accept the remote host's key. Once you accept this key, you should be able to connect and will not be prompted to save the key on future connections.

    If this does not work, try the following:

    His /u/rt/.sshhost was putting him specifically on plato so I remove it so he could just ssh ssh. If he wanted to then get to plato he should do this:

     ssh -t ssh host=plato

  11. ssh keys are set up, but I still can't connect
  12. Problems with ssh can be tricky to hunt down, as the error messages can be somewhat cryptic at times. Here are some hints which may help you resolve your connection problems:

    • SSH is very particular about directory and file permissions. On the remote end (the department machine, most likely) you need to ensure:
      • Your home directory is not group writable (i.e. chmod ~/ to 700, or 750, or 755)
      • Your .ssh directory is not group writable (i.e. chmod ~/.ssh to 700, or 750, or 755)
      • Your authorized keys file is not group/world readable (i.e. chmod ~/.ssh/authorized_keys to 600)
    • You need to be careful about the username being used to authenticate yourself. If you're logged into the local machine as user "josiah" and your account on the remote machine is "jcarberr", you will need to tell ssh to log in as jcarberr" on the remote machine. You will still authenticate against the "josiah" public key you placed in the "jcarberr" ssh authorized_keys file. This becomes a particular issue when people are connecting from Windows machines either from the administrator account or a default user account that shipped with the computer. You can tell ssh to log in as a different user by giving it the "-l <username>" flag. See your ssh man page if you need more information.