我想在login后，直接联到另一台机器（也是SCO）,而不需要二次登陆。
但用rlogin 时有乱码...

简介 


SSH除了能够执行平常的交互操作外，还可以用来自动地执行一些脚本和自动任务，为这些任务提供优秀的安全保护。不过要做到这些有一个最大的障碍，就是客户的认证：在无人输入的情况下，如何获得用户的认证信息(用户名和密码)？这里，我们将讨论如何实现ssh的非交互认证。 


注意任何非交互认证都存在安全问题，即使SSH也不例外，因此一定要慎重考虑。在无人参与的情况下，认证所需的凭证(例如：密码)都要放在主机的某个地方，这样只要攻击者获得了主机的root权限，就可以访问保存在主机上的所有认证凭证。总之，在在选择使用的方法之前，你一定要权衡每种实现方式的优、缺点。选择危害较请的实现方法。如果你不想降低系统的安全性，那就不要使用批量和定时的远程作业。 




1.密码认证 



这种认证方式的安全系数是最底的。因为为了使用密码认证，你必需把密码潜入到要执行的脚本或者放到一个脚本能够读到的文件中。无论你采取什么措施，具有脚本读权限的任何人都会获得密码。因此，我们不建议使用这种技术，相对来说，选择公开密钥认证要安全的多。 

2.公开密钥认证 



在公开密钥认证中，私钥是客户的认证凭证。因此，脚本需要访问这个密钥，必须保存在脚本能够访问到的地方。保存密钥的地方可以有三个选择，后面我们将会分别讨论： 




把加密后的密钥和访问这个密钥的口令保存到文件系统。 



把明文(未加密的)私钥保存到文件系统，因此不需要口令的保护。 



使用ssh代理管理密钥，这种方式比直接保存到文件系统要安全一些，只是在系统启动时需要人工解密这个密钥。 




2.1.在文件系统中保存口令加密过的密钥 


这种保存方式是在文件系统中保存加密的密钥和访问这个密钥的口令。不过，我们不建议使用这种方式，因为它并不比直接保存明文密钥更安全，它们的安全性都依赖于对文件系统的保护。而且，如果使用这种方式还比较麻烦。 



2.2.保存明文密钥(私钥) 


使用这种保存方式不需要密钥的口令。用户可以使用OpenSSH套件的ssh-keygen命令产生新的私钥和维护原由的私钥。在ssh-genkey提示输入私钥的保护口令时，就可以产生一个明文保存的私钥；另外使用ssh-genkey -p命令可以去掉私钥的保护口令。然后，你可以使用ssh命令的-i选项指定私钥文件的位置，或者在客户配置文件中使用IdentityFile关键词指定私钥文件的位置。 


明文密钥不太安全的，相当于把密码放到帐户的一个文件中。不适合交互登录的情况下采用这种密钥保存方式，而使用SSH代理管理密钥可以更安全一些。不过，对于自动登录，这种方式还是可以使用的。从安全角度看，以上三种情况：明文密钥、使用口令加密的密钥和密钥的安全性是一样的。但是，有三个理由使我们采用明文密钥的认证方式： 




在服务器端，使用公开密钥认证更有利于帐户的管理，尤其是在建立批量作业时。 



公开密钥认证不会被恶意服务器窃取认证机密。 



从一个程序向SSH提供一个密码比较困难。SSH不是从标准输入获得用户的密码，它是直接从与用户进行交互的控制终端获得密码。为了在应用程序和SSH之间传递密码，你需要使用一个伪终端和SSH进行交互(例如：使用expect等工具)。 



明文密钥还是比较让人担心的。攻击者只要突破文件系统的保护，就可以获得他需要的东西。因此，我们建议使用下面的认证方式。 

采用 rsh 即可。

每个操作系统都有信任机制，如果用户 ID 相同，并且授权信任 是可以的。

具体做法是：

  1） 在 A 和 B  上建立相同 ID 的用户：这样可以相互 rsh ，但要口令

  2） 建立信任： 在 B 上该用户的主目录下，创建 .rhosts 文件，内容是：
           A主机名或IP地址  用户名
                 在 A 上该用户的主目录下，创建 .rhosts 文件，内容是：
           B主机名或IP地址  用户名

      这样 A 和 B 的该用户可以相互 rsh ,不需要口令了。
      .rhosts 可以有多行，主机名 或 用户名 填 + ，表示所有，慎用！

rlogin和ssh都是不错的选择，rlogin也有-8选项的，如果要求安全性，建议用ssh。

用shell写一个能登录到B机的程序（里面包含可登录B机的用户和密码），然后在A机的一个用户下，把该程序加入到“.profile”文件中。

用expect或perl/telnet写个脚本吧，当然也可用c写。

用netterm,设置登陆文件，可以直接登录n层机器