经常看到各种介绍SSH的技巧文章，有些至少对我来说非常实用，我就整理一下。文章都是来自互联网，不过内容我肯定是基本看懂，也肯定会注明出处。后续会把看到的SSH相关内容整理在这里

原文：http://www.javaranger.com/archives/968  下面内容全部来自原文，我只是做了一下格式排版而已。

什么是SSH？

Secure Shell（缩写为SSH），由IETF的网络工作小组（Network Working Group）所制定；SSH为一项创建在应用层和传输层基础上的安全协议，为计算机上的Shell（壳层）提供安全的传输和使用环境。
最初的SSH协议是由芬兰的一家公司的研究员Tatu Ylönen于1995年设计开发的，但是因为受版权和加密算法等等的限制，现在很多人都转而使用OpenSSH。OpenSSH是SSH的替代软件包，而且是开放源代码和免费的。

基本用法

SSH主要用于远程登录。假如用户名为java，登录远程主机名为linux或者使用IP，如下命令即可。SSH的默认端口是22，也就是说，你的登录请求会送进远程主机的22端口。使用p参数，可以修改这个端口。

ssh -p 88 java@linux
ssh -p 88 java@ip

安全验证

SSH之所以能够保证安全，原因在于它采用了公钥加密。
过程如下：

• 远程主机收到用户的登录请求，把自己的公钥发给用户。
• 用户使用这个公钥，将登录密码加密后，发送回来。
• 远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

口令登录

如果你是第一次登录对方主机，系统会出现下面的提示：你在windows用putty或者别的ssh客户端登陆，都基本可以看到类似的信息

ssh java@linux
#########
The authenticity of host ‘host (159.211.1.39)’ can’t be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

这段话的意思是，无法确认host主机的真实性，只知道它的公钥指纹，问你还想继续连接吗？
所谓”公钥指纹”，是指公钥长度较长（这里采用RSA算法，长达1024位），很难比对，所以对其进行MD5计算，将它变成一个128位的指纹。上例中是98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d，再进行比较，就容易多了。
很自然的一个问题就是，用户怎么知道远程主机的公钥指纹应该是多少？回答是没有好办法，远程主机必须在自己的网站上贴出公钥指纹，以便用户自行核对。
假定经过风险衡量以后，用户决定接受这个远程主机的公钥。

Are you sure you want to continue connecting (yes/no)? yes

系统会出现一句提示，表示host主机已经得到认可。

Warning: Permanently added ‘host,159.211.1.39′ (RSA) to the list of known hosts.

然后，会要求输入密码，如果密码正确，就可以登陆。

当远程主机的公钥被接受以后，它就会被保存在文件$HOME/.ssh/known_hosts之中。下次再连接这台主机，系统就会认出它的公钥已经保存在本地了，从而跳过警告部分，直接提示输入密码。

每个SSH用户都有自己的known_hosts文件，此外系统也有一个这样的文件，通常是/etc/ssh/ssh_known_hosts，保存一些对所有用户都可信赖的远程主机的公钥。

公钥登录

使用密码登录，每次都必须输入密码，非常麻烦。好在SSH还提供了公钥登录，可以省去输入密码的步骤。

所谓”公钥登录”，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。

这种方法要求用户必须提供自己的公钥。如果没有现成的，可以直接用ssh-keygen生成一个

ssh-keygen

运行上面的命令以后，系统会出现一系列提示，可以一路回车。其中有一个问题是，要不要对私钥设置口令（passphrase），如果担心私钥的安全，这里可以设置一个。
运行结束以后，在$HOME/.ssh/目录下，会新生成两个文件：id_rsa.pub和id_rsa。前者是你的公钥，后者是你的私钥。
这时再输入下面的命令，将公钥传送到远程主机host上面：

ssh-copy-id java@linux

从此你再登录，就不需要输入密码了。
如果还是不行，就打开远程主机的/etc/ssh/sshd_config这个文件，检查下面几行前面”#”注释是否取掉。

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

需要重启SSH服务才能生效。

authorized_keys文件

远程主机将用户的公钥，保存在登录后的用户主目录的$HOME/.ssh/authorized_keys文件中。公钥就是一段字符串，只要把它追加在authorized_keys文件的末尾就行了。

这里不使用上面的ssh-copy-id命令，改用下面的命令，解释公钥的保存过程：

ssh java@linux ‘mkdir -p .ssh && cat >> .ssh/authorized_keys’ < ~/.ssh/id_rsa.pub

• 登陆远程主机
• 如果用户主目录下.ssh 目录不存在，创建一个
• 把本地的公钥文件重定向追加到远程文件authorized_keys的末尾

写入authorized_keys文件后，公钥登录的设置就完成了。

今天看到淘宝的技术写了一篇交流总结。感觉也印证了我的很多想法。

1. 公司没有测试人员
2. 直接上线进行压力测试
3. 所有技术人员需要了解网站全部架构

 

下面转载内容http://blog.csdn.net/cenwenchu79/article/details/6196886

 

也算机缘巧合，一个不能称之为机会的机会让我再次和国外现在炙手可热的T公司(由于也不想过多的说这家公司的名字，因此就用T作为代号了)做了一次技术和公司文化的简单交流，这里做个简单的交流分享，希望能够让更多的朋友能够从中找到自己团队或者公司有帮助的内容。但这里还是丑话说在前头，中国有句成语：东施效颦。国外的月亮多圆我不知道，但是我们需要客观的看待不同环境的差异，看到目标，而不要过多模仿过程。下面的阐述将都分成场景和观点，如何做三部分，场景描述了具体的情况，观点仅仅代表我自己的一些感触和理解，如何做是对问题Action提出自己的想法。

场景1：

         T公司的任何一个小Team（业务上划分或者职能上划分）都需要熟悉整个系统从前到后从上到下的代码实现。例如相册团队，从前端脚本，到业务逻辑，再到底层的Memcached或者图片服务器代码在必要的时候都能自己修改和实现业务需求。UserGroup团队是负责对全球业务的用户做统计分析的，当希望做一些变革能够尝试着提升用户转化率的时候，首先是考虑自己如何动手去修改已有系统的功能，而不是去协调各个团队去做。

观点：

垂直化的开发模式其实挑战了国内很多企业的横向细分化流水线方式的开发模式。从技术的横向细分，到业务的模块化细分，好处是提高企业的生产效率，坏处是对人全方面的培养成为一种制约。最大的问题：对自己上游系统的需求了解不透彻，对自己依赖系统的实现完全不理解。

如何做：

横向切分的方式和纵向的方式都有适应的场景，因此可以考虑在互连网企业中部分部门中实施垂直化开发模式，这些部门人员素质较高，能够从产品层面全局的考虑整体的发展，通过实际的参与各个业务线和各个层次的技术中间件开发，为横向切分的部门工作做出改进和建议。这样在高素质人才发展和网站规模化整体化发展之间找到平衡点，相互促进。

场景2：

         T公司的任何一个技术框架都可以被挑战和替换，只要用数字和测试结果作为有效的证据，大家都抱着对公司负责的态度来对待技术选型。因此在T公司中，技术的发展完全是最原始的优胜劣汰机制。

观点：

这点其实很赞同，首先技术如果不是用数据来说话，采用自上而下的方式来决定选型，那么就是拍脑袋做事情。另一方面，如果技术不持续的按照用户需求来优化和演进，那么一定会烂掉，最好的触动不断发展的方式，就是竞争。有人会担心技术竞争会带来资源消耗，其实烂掉的东西在被使用的过程中一样在消耗。

如何做：

首先当然还是提倡积累，能够在已有的技术基础上不断积累发展是最好的，其次也应该鼓励创新，如果有足够理由证明成熟的技术能够替代现有技术，而现有技术又没有发展的动力时，变革并不是坏事（也许这种压力就会迫使原有技术实现者去更好服务客户），最后就是给每个人都有改变任何一部分代码的能力，因为依赖的不稳定也决定了上层系统的不稳定，作为一个产品来看，每个人是对产品负责，而不是对一个组件负责。

场景3：

没有任何文档。最多写一点wiki。

观点：

设计从简，代码需要更优雅，注释需要更全面。文档是代码的骨架。

如何做：

应该有产品需求文档，理解业务需求。技术文档多半是总体性设计和一些协议描述，多一些代码注释和Demo，更利于学习和阅读。

场景4：

应用都被编译在一个包里，一台机器就运行了诺大一个网站的所有功能，不存在服务器间的应用服务调用，都是本地服务方法调用（服务依赖较少）。

观点：

这和Java类型的应用还有些差别，Java的第三方依赖较多，版本凌乱复杂，导致应用部署在一台机器上很困难。但很多大型网站的系统设计慢慢地就将模块分的很细，结果导致服务调用和依赖特别复杂，自身的可用性和稳定性变得难以估量。

如何做：

需要审视服务粒度的合理性及垂直化设计在不同系统中的应用，需要在可扩展和可用性及效率中差别对待不同系统设计，同时降低服务差异性，减少应用服务器由于应用差异导致无法复用的问题。

场景5：

任何一个应用或者中间件开发完成后，都会有一个监控应用伴随诞生。（有些是直接通过已有工具实现，有些独立实现）

观点：

1：1的透明化开发比unit test来的还要重要，因为运行期的系统透明化是业务分析，系统优化，系统监控告警最基本的要求。

如何做：

最低代价就是将监控数据记录打点，应用或者外部系统对数据进行计算和分析，最终提供结果给外部系统展现和处理。

场景6：

没有测试团队，任何开发都是测试人员，通过工具完成页面，接口，集成测试。

观点：

强大的测试工具框架为开发人员提供了测试的规范性和便利性，同时开发人员自身的责任感增强，也让开发人员在测试过程中总结和思索开发设计的常规性错误，理解边界问题。

如何做：

需要有专人专职来负责测试框架的有效性，当然对于这个人或者这么一个小团队来说要求很高。可以借鉴的是，测试团队应该有更加高效的方式自动化测试，同时应该将测试框架开放给开发人员，增强开发人员对产品质量的责任感。

场景7：

没有线下的压力测试和极限测试，线上引流和部分区域发布来做测试。

观点：

一直认为线下的网络环境，用户数据的仿真度都难以模拟线上，因此很多压力测试和极限测试的数据基本就不能成为依据。在数据透明化体系完成后，线上的任何改变都可以获得数据的支持，这样单独或者对比的结果就是压力测试或者AB测试的结果。

如何做：

系统透明化工作为基础，结合Beta发布或者局部发布的模式来验证和测试不同压力下的新老系统。

场景8：

Hack Day，一个晚上通宵做出原型，第二天在全公司面前展现创意，用技术来说服有兴趣的同事一起去做一些有创意的工作。T公司最典型的视频项目就出自于Hack Day。

观点：

通过自己努力和时间的投入，在公司给的平台上展现，最后取得好的效果。

如何做：

公司给平台，个人挤时间。

场景9：

公司中所有的开发人员都是Engineer，每个人可能不同Level，但是每个人的工作都是自己来考虑，上级M只是替Engineer去协调资源。此时任何Team的人如果有想法和创意，如果要做，也需要资源，只能靠自己去说服同事一起做，而M没有权利否定或者强制Engineer去做任何工作。

观点：

由于考核都是同事之间点到点的评价，因此其实M没有任何实质性的技术管理职能在，任务分配和工作目标也是工程师自己需要去考虑的，主动权掌握在自己手中。工程师需要去考虑自己有限的工作时间中如何做有效的做出最有用的内容。能力越大责任越大，因此原本认为束缚工程师的方式，其实反而给工程师偷懒思考的机会。

如何做：

在工程师技术能力达到一定阶层时，国内的公司可以考虑采用这样的方式去管理他们，同时为他们提供更广阔的技术空间去创新和渗透到他们希望渗透的产品中。

场景10：

对于问题从效率角度去考虑如何解决，而不是简单的从资源角度去考虑。

观点：

公司发展壮大，业务战线不断变长，往往第一就考虑需要资源，往往忽略了如何用技术提升效率。增加资源有时候反而是增加内耗和降低工作效率的诱因。

如何做：

压力带来动力，决策者需要判断和观察。

场景11：

每个新人进来都会进入新兵训练营，每个人选择自己有兴趣加盟的两到三个团队，一个月内完成两到三个团队的一些线上问题修复，在熟悉业务的同时，也锻炼了自己的能力，同时更加明确自己感兴趣的团队究竟是哪一个。

观点：

这种方式可以最直接的让新人了解业务，熟悉将来的方向，同时也是检验一个人能力的最有效的手段。

场景12：

不同Level的错误有不同的通报，产生较大问题时，全公司邮件通报，但考核并不看问题发生次数和严重程度（因为每个人都可以修改各个层次内容，多做多错，少做少错这种事情不应该鼓励）。同时，任何过失需要描述四方面内容：现象，问题原因，解决方法，防范措施。范例：有一个同事修改了底层配置系统的部分代码，结果导致全站系统2小时不可用，全公司通报。遂这个同事花了几天时间全部重写了底层配置系统代码，为了防止别人和他犯一样的错误，后遇人都笑谈他重写代码的事，而不是那次问题。

观点：

首先，大家都抱着乐观的态度去看待犯错，看到别人的总结，也是审视自己的工作。其次，最重要的是问题的解决和预防，这点是透明化问题的关键所在，也是驱动犯错者改进自身不足的动力。

如何做：

倡导这种氛围，提升工程师的责任感。

场景13：

对于所有代码的更新时间有监控，很久没有更新的代码将会被提出来，作为烂掉的代码告警全团队。

观点：

很多时候不是做减法不易，而是没人知道什么时候该减什么。

时间有限，其实也没谈太多技术内部的东西，但是从周边的这些内容聊下来，两点让我感觉和去年自己做的一些工作很类似，也很重要。产品责任感，系统透明化。

不论是业务或者技术的垂直化，测试工作前移，产品设计后移（在另外文章中有提到），技术工作自我定义，其实都是在考验一个工程师对产品的责任感，不简单的约束自己在某一个技术领域，在某一个产品环节，在某一个岗位职责，也许听起来是一个较高Level的工程师（国内叫架构师）所需要考虑的，但其实也只有这样的工程师才会称得上是合格的工程师。

不论是1：1系统设计方式，线上仿真测试，丰富的监控系统，其实就是要求做每一个业务系统或者技术框架一定要做好透明化工作，系统透明化是对当前系统负责，对依赖这个系统的外部系统负责。当一个网站各个零部件都能被外部所观察到的时候，出现问题不为人知，缓慢出现量变病化，业务模式AB结果都将变得一目了然。