How to Enable Logins Via SSH on titanium Jon Bell, 4 July 2003 ---------------------------------------- This document attempts to give you enough information to decide which authentication method to use for SSH logins on titanium, and instructions for installing public keys for public-key authentication. Background ---------- SSH logins can use either the account password or a public/private key pair for authentication. When you connect with an SSH client to a server that has an SSH daemon running on it, the following steps happen: 1. The server sends its "host key" (public key for the server itself) to the client, which compares it against the collection of host keys that it has stored as being safe to connect to. If the client doesn't have this host key, it warns you and asks you if you want to accept it. The idea here is that if you're paranoid about the possibility that some hacker might divert your initial connection to a different server, you can get the host key beforehand via some other mechanism (snail mail, trusted courier, etc.) and install it into the client yourself. If you're reasonably sure that you're really connecting to the server you think you're connecting to, simply accept the key, and that will validate future connections to the same server. 2. The client and server set up an encrypted channel for all communications between them during the rest of this session. 3. The client now attempts to log you into the desired account on the server. First, if you have set up a personal public/private key pair on your machine, and the server has a copy of your public key in the desired account, the server logs you in, and you now have access to that account. For this to work, the account owner or server administrator has to install your public key in the account beforehand. 4. If you *don't* have a public/private key pair on your machine, or if the desired account doesn't have a copy of your public key, the client asks you for the password to that account. If you know the password, it's safe to send it this way, because it's encrypted during transmission. If the password is correct, the server logs you in. 5. Either way, after you have logged in, all communication between you and the server is still encrypted, so nobody can peek at it and get useful information from it. Which Authentication Method? ---------------------------- It seems to me (I'm open to discussion!) that the following guidelines are plausible: 1. If the account is going to be used by just one person, and that person can receive the password via some secure means, then it's reasonable to use password authentication and not bother with public/private keys. The person just has to take normal care with the password, i.e. not write it down anywhere it can be associated with the account. Using public-key authentication does mean you don't have to enter your password every time you log in, but then you have to make sure nobody else can get at your computer and use it to log onto the server. For example, you can set up your computer so that you have to log onto it with a password; or you can keep it physically secure (lock the door to your office or room whenever you're not in it). 2. On the other hand, if more than one person may need to use the account, or if it's not easy to give someone the password securely, then it's reasonable to use public-key authentication. If more than one person uses the account, there's no hassle with having to notify them all if the password changes (because they don't need the account password at all). It's also easy for the account owner or server administrator to deny access to one or more of the account users without affecting the others; simply remove the corresponding public keys from the account. With public-key authentication, there's no security hassle with transmitting the account password to someone who wants to use the account (because he/she doesn't need the password), nor with transmitting the user's public key to the account owner or server administrator (because the public key is by definition publically knowable). Installing Public Keys for SSH Logins ------------------------------------- In the account's home directory, create a subdirectory named .ssh if there isn't one already: mkdir .ssh It should have the usual ownership and permissions for user directories. In that directory, you need to create a file named authorized_keys which contains the public keys of the people who are allowed to log in via SSH public-key authorization. Someone who wants to log in needs to give you his/her public key in "export format." The following example is my public key from my home computer. The BEGIN and END lines are part of the format. ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit DSA, converted from OpenSSH by jtbell@Jon-Bells-Computer.local." AAAAB3NzaC1kc3MAAACBAPNgmidbM2rhYjUXunpnlXjHWfV+vc8/5YKrn8Y5P0Y6KwmG2G GMgNBon3LX3iJlBhtuU3FCBj3G1Kdt5vUhQHhUmHVrOasi47vawTrv7ZJCfiaSGwRsiBHt Jta5CAp7t0EnzX2q6BvPbFBBHNLyy6uNVpL2jOR06Pkx/vaqyScvAAAAFQDHvwmjWYwK9g K6Sp+pSvI7bwEUtwAAAIANMJDotMpfj89N+7+FJylSS+uFEQSS61PxENl/Mcj1jUREjJg2 eNsJdAB9Ev99hWYS+7lFRtTJ2eh4Y9gpGe7BX3e2YGHOqp8cWCVCIKaMzwk9To+xnfThWq IfHT8I6CJxp/5ez02m6F2k/5iukvOwbGms6EAZK1DTBhDOHjEQwQAAAIAlz2/qBWkaMP+s W8FLmGKM+cCw5+asOaJGTwrFVuwJkDMvdEWxmG92A2dxuUske0d/AkN6zJp7HD0wlfesRM 3+c+Res5qun9lFcdM4i03VoV5mXd+T7laS8yku6vZgvZZFnPvr2LOUnc7XThGFwMaQpFEW U8cvQbttO6QrT2CD2w== ---- END SSH2 PUBLIC KEY ---- You need to convert this into the normal format that is used in the authorized_keys file, using the ssh-keygen command. Here's how I usually do it: 1. Enter the .ssh directory. cd .ssh 2. Create a file containing the key in export format, as given to you by the person who wants to log in. I usually use pico and copy/paste the key into my terminal window, but you can also ftp it over or whatever. For this example I'll call it exportkey.txt. 3. If there is no authorized_keys file already, create one using pico, containing a comment describing the key you're about to add (e.g. who owns it). Comment lines begin with a # character. Blank lines are also OK. If the file already exists (e.g. you're adding another key to it), edit it and put the new comment at the end. Be careful not to break the lines containing the keys that are already in the file! Each key is a single long line. 4. "Import" the key to normal format and append it to the authorized_keys file: ssh-keygen -i -f exportkey.txt >> authorized_keys Make sure you use >> which appends to the file, not > which overwrites the existing contents! 5. Inspect the authorized_keys file and make sure the new key got into it OK. I've appended an example of an authorized_keys file, from my own account on titanium. Logging In ---------- The person whose key you've just added should now be able to log into that account using his/her SSH client, without being asked for the account password. How to do this depends of course on the specific client software being used. From a Unix or Linux system for example, I can log into my account on titanium with ssh jtbell@titanium.presby.edu If the user *does* get asked for the account password (as opposed to the passphrase which he/she may have set for hie/her own private key), something is wrong. Check the authorized_keys file. You may need to edit it to delete the bad key and try importing/appending it again. Sample authorized_keys File --------------------------- This is the authorized_keys file in my account on titanium. It has entries for each computer that I log in from, because I have different public/private key pairs on each one. Note that each key is actually one long line, although it may appear to be broken into more than one line depending on what software you're viewing this with. (Or maybe they got broken when I pasted them in.) ------- paste ------- # Jon Bell's office computer ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAsyQ/ZOQqivsRbZze6bn3P63ZmlqiKD8sL/eqayqG9Mg5iONT/7F8ZX5XmOdDSoSNtlSeuHNgUo+ePenoQ/3w3gZqL922Dmqvi/XclTUh0rde82QBKz4GtnIUQO8Z4XHAya3ZNHW9DAQm8s7LXW/sObkNyqlFf0pz/MIsHKj8xmE= # Jon Bell's account on cs2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApwFQWa9G0FX7M+uSi8ipny0+C14lPFZtdFLj2rT5FNbUcat6BNswFt4Ys97celZ1HiuMGjyAIPDO1B290SSXGOWV/hwhNlMG080yjXbj0BC/5qNim9eDXJHqq0knFbIsHvcOZ9SepVp9q6SuqXuSQ6AXmMed3ZRm2ig7DiqDHVM= # Jon Bell's home computer (G3) ssh-dss AAAAB3NzaC1kc3MAAACBAKIS7gxEZ979usZaftnPgHizor4tQsaeba+wYfNp7fqM1D9yUf04Nz/dTVoLhgSNsrQpUBp28pdPB3O2/yR4Ep6xx4LpkvWgGt/8D1rnsRK8D6GdriPdwJWhcvQJjXK+oZA4JQGSZBoOtE0tijwERpBForsetqkpPG63jtk46AkfAAAAFQDU47mmJamJostXSwVbB6Mu9NUDvQAAAIBfApAvFa1rGumLJcM MgHVVc0fkh5/dEYwXGayJ+gurztdJTKw1gWjZ4CKfJq8A6Pe4cZcPcYMrBRF5bIHfjnqWGQ7vU1Xc0s5mBd/H8mK8GOZH/VKjF0Y4PhyVu1ongnQ6vkOAlPqSaywr1m09i8VYT1KpKcXR2ArSjVsUBggmFAAAAIBo9KM0RRrNxIoQX9sPFSkw7e4XD7HJ9RfBkMVclPzR6dhqNGtnPyJXE6AAcV+tvO58S8oHA4c4ffMJLP3Y31c6ntk9IfRNOt fUu7Qjc874iDAlqrWzjj7DZakjyVK4bcyd7zX7TE0eZMXzbf0ISWE0RF5zE3mTH4NUt6xOPspVng== # Jon Bell's home computer (G4/OS9) ssh-dss AAAAB3NzaC1kc3MAAACBAMwQmH+3mh86h0eTxfghjxDdToEetayiEv+CeaZ6d9rKyQyYVlkJFmaD1LI9YpEVAeDi4CCUrYfRyF56p7wBOdjiwXW8rdSvcqPMMVE4Gfcp6JhrGmjxIK+oStYDmu7GH3CIUTJU9urQh5kN+CfCTsRv+r1HPTcU/U70yH/3i423AAAAFQDiTcFNE/1ZjPRqAykOsHueYd5iJQAAAIEAgK3AXFpE7lVoVdJ tVdKMWNZb34RZZk/tThxXihCINw3O+1iszg7ae1Y6NMH/Kvib6u8CzkAfz970nopQyWLoOE7EabPso1Ay0JH/N21R1oWOjKPbWtlOZdRMGqsTp9hNvtSbLyqzNULQLBkCddRRQgFBsegS1dGfgyof3sjLJ48AAACAYKnfJcDDOlPKTxwd9/0RR5aLufbKG58zwVxHwsy5mnB313zEAKi2YtV8k7o+E6NgF9OwhVz+WB2tiFYvKs2qm/6p4mI2TS qF30TvQKEYBnCfBXk0S1YSahye2/qqJombLN/ALZKXU/5vkeMVg0oslBhg2Kk66NukD5cFnZNpq88= # Jon Bell's home computer (G4/OSX) ssh-dss AAAAB3NzaC1kc3MAAACBAPNgmidbM2rhYjUXunpnlXjHWfV+vc8/5YKrn8Y5P0Y6KwmG2GGMgNBon3LX3iJlBhtuU3FCBj3G1Kdt5vUhQHhUmHVrOasi47vawTrv7ZJCfiaSGwRsiBHtJta5CAp7t0EnzX2q6BvPbFBBHNLyy6uNVpL2jOR06Pkx/vaqyScvAAAAFQDHvwmjWYwK9gK6Sp+pSvI7bwEUtwAAAIANMJDotMpfj89N+7+ FJylSS+uFEQSS61PxENl/Mcj1jUREjJg2eNsJdAB9Ev99hWYS+7lFRtTJ2eh4Y9gpGe7BX3e2YGHOqp8cWCVCIKaMzwk9To+xnfThWqIfHT8I6CJxp/5ez02m6F2k/5iukvOwbGms6EAZK1DTBhDOHjEQwQAAAIAlz2/qBWkaMP+sW8FLmGKM+cCw5+asOaJGTwrFVuwJkDMvdEWxmG92A2dxuUske0d/AkN6zJp7HD0wlfesRM3+c+Res5qun9 lFcdM4i03VoV5mXd+T7laS8yku6vZgvZZFnPvr2LOUnc7XThGFwMaQpFEWU8cvQbttO6QrT2CD2w== ------ end paste ------