This article is composed of the following sections:
ssh and slogin are replacements for the traditional rsh and rlogin commands that implement RSA-based authentication for network connections.
ssh by default uses a 768-bit host key and a 1024-bit user key that provides an extremely strong and secure authentication, to ensure that both ends of a connection really are who they say they are.
ssh also allows one working over a slow or lossy link to initiate gzip-style compression in order to speed the transfer of data.
As a general rule, rhosts-style authentication is insecure except on closely-controlled and isolated networks, and it is never truly secure. ssh, on the other hand, uses RSA-style authentication - the sort that netscape and the government uses. This makes IP spoofing (falsifying information about the source of a network connection) impossible because the client must answer a challenge from the server based upon its 'public key' in order to gain access to the server.
The key method is virtually unbreakable; in a project a few years ago with Iowa State University, a cryptography expert used 1500 workstations working together to factor a 428-bit key. This process took about nine months to complete. Each time one adds 4 bits to a key, the time to factor the key nearly doubles. Since ssh uses a 768-bit key, it would take 100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years - such that by the time anyone decrypts a particular key, the two computers used in the transaction, UCSD, and human civilization will have crumbled to dust. }:>
Anyone who's used rsh or rlogin before can use ssh with no learning curve. In order to connect from one host to another, one simply replaces the 'rsh' or 'rlogin' command with 'ssh' or 'slogin':
sdcc12 % ssh somehost
It accepts the same flags to specify a different username (say, dalv):
sdcc12 % ssh somehost -l dalv
If you're using a slow link, you can turn on compression with the -C switch:
sdcc12 % ssh -C somehost -l dalv
Once ssh establishes the connection, it will ask for your password:
sdcc12 % ssh somehost -l dalv dalv's password:
And once you type in the correct password and hit return, it will let you in. You've now established a secure, encrypted connection to the remote host (in this case, somehost.ucsd.edu) from your machine.
If this is the first time you've connected to somehost from this machine, it will display the following:
sdcc12 % ssh somehost -l dalv Host 'somehost' added to the list of known hosts. Creating random seed file ~/.ssh/random_seed. This may take a while.
The random seed file is used to calculate the encryption strings on your end of the connection. This will be displayed the first time you use ssh on a particular machine.
In this example, since this is the first time sdcc12 has connected to 'somehost', it stores the public host authentication key for 'somehost' into your personal file of known hosts. The next time you connect to 'somehost', ssh will issue a challenge to 'somehost' that it must answer correctly using its private identity file. If the host doesn't respond correctly, it means that the key information has somehow changed, and ssh will warn you of the discrepancy which might be due to a hacker setting up an imposter machine to pose as 'somehost'. This test ensures that you really are connecting to 'somehost', and not some hacker's machine between you and 'somehost'. (Assuming, of course that the first time you connected to 'somehost' you connected to the real somehost and got the real somehost's key, and that you didn't get a false key on the first connect.)
You can also use ssh just like rsh:
sdcc12 % ssh somehost -l dalv uptime dalv's password: 9:07pm up 11 days, 21:49, 19 users, load average: 0.38, 0.54, 0.44
This executes the 'uptime' command on the host 'somehost' as the user 'dalv'.
Note that some machines may not run ssh. If you try to use ssh to these machines, the program will automatically use rlogin/rsh, and will print a warning:
sdcc12 % ssh sdcc8 Secure connection to sdcc8 refused; reverting to insecure method. Using rsh. WARNING: Connection will not be encrypted. Password:
The functionality will be the same, but the connection will not be securely authenticated or encrypted.
With rlogin and rsh, one can set up a file called '.rhosts' in your home directory. In this file, one can put hostname/userid pairs of machines from which one can login. When one rlogins to this machine, then, one can get in without having to type a password:
sdcc12 % rlogin sdcc10 Last login: Tue Nov 26 10:19:37 from sdcc12.ucsd.edu SunOS Release 4.1.3_U1 (SDCC10 1.5) #1: Mon Oct 14 16:13:47 PDT 1996 sdcc10 %
However, this is inherently insecure because this relies on domain name service information and an IP address for authentication, both of which can be spoofed, or falsified, thus opening one's account to break-ins.
(Fortunately, machines at a local site or on a local network are somewhat more secure, simply because the routers that divide that segment of the network from another keep out spoofers. In an environment like UCSD's computer room, where access is extremely controlled 24 hours a day, it is very unlikely that a breakin of this nature could occur. However, on machines accessed from across the global internet, it is very possible and even likely to occur.)
ssh fixes this by using RSA-based host authentication. Intended as a full replacement for rsh and rlogin, ssh even supports the use of an rhosts-like file called '.shosts'.
(If you only have an '.rhosts' file, ssh will use this file exactly like it would use the .shosts file - except that rlogin and rsh, which ssh intends to replace, will also use that file, thus defeating the extra level of security. Also, please read the section on pure RSA authentication, as this may be a simpler method to set up rhosts-style logins-without-a-password.)
The format of the .shosts file is exactly like that of the .rhosts file, except that a few additional requirements must be met. First, though, the format of the file itself.
A sample .shosts file:
sdcc12 dalv sdcc13 dalv sdcc17 dalv dragonlair.dal.net dalv
If this file resided on ieng9, it would allow someone with the username 'dalv' to login to this account from any of sdcc12, sdcc13, sdcc17, or dragonlair.dal.net.
Because this is a favorite target of hackers, however, in order for this file to be accepted, one must perform two additional tasks: * Make sure that your home directory, the .shosts file, and the .ssh directory and files are writeable only by the user. * Verify that ieng9 has a host authentication key for sdcc12, sdcc13, sdcc17, and dragonlair.dal.net.
One can do the first by executing the following commands (on the *target* host):
ieng9 % chmod g-w,o-w ~ ieng9 % cd ieng9 % chmod 700 .ssh ieng9 % chmod 600 .shosts .ssh/*
The first command ensures that only the user can write to his/her home directory. The second ensures that the user is the only one with any access to the .ssh directory, and the third does the same for the .shosts file and any files in the .ssh directory.
After this has been done, one needs to make sure that ieng9 knows the host keys for the five hosts in the .shosts file. Depending on the system configuration, this may or may not have already been done.
By viewing the system 'known hosts' file using the command 'more /etc/ssh_known_hosts', one can verify that the hosts *from* which the ssh session will come can be identified by the target machine.
An entry for sdcc13.ucsd.edu, for example, will look like this:
sdcc13.ucsd.edu 1024 35 9476867275562487563709483772740383309755296835 7531448351782289106802688182094427331369506907299501704894788975203252078 771287265680161651556819549952708689761039573604860469939681262935652569 204095233404687846356661031061808977066614042574219382833635431351337244 089391206874050663379360766169063954314988591
(That long string of numbers is the host's public identity key, used to verify the host's identity.) If you find the source hosts in this file, the job is done, and rhosts with RSA authentication will work.
As ssh becomes more widespread use at UCSD, the host keys for most workstations and servers will be distributed to the system known hosts files, and installing the host keys manually (as seen in the next few paragraphs) will become virtually unnecessary.
For any hosts that are *not* listed in this system file, you will need to install a host key for each unlisted machine in your personal ~/.ssh/known_hosts file by ssh'ing *back* to each of the five hosts from ieng9, then exiting the shell:
ieng9 % ssh sdcc12.ucsd.edu dalv's password: Last login: Tue Nov 26 10:19:37 from sdcc17 SunOS Release 4.1.3_U1 (SDCC12 1.5) #1: Mon Oct 14 16:13:47 PDT 1996 sdcc12 % logout ieng9 % ssh iacs5.ucsd.edu dalv's password: [...]
ssh will put each of the unknown hosts' keys into the .ssh/known_hosts file, and will use this to authenticate the connection when the user sshs in. Note that when doing this, you need to use the entire name of each host - in other words, you must use sdcc12.ucsd.edu instead of sdcc12, iacs5.ucsd.edu instead of iacs5, etc.
And that's all! The user dalv can now ssh into ieng9 from any of sdcc12, sdcc13, sdcc17, or dragonlair.dal.net without having to type in a password.
One can also set up ssh to login without a password by creating and installing a personal RSA key that can be used to authenticate both a connection and a user securely without the need for a password. This method is easier and requires less work than rhosts-with-RSA- authentication.
Using this method of authentication requires two simple steps to set up: * Generating a personal RSA key with 'ssh-keygen' * Distributing this key among the various target hosts
First, run 'ssh-keygen' on the machine FROM which the logins will be coming (this will be for the account 'abrayn' on ieng9):
ieng9 % ssh-keygen Initializing random number generator... Generating p: ...........................++ (distance 336) Generating q: .++ (distance 10) Computing the keys... Testing the keys... Key generation complete. Enter file in which to save the key ($HOME/.ssh/identity):
At this prompt, simply push 'return'. The key should be saved in the default file.
Enter passphrase: Enter the same passphrase again:
At this set of prompts, one may enter a passphrase used to activate the key. Doing so, however, makes it so that one must enter this passphrase each time one uses ssh to get to a target machine, and defeats the convenience of being able to get to other machines without a password. It does, however, increase the security - if one is paranoid, using a passphrase might be a good idea.
To use a key without a passphrase, simply hit return at the two passphrase prompts.
The program then prints:
Your identification has been saved in /home/solaris/oce/abrayn/.ssh/identity. Your public key is: 1024 37 730424662526414281339086750022538462553259901525707720154402047424 7197937876197866923886632751633508582464057373146071686964039491372131686576 047921179303084370018200284103795944556001828575921188635306649448153009255 5604976760582142584621320360689907006570124515950157397815124036087880055391 094643244472871 firstname.lastname@example.org Your public key has been saved in /home/solaris/oce/abrayn/.ssh/identity.pub
This completes the first step, key generation. In the next step, the key shown above (and contained in ~/.ssh/identity.pub) needs to be distributed to the file ~/.ssh/authorized_keys on the remote hosts.
This can be done by 'scp' or ftp - use this method if the source key is the only one which will be in the target host's authorized_keys file:
ieng9 % scp ~/.ssh/identity.pub abrayn@sdcc10:~/.ssh/authorized_keys abrayn's password: ieng9 %
(The '~/.ssh' directory must exist on sdcc10 beforehand; it can be made with the command 'ssh sdcc10 mkdir .ssh')
It can also be done by editing the file .ssh/authorized_keys with a text editor such as vi, emacs, or pico and simply pasting the key, ensuring that the key is contained on one line and does not wrap (i.e. there must be no returns in the middle of the key). This method should be used if there will be more than one source host that will ssh into the target account. For example, on the machine delivery.dal.net, the login name 'dalv' has the following .ssh/authorized_keys:
1024 37 139138116986620484[...]6142758206500869 email@example.com 1024 37 962036397358770606[...]2436464402257743 firstname.lastname@example.org
(keys truncated for the sake of brevity)
This file enables both someone coming from the account 'dalv' on the machine dragonlair.dal.net and someone coming from the account 'abrayn' on the machine sdcc12.ucsd.edu to login to the account 'dalv' on the machine delivery.dal.net without a password.
After distributing the keys, one can then use ssh to login to the remote machines using pure RSA authentication. Based on the public key in authorized_keys, the target machine sends a challenge to the source machine that can only be answered properly if the source has access to the appropriate private key counterpart (stored in .ssh/identity).
Mac OS X comes with a SSH client pre-installed.