Relay-Version: ANU News - V6.2.0 06/23/97 OpenVMS VAX; site news.bofh.se Path: news.bofh.se!levitte Newsgroups: comp.os.vms Subject: Re: RELEASE: FISH 0.1, a SSH client for VMS Message-ID: <LEVITTE.98May8053005@nic.bofh.se> From: levitte@lp.se (Richard Levitte - VMS Whacker) Date: 08 May 1998 03:30:05 GMT References: <LEVITTE.98May5165940@nic.bofh.se> <6it8pd$hhg@milo.mcs.anl.gov><LEVITTE.98May8035826@nic.bofh.se> Distribution: world Organization: Levitte Programming Nntp-Posting-Host: ns.bofh.se In-reply-to: levitte@lp.se's message of 08 May 1998 01:58:26 GMT MIME-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-URL: http://www.lp.se/~levitte/ X-PGP-Key-ID: Length=1024; ID=0xB2DEE2AD X-PGP-Key-Fingerprint: A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 X-PGP-Key-URL: <http://www.lp.se/~levitte/pubkey1.asc> X-Date-Of-Birth: Setting Orange,the 63rd day of The Aftermath in the YOLD 3130 X-Waved: dead chicken, dms-sig 2.2 RL1 (enhanced), rl-head 1.01 Lines: 138 In article <LEVITTE.98May8035826@nic.bofh.se> levitte@lp.se (Richard Levitte - VMS Whacker) writes: Right! I wonder when I'll learn... Well, this'll teach me to start blabbering (sp?) at 2am when I'm on the verge of falling asleep... So, I need to correct myself, sorry. According to the aaareadme.txt, rsa key exchange is not used, Actually, what AAAREADME.TXT says is the following: [...] Some areas of enhancement might be: [...] * RSA key authentication Note that RSA key authentication and RSA key exchange is not really the same thing. According to the Internet draft (draft-ylonen-ssh-protocol-00.txt, from May 1996 (does anyone know if anything newer is around, I can't seem to find it anywhere anymore...), this is what happens directly after the client and the server have verified (through version numbers) that they talk the same language: The first message sent by the server using the packet protocol is SSH_SMSG_PUBLIC_KEY. It declares the server's host key, server pub- lic key, supported ciphers, supported authentication methods, and flags for protocol extensions. It also contains a 64-bit random number (cookie) that must be returned in the client's reply (to make IP spoofing more difficult). No encryption is used for this message. Both sides compute a session id as follows. The modulus of the server key is interpreted as a byte string (without explicit length field, with minimum length able to hold the whole value), most signi- ficant byte first. This string is concatenated with the server host key interpreted the same way. Additionally, the cookie is con- catenated with this. Both sides compute MD5 of the resulting string. The resulting 16 bytes (128 bits) are stored by both parties and are called the session id. The client responds with a SSH_CMSG_SESSION_KEY message, which con- tains the selected cipher type, a copy of the 64-bit cookie sent by the server, client's protocol flags, and a session key encrypted with both the server's host key and server key. No encryption is used for this message. The session key is 32 8-bit bytes (a total of 256 random bits gen- erated by the client). The client first xors the 16 bytes of the session id with the first 16 bytes of the session key. The resulting string is then encrypted using the smaller key (one with smaller modulus), and the result is then encrypted using the other key. The number of bits in the public modulus of the two keys must differ by at least 128 bits. At each encryption step, a multiple-precision integer is constructed from the data to be encrypted as follows (the integer is here inter- preted as a sequence of bytes, msb first; the number of bytes is the number of bytes needed to represent the modulus). The most significant byte (which is only partial as the value must be less than the public modulus, which is never a power of two) is zero. The next byte contains the value 2 (which stands for public-key encrypted data in the PKCS standard [PKCS#1]). Then, there are non- zero random bytes to fill any unused space, a zero byte, and the data to be encrypted in the least significant bytes, the last byte of the data in the least significant byte. This algorithm is used twice. First, it is used to encrypt the 32 random bytes generated by the client to be used as the session key (xored by the session id). This value is converted to an integer as described above, and encrypted with RSA using the key with the smaller modulus. The resulting integer is converted to a byte stream, msb first. This byte stream is padded and encrypted identi- cally using the key with the larger modulus. After the client has sent the session key, it starts to use the selected algorithm and key for decrypting any received packets, and for encrypting any sent packets. Separate ciphers are used for dif- ferent directions (that is, both directions have separate initializa- tion vectors or other state for the ciphers). When the server has received the session key message, and has turned on encryption, it sends a SSH_SMSG_SUCCESS message to the client. [...] So, the conclusion is that the session key is encrypted using the server RSA keys, so contrary to what I said before, the session key is *not* passed around in the clear. The RSA authentication is a different matter, and comes right after in the protocol (uhmmm, OK, the username is declared to the server before that :-). It is one of 4 possible methods for the server to verify that the user in question may enter. These methods are: SSH_AUTH_RHOSTS 1 .rhosts or /etc/hosts.equiv SSH_AUTH_RSA 2 pure RSA authentication SSH_AUTH_PASSWORD 3 password authentication SSH_AUTH_RHOSTS_RSA 4 .rhosts with RSA host authentication The only method supported by FISH today is SSH_AUTH_PASSWORD. This is what the draft has to say about it: SSH_AUTH_PASSWORD The client sends a SSH_CMSG_AUTH_PASSWORD message with the plain text password. (Note that even though the password is plain text inside the message, it is normally encrypted by the packet mechanism.) The server verifies the password, and sends SSH_SMSG_SUCCESS if authentication was accepted and SSH_SMSG_FAILURE otherwise. Note that the password is read from the user by the client; the user never interacts with a login program. This authentication method does not trust the remote host, the network, name services or anything else. Authentication is based solely on the possession of the password. Anyone in pos- session of the password can log in, but nobody else. I've verified that the code actually does all this. (despite needing rsa routines to satisfy the link). I guess the real reason is apparent now :-). -- NEWBIE! read and heed the Guidelines on Posting: http://www.lp.se/~levitte/docs/post_hlp.html --- R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://richard.levitte.org/ for my public key. bastard@bofh.se "price, performance, quality. Choose any two you like"