Introduction User public key authentication S-tools Installation in FreeBSD 4.1 FreeBSD 4.x and SecureCRT in SSH2 mode
IntroductionDate: Fri, 24 Sep 1999 23:47:22 -0400 (EDT) From: David Ott
To: firstname.lastname@example.org Subject: ssh ssh (see http://www.ssh.fi/), version 2.0.13 (and 1.2.27) has now been installed on the following production machines dot granny tyagi sam skipper161 foghorn dirt moorthy michigan goldberg thurston It works with both ssh1 and ssh2 protocol clients/servers, so it should be ready to use with any host out there which has either version installed. To use it, just "ssh" in place of "telnet" or "rlogin" like this: goldberg[~]>ssh dot Accepting host dot key without checking. ott's password: Last login: Fri Sep 24 1999 21:47:24 -0400 The first time you log in, it will get the public key associated with the sshd server running on that machine. So the next time, you login it will look like this: goldberg[~]>ssh dot ott's password: Last login: Fri Sep 24 1999 21:50:31 -0400 If the server you login to is using ssh1, then their public key will be added to the "known_hosts" file within your home directory /home/username/.ssh/known_hosts "known_hosts" looks something like this: tyagi[~/.ssh]>cat known_hosts capefear 1024 37 178086079035539214331787087745349837432790458872600785925995022788387765 tyagi 1024 37 366754208795573592994280683358048504671541356444512591602790193909736628 You can also obtain their public key by other means (email,www,etc.) and add it to your "known_hosts" file manually. This will avoid the initial "Accepting host dot key without checking." which happens on the first connection with another ssh server. The public key for a ssh1 server is located on a UNIX system at /etc/ssh_host_key.pub The "1024 37" apears to come from the /etc/ssh_host_key.pub file on your own machine (ie. the client side). It appears to identify the client used to get the public key. If the server you are ssh'ing to is using ssh2, then their public key will be added to your /home/username/.ssh2/hostkeys/ directory. Right now, my directory shows: goldberg[~/.ssh2/hostkeys]>ls key_22_dot.pub key_22_granny.pub key_22_tyagi.pub key_22_foghorn.pub key_22_sam.pub key_22_goldberg.pub key_22_skipper161.pub Each file looks something like this: goldberg[~/.ssh2/hostkeys]>cat key_22_dot.pub ---- BEGIN SSH2 PUBLIC KEY ---- Subject: ott Comment: "host key for dot, accepted by ott Fri Sep 24 1999 21:28:57 -\ 0400" AAAAB3NzaC1kc3MAAACBANIn/K3f1ftjWQTlGOu1ZRLF5ZJdxI/Q61JdFdbkeNGQAssKUS ---- END SSH2 PUBLIC KEY ---- Again, if you want to avoid the initial "Accepting host dot key without checking.", then obtain the public key for that host by other means, and then add it as a file to this directory using the filename and content format seen above. If you ssh to a machine with ssh1 installed only, then you'll see the following message: thurston[~]>ssh capefear Executing /usr/local/bin/ssh1 for ssh1 compatibility. ott@capefear's password: Last login: Fri Sep 24 21:23:20 1999 from tyagi137.cs.unc. Note that ssh is smart enough to choose the right client, so you needn't use ssh1 directly (although you could if you wanted to). Likewise, the correct sshd (sshd1 or sshd2) is started up automatically in response to either client version requesting a connection. Remember that "sftp" is part of the ssh suite as well. Use it as you would regular "ftp". Finally, man pages are installed on each machine and include ssh sshd sftp as well as ssh-add ssh-agent ssh-keygen -d
(Added by Felix Hernandez. July 24th, 2000)
This section has its own FAQ page now: How do I give out a new password to a remote user? How do I handle guest accounts?
(Added by Felix Hernandez. March 23, 2001)
Most 4.1 machines cannot run ssh since they don't have the rsaref library. This library is not part of the standard installation, due to some legal concerns at the time 4.1 was released. I created a script that installs and compiles the library (/usr/dirt/bin/install_rsaref.bash), so use it whenever you need to add ssh and the other secure tools to a 4.1 machine.
(Added by Felix Hernandez. March 29, 2001)
The default SSH2 client in the department, SecureCRT, support 4 different SSH2 server modes. The default one is "Data Fellows 2.0.13". This mode is NOT compatible with our ssh daemons for FreeBSD 4.x. If you try to use it, the client will return an informative "error no. 2". Upon David's request, I did some digging into this problem, and I found that you have use the "standard" SSH Server mode (4th option in the drop-down box). That server mode works fine. This is a confusing problem, since the other mode works well with FreeBSD 2.x sshd (I guess the new daemon is more strict in its implementation of the ssh2 protocol.)