Ivan Shmakov wrote: > Bob Proulx writes: > > 2. Ensure that sshd is listening on port 22. > > > $ netstat -na | grep '0.0.0.0:22' > > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN > > As IPv6 is slowly conquering the world, I'd be checking for > :::22 just as well, e. g.:
Good point. I have yet to convert over to the IPv6 world. But in this case IPv4 was/is sufficient to verify that it was installed and running. Or rather in this case that it wasn't installed and wasn't running. > Also, neither . nor : are the characters that an ordinary shell > would treat as special, so single quotes aren't necessary. Sorry for not reducing to minimum form. I started out looking for ":22 " and so needed the quotes. I have many ports that started with 22XYZ and so needed to avoid the substring match. But then evolved it into 0.0.0.0:22 which didn't need the space and so went with it and didn't think to remove the quotes. > OTOH, grep(1) will treat . as any character, not period, thus -F > should be used. Consider, e. g.: > > $ printf %s\\n 0.0.0.0:22 1020:030:22 | grep '0.0.0.0:22' > 0.0.0.0:22 > 1020:030:22 > $ printf %s\\n 0.0.0.0:22 1020:030:22 | grep -F 0.0.0.0:22 > 0.0.0.0:22 > $ That is of course correct. But since the result is to the human eye I expect that a real person will be able to interpret what they see. I didn't happen to have any other matches when testing that on my real system and so didn't bother with it. I often use grep when more correctly I should be using sed. > > 3. Ensure that you can connect to the sshd port from the local host. > > Do this on the local host. > > > $ telnet localhost 22 > > ... > > Escape character is '^]'. > > SSH-2.0-OpenSSH_5.8p1 Debian-7 > > ^] <-- Use Control-] to escape > > telnet> quit <-- Then type quit to exit > > The Telnet protocol isn't the same as “no protocol.” In > particular, IIRC, Telnet treats a \xff code as special. Right. But telnet is installed on a default system and so doesn't need any more explanation. It is "Good Enough(TM)". We are not needing to interact with sshd more than simply getting a banner. It doesn't matter that telnet is has in-band control and other issues. I didn't want to make things more complicated than necessary. I contemplated talking about 'connect' here but then decided against it. If I were going to talk about using a different command such as 'connect' or goodness forbid 'nc' then I would be obligated to explain how to install that command first. And for relatively small gain. It wasn't worth it. But since you brought it up now I feel obligated. The 'connect' program is the superior choice in my opinion. > For network diagnostics, netcat (as of either netcat6, > netcat-openbsd, or netcat-traditional package) is generally > better. I realize that 'nc' is the grand old dog of the network connection utilities. But just the same it is really a terrible program. It by design ignores errors, or is it EOF, I can't remember. And so when trying to use it for things such as ssh ProxyCommand connections it tends to leave orphan 'nc' processes hanging around because they don't close themselves down properly when the network drops out. Some years ago I chased down the root cause that 'nc' processes were being left around but can't remember it now. But when I found out it was an intentional design decision I became less of a fan of it. For general network connectivity connections the best program IMNHO is the 'connect' program. It detects errors and EOF properly and therefore never leaves orphan 'connect' processes hanging around when used as an ssh proxy command. Check it out. # apt-get install connect-proxy http://bent.latency.net/bent/git/goto-san-connect-1.85/src/connect.html > And it can be interrupted by a plain ^C (C-c), BTW. The connect program is similar. The connect program is 8-bit clean and handles errors better. Try it, you will like it. :-) Bob
signature.asc
Description: Digital signature
