Sunday, March 8th, 2009 at 4:04 pm
上课的时候给学生留了个作业，让学生用xinetd来配置sshd，结果我自己没有搞定，太丢了。。。
按理说，sshd进程运行的时候，是不需要参数的，但是配置到xinetd之后，就是只能监听端口不能登陆系统。每次登陆，都会报如果错误：
ssh_exchange_identification: read: Connection reset by peer
如果加上-v参数查看的话，就会有这么一个报告：
debug1: ssh_exchange_identification: sshd re-exec requires execution with an absolute path
查到最后，后来是sshd如果用于inetd(xinetd)模式的时候，需要加上一个参数-i。
因为在inetd(xinetd)模式下，sshd在响应客户端之前要花上大约十秒的时候来重新生成一个服务器端的key，客户端不会花那么长的时间等待，所以就会报错。
而且，这个参数只用于inetd(xinetd)模式。
附正确的配置文件：
service ssh
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
disable = no
}
Thursday, January 8th, 2009 at 7:57 pm
来源：http://www.lupaworld.com/441/viewspace_1762.html
首先，认识下这三个非常强大的命令：
ssh -C -f -N -g -L listen_port:DST_Host:DST_port user@Tunnel_Host
ssh -C -f -N -g -R listen_port:DST_Host:DST_port user@Tunnel_Host
ssh -C -f -N -g -D listen_port user@Tunnel_Host
相关参数的解释：
-f Fork into background after authentication.
后台认证用户/密码，通常和-N连用，不用登录到远程主机。
-L port:host:hostport
将本地机(客户机)的某个端口转发到远端指定机器的指定端口. 工作原理是这样的, 本地机器上分配了一个 socket 侦听 port 端口, 一旦这个端口上有了连接, 该连接就经过安全通道转发出去, 同时远程主机和 host 的 hostport 端口建立连接. 可以在配置文件中指定端口的转发. 只有 root 才能转发特权端口. IPv6 地址用另一种格式说明: port/host/hostport
-R port:host:hostport
将远程主机(服务器)的某个端口转发到本地端指定机器的指定端口. 工作原理是这样的, 远程主机上分配了一个 socket 侦听 port 端口, 一旦这个端口上有了连接, 该连接就经过安全通道转向出去, 同时本地主机和 host 的 hostport 端口建立连接. 可以在配置文件中指定端口的转发. 只有用 root 登录远程主机才能转发特权端口. IPv6 地址用另一种格式说明: port/host/hostport
Read More »
Tuesday, December 30th, 2008 at 8:10 am
参考：http://www.simplehelp.net/2008/12/17/how-to-ssh-to-your-remote-server-without-entering-a-password-every-time/
由于工作关系，我经常需要在非常不同的Linux服务器上转上转去，原来每次登陆，系统都会提示你输入密码，这的确是一件很烦的事情，特别是你在需要对好几台机器工作的时候。后来，我学会了用SSH证书认证来取代普通的密码认证，这样子我就不用每次都输入密码了。OpenSSH允许远程执行命令，如果再加上证书使用，那就我就可以运行一些远程控制的脚本去控制许多许多机器，这个对我的工作非常有用。比如说，在需要在100台机器上添加许多相同的用户。。。
闲话少说，下面我们正式来创建证书：
首先，我们要给远程服务器创建一个公钥(public key)。在你的Linux系统上打开一个命令终端，运行如下命令：
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/calvin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/calvin/.ssh/id_rsa.
Your public key has been saved in /home/calvin/.ssh/id_rsa.pub.
在这一步里，系统将自动生成一个公钥(public key)并保存在/home/calvin/.ssh/id_rsa/.pub这个文件里面。在上面的命令执行过程中，我们只需要一直敲回车直接使用默认值就好了（如果你想具体了解，可以去看man page，也可以私下跟我讨论）。
接下来，我们要将这个公钥(public key)复制到远程机器上面去，以前这是一个比较麻烦的事，但是，现在我们只要一个命令就可以搞定：
# ssh-copy-id -i /home/calvin/.ssh/id_rsa.pub username@@remoteserver.com
用自己实际的用户名与服务器地址取代username和remoteserver.com（下同）。
在这里，你可以再试下ssh到远程服务器，应该是不会再提示要密码而直接登陆进去了。
当然，如果你的机器没有ssh-copy-id这个命令，我们也可以使用传统的方法：
# scp ~/.ssh/id_rsa.pub username@remoteserver.com:/home/username
然后，登陆到远程机器上进行下一步的操作：
# ssh username@remoteserver.com
# cat ~/id_rsa.pub >> ~/.ssh/authorized_keys2
接下来，我们要给~/.ssh/authorized_keys2 correctly这个文件设置正确的权限（权限不对，证书会被拒绝）
# chmod 644 ~/.ssh/authorized_keys2
Wednesday, July 16th, 2008 at 4:51 pm
今天调试机器的时候，由于目录权限问题导致密钥对无法工作，在重启sshd时，突然发现sshd启动不了，查看message也没有发现任何错误。最后在//var/log/secure下面找到这样的记录：
Jul 16 15:57:20 devchn sshd[20399]: fatal: daemon() failed: No such device
通过查看发现sshd的启动脚本只与/dev/null这个设置有关系。难道是这个文件有问题？
在linuxquestions.org找到了答案，原来真的跟这个文件有关系。
原来，是我开始有把/dev/null这个文件给破坏掉
通过查找历史记录，找到这么一条：
mv ALLDBS-2008-07.tgz /dev/null
/dev/null是一个字符块特殊文件，上面的命令会让他变成一个规则文件，这样，就会导致不少的程序重启时出问题
问题找到了，接下来重建这个文件就OK了
下列命令可以重建：
rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
再重启sshd，果然可以了
Tuesday, March 11th, 2008 at 6:42 pm
近来无聊无事，随便发一个SSH中常见的错误吧。
Last login: Sun Dec 28 17:33:02 2003 from 192.168.1.1
[root@mail root]# ssh -l knet 192.168.0.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
09:de:ab:29:81:7f:0b:7f:27:22:88:02:fd:99:98:00.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1
RSA host key for 192.168.0.2 has changed and you have requested strict checking.
Host key verification failed.
[root@mail root]#
上面这个提示，很多人应该都遇到过
其实处理很简单，
注意这一行：
Offending key in /root/.ssh/known_hosts:1
找到/root/.ssh/known_host
然后，直接跳到这行后面所接的那个数字行，将其删掉就可以了
这个问题基本上是因为IP的重分配置或者重装目标系统所造成的密钥不匹配造成的