How not to reconfigure your sshd
Yesterday I wanted to reconfigure the
sshd on a remote machine.
Although I'd never done
sshd itself, I've done this kind of thing
a zillion times before. It looks like this: there is a configuration
file (in this case
/etc/ssh/sshd-config) that you modify. But this
doesn't change the running server; you have to notify the server that
it should reread the file. One way would be by killing the server and
starting a new one. This would interrupt service, so instead you can
send the server a different signal (in this case
SIGHUP) that tells
it to reload its configuration without exiting. Simple enough.
Except, it didn't work. I added:
Match User mjd
ForceCommand echo "I like pie!"
and signalled the server, then made a new connection to see if it
I like pie! instead of starting a shell. It started a
shell. Okay, I've never used
ForceCommand before, maybe
I don't understand how they work, I'll try something simpler. I
which seemed straightforward enough, and I put some text into
/etc/motd, but when I connected it didn't print the motd.
I tried a couple of other things but none of them seemed to work.
Okay, maybe the
sshd is not getting the signal, or something? I
hunted up the logs, but there was a report like what I expected:
sshd: Received SIGHUP; restarting.
This was a head-scratcher. Was I modifying the wrong file? It semed
hardly possible, but I don't administer this machine so who knows? I
lsof -p 1210 to see if maybe
sshd had some other config file
open, but it doesn't keep the file open after it reads it, so that was
Eventually I hit upon the answer, and I wish I had some useful piece
of advice here for my future self about how to figure this out. But I
don't because the answer just struck me all of a sudden.
(It's nice when that happens, but I feel a bit cheated afterward: I
solved the problem this time, but I didn't learn anything, so how
does it help me for next time? I put in the toil, but I didn't get
the full payoff.)
“Aha,” I said. “I bet it's because my connection is multiplexed.”
Normally when you make an
ssh connection to a remote machine, it
calls up the server, exchanges credentials, each side authenticates
the the other, and they negotiate an encryption key. Then the server
forks, the child starts up a login shell and mediates between the
shell and the network, encrypting in one direction and decrypting in
the other. All that negotiation and authentication takes time.
There is a “multiplexing” option you can use instead. The handshaking
process still occurs as usual for the first connection. But once the
connection succeeds, there's no need to start all over again to make a
second connection. You can tell
ssh to multiplex several virtual
connections over its one real connection. To make a new virtual
connection, you run
ssh in the same way, but instead of contacting
the remote server as before, it contacts the local
ssh client that's
already running and requests a new virtual connection. The client,
already connected to the remote server, tells the server to allocate a
new virtual connection and to start up a new shell session for it.
The server doesn't even have to fork; it just has to allocate another
pseudo-tty and run a shell in it. This is a lot faster.
I had my local
ssh client configured to use a virtual connection if
that was possible. So my subsequent
ssh commands weren't going
through the reconfigured parent server. They were all going through
the child server that had been forked hours before when I started my
first connection. It wasn't affected by reconfiguration of the parent
server, from which it was now separate.
I verified this by telling
ssh to make a new connection without
trying to reuse the existing virtual connection:
ssh -o ControlPath=none -o ControlMaster=no ...
This time I saw the MOTD and when I reinstated that
Match command I
I like pie! instead of a shell.
(It occurs to me now that I could have tried to SIGHUP the child
server process that my connections were going through, and that would
probably have reconfigured any future virtual connections through that
process, but I didn't think of it at the time.)
Then I went home for the day, feeling pretty darn clever, right up
until I discovered, partway through writing this article, that I can't
log in because all I get is
I like pie! instead of a shell.
[Other articles in category /Unix]