|
|
Last update:
Sat Sep 24 06:47:07 2005
Wed Oct 5 17:14:41 2005
Wed Aug 23 18:33:24 2006
Wed Aug 30 17:30:46 2006
Fri Sep 15 18:25:55 2006
Wed Sep 7 15:41:27 2016
How do I login from local machines?
On all local workstations, you should find a login screen requesting username and password.
On SunRay clients (identified by a small book-size box, with a SmartCard reader, standing vertically in a translucent plastic base beside the display), the password box is shown only after entering a valid username. The default login host can be changed by following the menu path Options -> Remote Login. However, a connection made that way does not support access to SunRay devices, such as audio and USB ports.
How do I login from remote machines?
We do not permit remote logins to our systems from the older telnet, rsh, and rlogin programs, because their communications are insecure.
Instead, remote access to our systems requires a secure-shell client. On Unix systems, this is called ssh, and some also have the GNU version, lsh. You can initiate a session to a particular host like this:
% ssh username@xserver.math.utah.edu The authenticity of host 'xserver.math.utah.edu (...)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'xserver.math.utah.edu,....' (RSA) to the list of known hosts. username@xserver.math.utah.edu's password:
The hostname xserver.math.utah.edu is an alias for a circular list of several large multiprocessor IBM servers running CentOS GNU/Linux, and is our recommended host choice when a particular one is not required.
Once you have made a successful connection from a particular host, the host-authenticity query is suppressed in future sessions.
The secure-shell client sets up an encrypted channel between your machine and the remote system that you are logging into, doing so before any of your keystrokes are sent, preventing attackers along the network connection from seeing your traffic.
Please be aware that attacks are still possible between your keyboard and the local client, or from someone looking over your shoulder. In particular, a keyboard sniffer installed on a machine in an Internet café can record everything that you type, including usernames, passwords, bank account numbers, and credit-card numbers. Such environments should be considered completely untrustworthy, and avoided.
On Microsoft Windows systems, you may need to first download a secure-shell client:
NOTE: The formerly recommended SSH client for Windows (SSHSecureShellClient-3.2.9, from 2003) is now deprecated. The reason for this is that the supported ciphers and key exchange protocols that this client has available are deemed insecure.
The recommended secure-shell client for Windows is available from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
The WinSCP program is the current recommendation for transferring files between the department Unix/Linux servers and Windows computers and is available from http://winscp.net/.
Run the passwd command. You will be asked to enter your old password first, so that no one can change your password, should you leave a workstation session unattended. Then you will be asked to enter the new one twice, to guard against typing errors.
We strongly recommend that you change passwords only on our Sun systems. If you are unsure of what system you are logged into, run the command uname -o: it should display Solaris. The reason for this caution is that we have multiple operating systems, and the encrypted password formats on some of them are incompatible with others. A password change on a non-Solaris system could result in your being unable to login to some of our public machines.
Your new password should be at least eight characters long, contain only printable characters, and not appear in a dictionary (even non-English ones) or a telephone directory. You should never write it down, or allow a Web browser, e-mail viewer, or secure-shell client to record it for you. You should also change it periodically (e.g., every semester), or immediately if you suspect it may have been compromised. For help on choosing a hard-to-guess password, enter the phrase how to choose a password into your favorite Web search engine; there is plenty of advice available on the Web.
The password change propagates to the central file server, and that in turn sends it back out to all clients within a minute or so. Thus, for a short period after the change, your old password may still be in effect on other local machines.
If you have forgotten your password, please see a systems-staff member to get it reset to something new that you can remember.
Please remember that you are personally responsible for keeping your password secret, and it is a serious violation of University policy to share accounts or passwords. If your account is broken into, you may lose important work, and you may compromise the security of thousands of other users.
Why do X Window System applications fail to work?
If you are logging in from a system running a non-Unix operating system (e.g., Microsoft Windows), you need a secure-shell client that supports the X Window System; the cygwin system can do this. From Apple Macintosh systems, you need to install the optional X Window System support, and then click on the X11 icon before making the secure-shell connection.
The X Window System system is powerful, and allows the application, the window manager, and the display to be on as many as three separate machines. In order to determine where to send window-system output, you must identify the local machine (the one with the display, keyboard, and mouse). Thus, X Window System applications run on a remote machine require the DISPLAY environment variable to be set appropriately:
When the application and the display are on the same machine, the value of the DISPLAY variable is normally something like :0.0 (meaning, display 0 and screen 0).
With the csh and tcsh shells (most departmental login accounts use the latter shell), set it like this:
setenv DISPLAY :0.0
With the bash, ksh, sh, and zsh shells, set it like this:
DISPLAY=:0.0
export DISPLAY
When the two are on separate machines, DISPLAY is set to something like hostname:0.0 where hostname is the Internet hostname of the machine with the display.
When you connect with a secure-shell client, the setting is a bit more complex, since ssh needs to be told to tunnel X Window System traffic across a secure connection. On our local systems, this is done automatically, but on some systems, you may need to run ssh with the -X and -Y options to request tunneling of window-system traffic. The DISPLAY variable then is set automatically to something like localhost:89.0, where 89 is a port number that differs with each connection, and is thus not predictable.
If you always want X Window System support in your secure-shell sessions, set the variables ForwardX11 and ForwardX11Trusted to yes in /etc/ssh/ssh_config (the exact path may differ on some systems) if you have management privileges and want it to apply to all users on your machine, or else in your personal $HOME/.ssh/config file, with lines like
ForwardX11 = yes
ForwardX11Trusted = yes
How can I use abbreviated usernames and hostnames?
Within our local network, the .math.utah.edu suffix can omitted from hostnames. However, if you want to have alternate values for a username and hostname in secure-shell connections, you can set them in your personal $HOME/.ssh/config file. For example, suppose your local username is jones, but your username on a.very.long.name.example.com is u958748365zqdw. A configuration-file setting of
Host = me
Hostname = a.very.long.name.example.com
User = u958748365zqdw
would let you replace
ssh u958748365zqdw@a.very.long.name.example.com
with
ssh me
to connect to that host.
How do I repair a Mac OS X keychain?
It is common for some interactive applications, such as Web browsers, and the Apple Mac OS X operating system, to offer to save usernames, passwords, and other credentials, for access to both local and remote computing facilities. In general, while such actions are convenient for many users, they are probably a bad idea: compromise, or loss, of the credential storage results in compromise, or loss, of all of the account information stored there. A successful breakin on one machine can then easily lead to attacks against many others.
Mac OS X calls the credential storage facility a keychain, and if it gets out of sync, or your password is reset, you may be denied access to credentials stored there until you reauthenticate. Apple describes that procedure here. It requires knowing both old and new passwords, and the reauthentication described there simply moves keychain access to the new password.
The Keychain Access application is located in the Utilities folder. There are two keychains that matter to the user: Login and Local Items. Select the one which is causing the problem, then under the Edit menu, try Change Password for Keychain. If resetting the password to the user's login password doesn't solve the problem, under the File menu, select Delete Keychain. Deletion means that all saved credentials are forgotten, so you'll need to reenter them in the future when you find that you need them.
It is rare, but possible, that the keychain itself has been corrupted. If so, you may be able to recover a recent working copy from a filesystem snapshot, as described here. The directory to be restored is the one named $HOME/Library/Keychains, where HOME is the standard Unix environment variable that records the pathname of your login directory.