You are not logged in.
I made a custom sshd.service file to get sshd starting at boot with a ListenAddress configured, which worked. I did some searching to see if this was best practice, and found the sshd.socket method in the wiki.
So I disabled sshd.service, enabled sshd.socket and rebooted. Problem is, my ListenAddress
$ cat /etc/ssh/sshd_config
...
#Port 22
AddressFamily inet
ListenAddress 199.200.1.111
#ListenAddress ::
...
is not being honoured when I use sshd.socket:
$ systemctl status sshd.socket
sshd.socket
Loaded: loaded (/usr/lib/systemd/system/sshd.socket; enabled)
Active: active (listening) since Thu 2013-08-01 14:55:21 EDT; 8min ago
Listen: [::]:22 (Stream)
Accepted: 2; Connected: 1
The system has two NICs (net0: 199.200.1.111 net1: 10.10.1.5). When sshd.socket is running I can ssh in through both. When sshd.service is running I can only ssh in through net0 as intended.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I think you'll have to add it to the sshd.socket unit. I also ran into a similar issue with the port. I cahnged it in sshd_config, but the socket starts before the daemon when you enable it insetad, so you have to specify it there. Check out the systemd.socket man page. There is a ListenStream= configuration option which might be what yu are looking for.
Offline
Thanks for the info, the wiki seemed to indicate ListenStream was just for specifying an alternate port. That said, configuring ListenStream= works, but it seems to get me back to where I started: the socket won't start until the network device is up.
Even ignoring that, this behaviour doesn't seem right. As I understand it, the purpose of the socket is to start the daemon. How does it follow that the daemon should ignore some of its configuration if started by the socket? I say 'some' because I'm logging in as root for now, so it can't be ignoring it entirely.
Without the ListenStream configured, I would expect any incoming connection to cause the daemon to start, but not necessarily be able to connect.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Thanks for the info, the wiki seemed to indicate ListenStream was just for specifying an alternate port. That said, configuring ListenStream= works, but it seems to get me back to where I started: the socket won't start until the network device is up.
Without a network interface, you cannot receive connections, so the service won't be started. The first connection can be opened after the network is up.
Even ignoring that, this behaviour doesn't seem right. As I understand it, the purpose of the socket is to start the daemon. How does it follow that the daemon should ignore some of its configuration if started by the socket? I say 'some' because I'm logging in as root for now, so it can't be ignoring it entirely.
The socket unit opens the port, accepts the connection and then forwards the open socket to sshd. sshd never opens the port, so it ignores this configuration option. It is similar to xinetd, but supports more socket types.
Without the ListenStream configured, I would expect any incoming connection to cause the daemon to start, but not necessarily be able to connect.
Sorry, systemd socket units are designed to work only with the specified socket types and ports.
Last edited by progandy (2013-08-01 20:30:35)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Without a network interface, you cannot receive connections, so the service won't be started. The first connection can be opened after the network is up.
I understand why the sshd fails to start in my configuration, but [according to the wiki] sshd.socket is supposed to be an alternative in such a case. However, from what I've seen it also fails to start when configured to do the same thing. This makes it a poor alternative IMO.
The socket unit opens the port, accepts the connection and then forwards the open socket to sshd. sshd never opens the port, so it ignores this configuration option. It is similar to xinetd, but supports more socket types.
If the socket itself accepts an ssh connection, I guess it makes sense. But I still think it's bad practice for a security config to be silently ignored. Based on the content of the wiki, I bet there are people who think they're only accessible over ListenAddress but are really accessible over any address.
Sorry, systemd socket units are designed to work only with the specified socket types and ports.
Much like the ISS, that's way over my head.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
I'm planning on editing the wiki based on my understanding of the issue. Since I'm using 'understanding' loosely, I was hoping someone would look it over first:
Using sshd.socket effectively negates the ListenAddress setting, so using the default sshd.socket will allow connections over any address. To achieve the effect of setting ListenAddress, you must create a custom unit file and modify ListenStream (ie. ListenStream=192.168.1.100:22 is equivalent to ListenAddress 192.168.1.100). However, doing so has the same drawback as setting ListenAddress: the socket will fail to start if the network is not up in time.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Looks good to me... I think this is a good addition. Great work alphaniner!
Offline