Below, is a lot of rambling, confusing notes on how to get ssh & scp automated, that is, working so you don't need to specify a password. Here's the executive summary for when the target is a Southbury, DCE/DFS userid. On the "server" (destination) side, 1) Generate a DSA public & private key. Logged in as your target id in Southbury, ssh-keygen echo 'Key id_dsa_2048_a' > .ssh2/authorization 2) and make it so the sshd daemon running in Southbury, can read what it needs, dcecp -c acl modify . -add {any_other r-x---} or dcecp -c acl modify . -change {any_other r-x---} dcecp -c acl modify .ssh2 -add {any_other r-x---} or dcecp -c acl modify .ssh2 -change {any_other r-x---} dcecp -c acl modify .ssh2/authorization -add {any_other r-----} dcecp -c acl modify .ssh2/id_dsa_2048_a.pub -add {any_other r-----} On the "client" (source) side, scp those id_dsa_2048_a files generated above, (when we did this for Sandy on 4-8-2004, it was) scp -p cotting@dephds035:.ssh2/id_dsa_2048_a.pub .ssh2/id_dsa_2048_a.pub scp -p cotting@dephds035:.ssh2/id_dsa_2048_a .ssh2/id_dsa_2048_a echo 'IdKey id_dsa_2048_a' > .ssh2/identification - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - These are my notes from when I installed the latest OpenSSL & OpenSSH on 5-27-2003. ------------------- For OpenSSL ------------------- The latest OpenSSL is at http://www.openssl.org/source/openssl-0.9.7b.tar.gz I saved it at /afs/d/software/base and cd /afs/d/software/base gzip -d < openssl-0.9.7b.tar.gz | tar xf - This created the openssl-0.9.7b directory which had 1700 files in it. rm openssl-0.9.7b.tar.gz First of all, I had freeware.openssl.rte 0.9.6.0 installed on my jasper machine, which had stuff installed in /usr/local, so I installp -u freeware.openssl.rte but there was still stuff in /usr/local/ssl that I didn't want to start with, so rm -rf /usr/local/ssl Now all I have under /usr/local is mklpp, zlib, and a version of Perl. But wait, there are some RPM-style packages installed. To query those, as root, rpm -q -a which shows I have these 5 RPM packages installed (with my notes) AIX-rpm-4.3.3.75-1 (The rpm command. See this file) openssl-0.9.6b-3 (Installed on 6-7-2002. See this file) gettext-0.10.39-2 (Needed by AIX-rpm-4.3.3.75-1) glib-1.2.10-2 (Part of netscape. See ~/aixnotes/netscape) gtk+-1.2.10-3 (Part of netscape. See ~/aixnotes/netscape) (See my ~/aixnotes/rpm file for other rpm command incantations.) I uninstalled ("erased" in rpm lingo) the openssl package with a rpm -e openssl-0.9.6b-3 command. Ok, NOW I think I'm ready to start. As jasper, cd /afs/d/software/base/openssl-0.9.7b vi INSTALL which said to build, ./config make which took forever, compiling hundreds (658?) of modules make test and su klog jasper (it compiled more stuff in AFS directory, so needed token) make install which took a very long time, too, installing lots of stuff, mostly in the /usr/local/ssl/man directory, but the really important stuff (I think) are /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a and /usr/local/ssl/bin/openssl ------------------- For OpenSSH ------------------- - Starting at http://www.openssh.org, - On the right, there's a section titled "For other OS's", which includes AIX, and goes to http://www.openssh.org/portable.html, - I went to one of the US ftp mirror sites, ftp://gandalf.neark.org/pub/distributions/OpenBSD/OpenSSH/portable, and - selected the latest tar.gz file, openssh-3.6.1p2.tar.gz dated 4-29-2003, which was 879,629 bytes big, putting it in /afs/d/software/base. Then cd /afs/d/software/base gzip -d < openssh-3.6.1p2.tar.gz | tar xf - creating a openssh-3.6.1p2 directory. rm openssh-3.6.1p2.tar.gz I wanted to see if building OpenSSH for use from /local/bin (AFS), would wind up being somehow different than for /usr/local, so I cp -pRh openssh-3.6.1p2 openssh-3.6.1p2.built.for.local.bin There were these notes in the INSTALL file, which sound like this is what I want to do, ************************************************************************* * will install * * * the OpenSSH binaries in /usr/local/bin, * * * the configuration files in /usr/local/etc, * * * the server in /usr/local/sbin, etc. * * * * To specify a different installation prefix, use the --prefix option * * to configure: * * ./configure --prefix=/opt * * make * * make install * * Will install OpenSSH in /opt/{bin,etc,lib,sbin}. * * * * You can also override specific paths, for example: * * ./configure --prefix=/opt --sysconfdir=/etc/ssh * * make * * make install * * This will install the binaries in /opt/{bin,lib,sbin}, but will * * place the configuration files in /etc/ssh. * ************************************************************************* For the standard /usr/local build, cd openssh-3.6.1p2 ./configure (This took 4.5 minutes) make (This took 3 minutes) su - cd /afs/d/software/base/openssh-3.6.1p2 make install (This took 1.5 minute ) Interesting lines from the make install included, mkdir /usr/local/etc Generating public/private rsa1 key pair. Your identification has been saved in /usr/local/etc/ssh_host_key. Your public key has been saved in /usr/local/etc/ssh_host_key.pub. ... Generating public/private dsa key pair. Your identification has been saved in /usr/local/etc/ssh_host_dsa_key. Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub. ... Generating public/private rsa key pair. Your identification has been saved in /usr/local/etc/ssh_host_rsa_key. Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub. ... This gave me in /usr/local/bin, scp, ssh, ssh-add, ssh-agent, ssh-keygen, and /usr/local/sbin/sshd, and configuration files in /usr/local/etc (among other stuff). When I start the sshd daemon via su - /usr/local/sbin/sshd I get the error message Privilege separation user sshd does not exist Doing a google search, turns up http://www.citi.umich.edu/u/provos/ssh/privsep-faq.html which says I need to create a sshd userid and group. Hmmmm, that's new. >>> Why didn't the install directions say anything about this?? Nothing in INSTALL, README files, man sshd, man5 sshd, man sshd2_config, or man 5 sshd2_config. ... Ah, but I needed to be seeing the right man pages. This man -M /usr/local/man 5 sshd_config showed me the UsePrivilegeSeparation option in the sshd_config file, whose default is "yes". There's also a README.privsep in the source /afs/d/software/base/openssh-3.6.1p2 directory. For more info, go to http://www.citi.umich.edu/u/provos/ssh/privsep.html. It talks about adding a sshd userid & group, with a home directory of /var/empty, but it seems easier to just shut this feature off than it is to do this for each server. I just added a UsePrivilegeSeparation no line to the /usr/local/etc/sshd_config file. Now /usr/local/sbin/sshd starts cleanly and I can login as both root and jasper (testing the AFS authentication). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------- History & Confusion ------------- - The original, Ed Geraghty SSH Version 1.2.27 used installp, and put the binaries in /usr/bin and /sbin, config files in /etc. It also updated /etc/services, adding ssh at 22 & sshdfail at 2222), /etc/inetd.conf adding sshdfail, and /etc/rc.tcpip (essentially) adding startsrc -s sshd1. Finally, it added sshd1 as a SRC-controlled daemon, so you can e.g. "startsrc -s sshd1". - Southbury uses an installp-able package called USFSssh2.rte that installs code in /usr/local, config files at /etc/ssh2, and even some miscellaneous stuff in /usr/lpp/USFSssh2. This apparently does not require ssl. - IBM distributes a not-that-old SSH in its "AIX Toolbox for Linux Applications" at http://www6.software.ibm.com/dl/aixtbx/aixtbx-ldl?S_PKG=dlaixww On 5-30-2003 for example, it only had OpenSSH-3.4p1-7. This gets distributed in rpm files, requiring that Redhat Package Manger software. It installs stuff in /usr/local and required the rpm-installable openssl. - If you get the source, this doesn't use installp or rpm at all and it also installs stuff in /usr/local and requires Zlib & openssl. - You could also get ssh from http://www.rge.com/pub/systems/aix/bull, which gets distributed as openssh-3.6.1.0.exe, which after running, gives you a bff, which is installp-able and goes into /usr/local, just like the original source does. So do you tell what you have? lslpp -L | grep -i ssh (Ancient Ed Geraghty stuff or USF package) or lslpp -L | grep -i ssl or lslpp -L | grep -i freeware (Bull stuff) rpm -qa | grep -i 'ss[hl]' (IBM-distributed stuff) else it must be a version built from the source. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Doing an "ssh -V" shows me that - Patolis's ssh was SSH Version 1.2.27 (before 12-19-2004) but as of 12-19-2004, is now SSH Secure Shell 3.2.9.1 (non-commercial version) - Southbury's is F-Secure-SSH-2.3.1 (build 7) - Our /local/bin in AFS is SSH Secure Shell 3.1.0 - whereas my new version is OpenSSH_3.6.1p2 Originally, SSH version 1 used ones ~/.ssh directory. The "F-Secure-SSH-2.3.1" that Southbury has as well as our /local/bin's "SSH Secure Shell 3.1.0", uses ~/.ssh2. And now, this new OpenSSH_3.6.1p2 goes back to using ~/.ssh. On top of that, the SSH book, only documents things up to F-Secure 2.0.13 or OpenSSH 2.2.0, but it does explain the 2 directories (~/.ssh & ~/.ssh2) and it also talks about the SSH version 2 identification & authorization files. It does not mention that somewhere along the line, they went back to ~/.ssh. Confusing when you're trying to get all versions to work with each other. Another difference. SSH Version 1 typically uses RSA encryption. SSH Version 2 typically uses DSA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ok. I'm doing all this to get public key authentication to work. At a high level, to get public key authentication to work, one does the following, 1) Create a public/private key pair. - Login as your target userid on your target system, - and type ssh-keygen (you may possibly need ssh-keygen -t dsa) 2) On the server or target or destination side, - add the public key in the proper authorization file. 3) On the client or source side, - add the public key in the proper authorization file, and - add the private key in the proper identification file. ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- Here's me getting this to work from Southbury's dephds010, to dephds009. 1) To set up the target userid (rickjas at dephds009), ssh -l rickjas dephds009 ssh-keygen I hit enter at the two Passphrase prompts so that I don't have to enter a decryption password when using these keys. This created a private key at /home/rickjas/.ssh2/id_dsa_1024_a and a public key at /home/rickjas/.ssh2/id_dsa_1024_a.pub To "activate" (my word) this public key, from rickjas on dephds009, echo 'Key id_dsa_1024_a.pub' > ~/.ssh2/authorization (Note it's the public key you put in this authorization file, not the private one like I would have guessed) ==================================================================== = In Patolis, as inst1 on ips01i which has SSH v1, this = = created the ~inst1/.ssh directory and two files under it, = = identity (private key) and identity.pub (public key). = ==================================================================== 2) To set up a client end (e.g. rickjas on dephds010), you need 3 files. mkdir .ssh2 (if it doesn't already exist) cd .ssh2 scp -p rickjas@dephds009:.ssh2/id_dsa_1024_a.pub . scp -p rickjas@dephds009:.ssh2/id_dsa_1024_a . echo 'IdKey id_dsa_1024_a' > identification (If you look at this closely, it may seem wrong. I can see needing the target's public key on the client end, but I thought the target's private key would be left on the server/target, but it's not. And it's this private key piece that's put in the client's identification file, not the public key. When the client invokes ssh/scp to the target, the client software reads the filename from the identifiation file, and also tries to read thatfilename.pub. If it doesn't exists, it spits out this error, warning: Could not read public key file /home/rickjas/.ssh2/id_dsa_1024_a.pub.pub This is when I had id_dsa_1024_a.pub in that file.) Confusing. I don't understand it. ==================================================================== = Or from inst1 on dephds059, = = scp1 -p inst1@ips01i:.ssh/identity ~/.ssh/identity = = scp1 -p inst1@ips01i:.ssh/identity.pub ~/.ssh/authorized_keys = ==================================================================== At this point, from rickjas on dephds010, I can ssh to or scp as rickjas on dephds009, with no password. Observe closely, scp -p /etc/motd rickjas@dephds009: motd | 546B | 0.5 kB/s | TOC: 00:00:01 | 100% ssh dephds009 Authentication successful. ==================================================================== = Or from inst1 on dephds059, = = scp1 -p /etc/motd inst1@ips01i: = ==================================================================== 3) After doing all the above, you need 2 things to finish up rickjas on both dephds009 and dephds010, e.g. to allow rickjas on dephds009 to get into rickjas on dephds010. You need the authorization file: As rickjas on dephds010, echo 'Key id_dsa_1024_a.pub' > ~/.ssh2/authorization And you need the identification file: As rickjas on dephds009, echo 'IdKey id_dsa_1024_a' > ~/.ssh2/identification 4) To set up the other ids (rickjas on dephds005-008 & dephds011-012) to act as both servers/targets and clients, as rickjas on dephds009, for i in 05 06 07 08 11 12 do scp -p ~/.ssh2/id_dsa_1024_a rickjas@dephds0$i:.ssh2 scp -p ~/.ssh2/id_dsa_1024_a.pub rickjas@dephds0$i:.ssh2 scp -p ~/.ssh2/authorization rickjas@dephds0$i:.ssh2 scp -p ~/.ssh2/identification rickjas@dephds0$i:.ssh2 done (This presumes the ~/.ssh2 directory exists, which it didn't on dephds011) Now from rickjas on any of dephds005-012, I can ssh to or scp as rickjas on any of the other of dephds005-012 systems. ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- To get that key to work from San Jose, all you need do is As jasper on jasper, which by default, uses /local/bin/ssh cd .ssh2 scp -p rickjas@dephds010:.ssh2/id_dsa_1024* . rickjas@dephds010's password: This gets both the id_dsa_1024_a.009 and id_dsa_1024_a.009.pub files. echo 'IdKey id_dsa_1024_a.009' >> identification and the ssh or scp from /local/bin, works without a password. ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- Depending on the level of ssh software you have, things could be slightly different than what I show above. * SSH version 1 creates an RSA key, version 2 creates a DSA key. * You may need to specify "-t dsa" on the ssh-keygen command. * The key files may go into ~/.ssh or ~/.ssh2. * The private and public key files may be named one of identity or id_dsa_1024_a or id_dsa for the private key, and identity.pub or id_dsa_1024_a.pub or id_dsa.pub for the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Those are the simple cases. You get into complexities when you try to get the above (public key authentication) to work with the new OpenSSH v 3.6.1p2 (what I have installed on my jasper machine at /usr/local/bin/ssh) or try authenticating with a DCE userid. 1) The OpenSSH_3.6.1p2 version installed on jasper in /usr/local, does not properly handle the key files created by Southbury's F-Secure ssh. 2-A) You've got to be very careful with DFS directory permissions when the target is a DCE id whose home dir is in DFS. The permissions on /dfs/users/u0/rickjas and /dfs/users/u0/rickjas/.ssh2 cannot be world-writable, and I think there are other restrictions as well that unfortunately, I didn't fully document. To debug this, it's best to run the sshd deamon with -d or -debug turned on. It may have been due to {other_obj rwx-id} {any_other rwx-id} being on my -io for my .ssh2 directory. This caused newly-created files to have permissions that were too open. But on the other hand, the permissions cannot be too restrictive either. Just remember the sshd daemon runs completely unauthenticated (I thought it might share root's self DCE credentials, but it doesn't). This means that you need {any_other r-x---} on the /dfs/users/u0/rickjas directory, the /dfs/users/u0/rickjas/.ssh2 directory, the /dfs/users/u0/rickjas/.ssh2/authorization directory, and the /dfs/users/u0/rickjas/.ssh2/id_dsa_1024_a.pub file. I was then able to login rickjas at dephds045 (for example), from anywhere. However, I was logged on without any DCE credentials. Sigh! Seems like I've seen this before -- that is, logging in via ssh with no password, doesn't give the sshd daemon the ability to also authenticate with DCE, which requires a password. Remembering my old DCE notes (~jasper/aixnotes/dce), I created a keytab file. As rickjas on dephds009, rgy_edit ktadd -p rickjas -pw bye22dfs -f rickjas.ktab quit --------> My DCE password on 8-25-2003 This will need updating when you change your password. Then to use it, for example, to dce_login, dce_login rickjas -k rickjas.ktab I even put these lines in my .kshrc, if ! klist >/dev/null 2>&1 then dce_login rickjas -k rickjas.ktab fi Now when I login to rickjas @ dephds009, I get ssh -l rickjas dephds009 Authentication successful. <--- This is the ssh authentication. DCE LOGIN SUCCESSFUL <--- This is the dce_login. There are then 2 shells to exit out of to logoff. This didn't work too well when the target's home directory is in DFS. There were problems writing to the .Xauthority file, which happened before one's .kshrc could execute, thus before the .kshrc could do the dce_login. And then when the .Xauthority stuff failed, .kshrc would never run. I never did get the ACL permissions right to make it work. 2-B) Permissions may not be a problem when the client (as contrasted with the target talked about in the preceeding paragraph) is in DFS. For example, as rickjas on dephds056, this worked just fine. cd .ssh2 scp -p rickjas@dephds009:.ssh2/id_dsa_1024_a id_dsa_1024_a scp -p rickjas@dephds009:.ssh2/id_dsa_1024_a.pub id_dsa_1024_a.pub echo 'IdKey id_dsa_1024_a' > identification and I was able to login rickjas at dephds009, but I think there may have been problems with permissions here, too. All you see with -v turned on at the client end (ssh -v ...), is this message ... Method 'publickey' disabled. Again, sorry, but I didn't quite document exactly which files have to be locked down to what state. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I also have the OpenSSH_3.6.1p2 version installed on jasper in /usr/local, which uses ~/.ssh, but the format of the identity file & private key is different, and I can't manipulate it enough to get it to work. One trick Christian Manasiou told me, was to create the key pair with the new ssh, then manipulate it and put it on dephds009. The F-Secure ssh they have in Southbury can handle the encryption files (with some tweaking) created by my new OpenSSH, but not vice-versa. cd .ssh cp -p ../.ssh2/id_dsa_1024_a.009 identity - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I still cannot get DSA authentication to work and turning on debugging/verbose on both the server and client ends, shows me it's reading ssh version 1-style configuration files. On the server (jasper) side, * I had to turn StrictModes no in the /usr/local/etc/sshd_config file, else I'd get debug1: trying public key file /u/jasper/.ssh/authorized_keys Authentication refused: bad ownership or modes for directory /afs/delphion.com/u/jasper Or more simply, chmod 755 /afs/d/u/jasper * To run sshd in debug mode, /usr/local/sbin/sshd -d On the client (patimg1) side, * To run in verbose mode, /usr/local/bin/ssh -v -l jasper jasper This shows the client is reading ~/.ssh/identity, which needs to be chmod'd to 600 else the client ignores the file (there's no way to override this action like there is on the server side with a "StrictModes no" in the sshd_config file). The book says for ssh2, we should be reading out of the ~/.ssh2 directory, but that was for OpenSSH version 2.2.0 and this is OpenSSH version 3.6.1. It looks like they went back to using the ~/.ssh directory, despite what the man pages say (But beware of your $MANPATH!! Normal is to pick up the ssh man pages from /local/bin/man before the /usr/local/man, which give you the wrong ones!!!) /usr/local/bin/ssh-keygen -t dsa taking the defaults and hitting enter for the two Enter passphrase (empty for no passphrase): Enter same passphrase again: prompts, created ~/.ssh/id_dsa <-- This private key goes on the "client" side. and ~/.ssh/id_dsa.pub <-- This public key stays here, on the "server" side, in the authorized_keys file. cd ~/.ssh cp -p id_dsa.pub authorized_keys The permissions on authorized_keys are correct (644 = rw-r--r--), and this is a 1-line file, 603 bytes long, containing "ssh-dss AAAAB3NzaC...www== jasper@jasper" And now both ssh & scp both work without a password, presuming 1) the sshd daemon running on the destination machine is this version of sshd, i.e. /usr/local/sbin/sshd, not the normal /local/bin/sshd out of AFS. and 2) the ssh & scp client programs are from /usr/local/bin, not /local/bin (AFS) ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- These files were ftp'd from www-126.ibm.com/pub/opensshi/openssh_install.tar.Z on June 6, 2002. These are my notes copied from /afs/d/software/base/OpenSSH-2.9.9/README. ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- These files were ftp'd from www-126.ibm.com/pub/opensshi/openssh_install.tar.Z on June 6, 2002. ---------------------------------------------------------------------------------- The first time I tried to install this stuff, I got A prerequisite package has not been installed. Open SSH requires Open SSL (Secure Sockets Layer). Please install Open SSL from the AIX Toolbox for Linux CD or Toolbox website: http://www6.software.ibm.com/dl/aixtbx/aixtbx-i?S_PKG=dlaixgv&S_TACT=&S_CMP= which interestingly enough, requires a userid/password to get in. I was in luck when it told me that I had the userid rickjas at their site, so I authenticated with my normal, standard, Internet password. Note this is Open SSL, not ...SSH, which you get with the link openssl - Secure Sockets Layer and cryptography libraries and tools: openssl-0.9.5b-3.aix.4.3.ppc.rpm 908KB and what you get is a Linux-style .rpm file. Warning: You must use this Linux-style thing. The Openssl Eric has in the /afs/d/software/base/OpenSSH-2.9.2 directory, ain't good enough. -rw-r--r-- 1 jasper staff 6092800 Oct 19 2000 openssl-0.9.6.0.bff -rw-r--r-- 1 jasper staff 2599 Oct 23 2000 openssl-0.9.6.0.bff.asc -rwxr-x--x 1 eric sys 1620889 Dec 17 16:56 openssl-0.9.6.0.ex It will still give you errors. So did getting OpenSSL-0.9.6d from www.openssl.org, compiling it, etc. Finally RTFM (that is, ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/FAQ), and learned that that .rpm file uses the Linux Redhat Package Manager tool to install, which was available from ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/INSTALLP/ppc/rpm-3.0.5.31 and all I had to do to install "rpm.rte 3.0.5.31 # RPM Package Manager" was to inutoc . & installp it. Was then able to install openssl via rpm -Uhv openssl-0.9.6b-3.aix4.3.ppc.rpm which was interesting. 3 Seconds and this line openssl ################################################## later, it was evidently installed. Hmmmm. Was than able to installp Openssh from this directory (Whew!), which got me openssh.base.client 2.9.9.0 C Open Secure Shell Commands openssh.base.server 2.9.9.0 C Open Secure Shell Server openssh.license 2.9.9.0 C Open Secure Shell License openssh.man.en_US 2.9.9.0 C Open Secure Shell Documentation openssh.msg.en_US 2.9.9.0 C Open Secure Shell Messages - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Now the question of the day is, is this version old? The version of ssh found at /afs/d/software/base/ssh-3.1.0, that Eric picked up from who-knows-where, apparently is ssh version 3.1, and 3.1 is greater than 2.9. ???????? ==================================================================================== Notes on getting automatic scp working to wilasys.intranet.wila for Tom on penguin today, but soon I'll need this working as well. The wilasys machine uses OpenSSH_3.4p1, which is similar to the OpenSSH_3.6.1p2 I have installed in /usr/local/bin on my jasper machine, so I referred to my notes in this file starting at line 469. Basically, I decided to install on penguin, the same OpenSSH_3.6.1p2 in as I do on jasper. To install the versions of OpenSSL & OpenSSH I needed, as root on penguin, I cd /afs/d/software/base/openssl-0.9.7b klog jasper make install cd /afs/d/software/base/openssh-3.6.1p2 make install Then on your target id, e.g. tgriffin on wilasys, ssh-keygen -t dsa taking the defaults and hitting enter for the two Enter passphrase (empty for no passphrase): Enter same passphrase again: prompts, created ~/.ssh/id_dsa <-- This private key goes on the "client" side. and ~/.ssh/id_dsa.pub <-- This public key stays here, on the "server" side, in the authorized_keys file, so cp -p id_dsa.pub authorized_keys If not already done (it wasn't for Tom), chmod 700 ~/.ssh Back as tom on penguin, cd ~/.ssh /local/bin/scp -p tgriffin@wilasys.intranet.wila:/.ssh/id_dsa . And now both ssh & scp both work without a password, presuming you use the /usr/local/sbin versions, not the normal /local/bin versions in AFS. ==================================================================================== Notes on getting automatic scp working from inst1@dephds059, to inst1@ips01i This time, done the way it's suppose to be done. From the "server" (inst1@ips01i), mkdir .ssh2;chmod 700 .ssh2 (if not already there) From the "client" (inst1@dephds059), ssh-keygen taking the defaults and hitting enter for the two Passphrase : Again : prompts, which created ~/.ssh2/id_dsa_2048_a <-- This private key stays here on the "client" side. and ~/.ssh2/id_dsa_2048_a.pub <-- This public key goes to the "server" side, cd .ssh2 echo 'IdKey id_dsa_2048_a' > .ssh2/identification chmod 600 .ssh2/identification scp -p .ssh2/id_dsa_2048_a.pub inst1@ips01i:.ssh2 From the "server" (inst1@ips01i) again, cd .ssh2 echo 'Key id_dsa_2048_a.pub' > authorization Now from inst1@dephds059, I can do a scp -p .kshrc inst1@ips01i:junk without specifying a password. Of course, what I really wanted to do from inst1@dephds059, was the weekly cd Japio.US.Update /usr/bin/scp -p inpadoc.collections.20041219 \ inst1@ips01i:/ips/prod/include/inpadoc.collections.html.20041219 or the ssh/scp commands Sandy does from the /home/inst1/Japio.US.Update/getUSdata.sh script, which inconsistently, goes to ips01i.ips4db2.com instead of just ips01i like the inpadoc.summary.pl script does. Oh, well. ==================================================================================== To get ssh to work without a password from dephds059, to marge01eu, I logged on to rickjas on dephds059 (I had already generated a key pair with ssh-keygen) scp -p .ssh2/id_dsa_1024_a.pub rjasper@marge01eu.ipr-village.info: Then as rjasper on marge01eu, I chmod 755 ~ mv id_dsa_1024_a.pub .ssh/authorized_keys chmod 644 .ssh/authorized_keys vi .ssh/authorized_keys to cut it down to one line, starting with "ssh-dss " (without the quotes), then that whole, big, long key, finally followed by " rjasper@marge01" That is, from ---- BEGIN SSH2 PUBLIC KEY ---- Subject: rickjas Comment: "1024-bit dsa, rickjas@dephds009, Fri May 30 2003 22:35:18" AAAAB3NzaC1kc3MAAACBAJExklYkGhnXAfnVBjuOzpo94Lx+4wbsLIbsQjT873wAewOW1a gUQQ7HkLOXg65zOEvpJouUOb7gbk4TPt+g6PHrz0JEFBTu+1Dn46kAqI9tY0R/zg4jvsDq eLiTiWisb9stgF9Uick+ysRHDXTxr6lt+nX3AFFvU8f/Tv/01ptlAAAAFQC3EFm5MW9cfn aVypW17d37e/yE1QAAAIBzjKSjeGduwJt+zce3DV2Ge6sjr9j7eyWBz97VUIj2dkmUzrck C7879xr1N7A9OL7QuR9E+kbBUyO7yab66akNf2Wf7pYZqLDwUVzzAsz8ZHxFH/1X2ZALgg cDZFGpvkozbh6dViOAiUnWrwAB4rXD+L4ORBUkgDANuDpkA++BIQAAAIA7lLg4hss/S915 b1HzLLYAQ9XMJajh0aJR1PB76s9DG1of2XTH/z9xUHvWGwl0cwagQvmhCZHX+miMxsAQlN aLJOO40dU7B06s4xx198mr2Iao0ue1lgR38ZtKH7GyiP/GSM08My5qCKrZHcRj2OE/gJx3 9FlxTlrg5zskieiZ7w== ---- END SSH2 PUBLIC KEY ---- to this one line ssh-dss AAAAB3NzaC1kc3MAAACBAJExklYkGhnXAfnVBjuOzpo94Lx+4wbsLIbsQjT873wAewOW1agUQQ7HkLOXg65zOEvpJouUOb7gbk4TPt+g6PHrz0JEFBTu+1Dn46kAqI9tY0R/zg4jvsDqeLiTiWisb9stgF9Uick+ysRHDXTxr6lt+nX3AFFvU8f/Tv/01ptlAAAAFQC3EFm5MW9cfnaVypW17d37e/yE1QAAAIBzjKSjeGduwJt+zce3DV2Ge6sjr9j7eyWBz97VUIj2dkmUzrckC7879xr1N7A9OL7QuR9E+kbBUyO7yab66akNf2Wf7pYZqLDwUVzzAsz8ZHxFH/1X2ZALggcDZFGpvkozbh6dViOAiUnWrwAB4rXD+L4ORBUkgDANuDpkA++BIQAAAIA7lLg4hss/S915b1HzLLYAQ9XMJajh0aJR1PB76s9DG1of2XTH/z9xUHvWGwl0cwagQvmhCZHX+miMxsAQlNaLJOO40dU7B06s4xx198mr2Iao0ue1lgR38ZtKH7GyiP/GSM08My5qCKrZHcRj2OE/gJx39FlxTlrg5zskieiZ7w== rjasper@marge01 And now scp from rickjas@dephds059 to marge01eu, works without a password, e.g. scp -p /etc/motd rjasper@marge01eu.ipr-village.info: ==================================================================================== To get ssh/scp working automatically in Limerick, you need to create an ssh identity, then spread it around to the different systems. First verify which ssh you're using. There are miscellaneous ssh versions floating around, which use different directories (e.g. ~/.ssh versus ~/.ssh2). For me, jasper@jasper, on 3-1-2005, type ssh-keygen returned ssh-keygen is /local/bin/ssh-keygen and this version of ssh used ones ~/.ssh2 directory. ssh-keygen Just hit for the 2 prompts, Passphrase : Again : This creates two files in your .ssh2 directory, * id_dsa_1024_a.pub = Your public key. This gets copied to all "source" machines as authorized_keys. For San Jose, #NO cp -p .ssh2/id_dsa_1024_a.pub .ssh2/authorized_keys * id_dsa_1024_a = Your private key. Activate it in San Jose by echo 'Key id_dsa_1024_a' > .ssh2/authorization For Limerick, note the change in the ssh directory, .ssh instead of .ssh2, scp -p .ssh2/id_dsa_1024_a.pub jasper@dweb1:.ssh/authorized_keys Hack at that authorized_keys file, changing it from ---- BEGIN SSH2 PUBLIC KEY ---- Subject: jasper Comment: "1024-bit dsa, jasper@jasper, Tue Mar 01 2005 18:15:58" AAAAB3NzaC1kc3MAAACBAPaLllXwJa0kwwdow9+kMhVqR2uZWhW9yPfwGUap7AWP2iLZ3W YhfaSZZ4GZz4Lh7KSx70v0hp6U0VRuqREaQ65fvl2lud3mHkinG+A0rabEArV+qxrTMmIi f7nVih9KWVHgbRSXfpGeIvUvX3UnKh1JUiEH6+Z/Z9riGbHg4QtfAAAAFQCxRfXOHx1kAM YWqg8sTvq0eh9LhwAAAIEAkDJLVirJzWnjLQ91PePc8z15BdWcOL5F++ABiBtnM/kNmwM4 KjozFckMYCatmQFwIxVw3GbAEcSXa5iSyhhi2LEbfeRFYHSahsEo2hgBaKS8P+7rq/Ba6b P1vwhXQgHx6ngIbXgeFeAoMv9kR5DjcU1qaBWWzrYx9vSsyUnVu24AAACBAJnuku1AG8rS i9CUucVzP143WgeuC9+y4VSO0lxh3Yu4iR5ioa6X8Lw+zSFEimlr2LUP0l1ORbrJWDSy4I xNWq2ihGMpsAnR0PiuNf8t6Ky7zydnQu/RkG4ld6/2meVDSoY6pJ1gWjdQI3NFLjiBk8k/ 078Q1hURAPrNjsWng842 ---- END SSH2 PUBLIC KEY ---- to this single line, ssh-dss AAAAB3NzaC1kc3MAAACBAPaLllXwJa0kwwdow9+kMhVqR2uZWhW9yPfwGUap7AWP2iLZ3WYhfaSZZ4GZz4Lh7KSx70v0hp6U0VRuqREaQ65fvl2lud3mHkinG+A0rabEArV+qxrTMmIif7nVih9KWVHgbRSXfpGeIvUvX3UnKh1JUiEH6+Z/Z9riGbHg4QtfAAAAFQCxRfXOHx1kAMYWqg8sTvq0eh9LhwAAAIEAkDJLVirJzWnjLQ91PePc8z15BdWcOL5F++ABiBtnM/kNmwM4KjozFckMYCatmQFwIxVw3GbAEcSXa5iSyhhi2LEbfeRFYHSahsEo2hgBaKS8P+7rq/Ba6bP1vwhXQgHx6ngIbXgeFeAoMv9kR5DjcU1qaBWWzrYx9vSsyUnVu24AAACBAJnuku1AG8rSi9CUucVzP143WgeuC9+y4VSO0lxh3Yu4iR5ioa6X8Lw+zSFEimlr2LUP0l1ORbrJWDSy4IxNWq2ihGMpsAnR0PiuNf8t6Ky7zydnQu/RkG4ld6/2meVDSoY6pJ1gWjdQI3NFLjiBk8k/078Q1hURAPrNjsWng842 jasper@dweb1 ==================================================================================== From jasper on dweb1, ssh-keygen -t dsa -b 2048 taking the defaults and hitting enter for these three Enter file in which to save the key (/dfs/home/jasper/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: prompts. This created ~/.ssh/id_dsa <-- Your private key. and ~/.ssh/id_dsa.pub <-- Your public key. Normally, the client's identity is verified on the server end. For example, if jasper@jasper tries to ssh/scp to jasper@dweb1, the client (jasper@jasper) asserts his identity (jasper@jasper) to the server side (jasper@dweb1). If the jasper@jasper's public key is in jasper@dweb1's authorized_keys file, then the sshd daemon/server on dweb1 will allow it. (This is backwards from how I previously thought it worked. I thought ) (that somehow the client proved to the server that he's jasper@dweb1, ) (and then got all confused with where the private & public keys needed ) (to be. That was all wrong. It's the other way around. ) So normally, the client side "activates" (my word) the private key with echo 'Key id_dsa' > ~/.ssh/authorization then sends his public key to whoever/wherever you may want to ssh/scp to. If the other end (jasper@dweb1 in my example) wanted to allow you in, they would append your public key (id_dsa.pub)to their authorization file, e.g. cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys or cat ~/.ssh/id_dsa.pub >> ~/.ssh2/authorized_keys depending on which version of SSH is on their end. Since in Limerick, ones home directory is shared, when you ssh/scp from and to a Limerick machine (eg, from jasper@dweb1 to jasper@dsearch2), your ~/.ssh directory acts as both a client and a server. So you need to do both steps, as jasper on some Limerick machine, echo 'Key id_dsa' > ~/.ssh/authorization to activate your private key (the client part), and cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys to authorize that public key. To get this working from San Jose, you normally would repeat the ssh-keygen command from San Jose and export the public key to EDC. Due to a SSH version difference though, I couldn't get this to work. So the easiest thing to do is for the client, jasper@jasper, to have that same identity as jasper@dweb1 has (normally, you would never do this). To do this, you want to bring over that private key to the proper ssh directory under your AFS home directory. As of 3-4-2005, the default SSH in /local/bin, was/is ssh: SSH Secure Shell 3.1.0 (non-commercial version) on powerpc-ibm-aix4.3.3.0 which uses your ~/.ssh2, so scp -p jasper@dweb1:.ssh/id_dsa ~/.ssh2/id_dsa and activate it by, echo 'Key id_dsa' >> ~/.ssh2/identification xxx echo 'IdKey id_dsa_2048_a' > .ssh2/identification xxx chmod 600 ~/.ssh2/identification xxx cd .ssh2 xxx chmod 600 .ssh2/identification xxx scp -p .ssh2/id_dsa_2048_a.pub inst1@ips01i:.ssh2 And to use the public key when ssh/scp-ing, cp -p ~/.ssh/id_dsa.pub ~/.ssh/authorized_keys If not already done chmod 700 ~/.ssh To get that working from San Jose, ?? cd ~/.ssh ?? /local/bin/scp -p jasper@dweb1:/.ssh/id_dsa.pub . And now both ssh & scp both work without a password, presuming you use the /usr/local/bin versions, not the normal /local/bin versions in AFS. ==================================================================================== Notes on getting automatic scp working from jasper@dweb1, to jasper@ips01i From jasper@dweb1 ssh-keygen -b 2048 -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/dfs/home/jasper/.ssh/id_dsa): /dfs/home/jasper/.ssh/id_dsa.2048 Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /dfs/home/jasper/.ssh/id_dsa.2048. Your public key has been saved in /dfs/home/jasper/.ssh/id_dsa.2048.pub. The key fingerprint is: 46:15:b9:ba:11:9d:97:68:e9:49:a9:04:8d:fe:9c:a5 jasper@dweb1 taking the defaults and hitting enter for the two Passphrase : Again : This created ~/.ssh/id_dsa.2048.pub <-- This public key goes to the "server" side, and ~/.ssh/id_dsa.2048 <-- This private key stays here on the "client" side. Still from jasper@dweb1, cd .ssh echo 'IdKey id_dsa.2048' > identification chmod 600 identification scp -p id_dsa.2048.pub jasper@ips01i.ips4db2.com:.ssh2 From the "server" (jasper@ips01i) again, cd .ssh2 echo 'Key id_dsa_2048_a.pub' > authorization Now from inst1@dephds059, I can do a scp -p .kshrc inst1@ips01i:junk ====================================================================================