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"