Hello! 1. systemd services have a special key (-H) to connect to remote host via ssh. E.g. 'timedatectl -H user@host'. By default port 22 is used. But in very often cases admins change the default ssh-port in sshd-daemon settings (e.g. 41122). It's useful to avoid connections from ssh-bruteforce robots. But systemd has no way (I can't find it in man-pages for example) how to define the admin-defined ssh connection port (possibly, other ssh options are also not accessable). The workaround is to define: 'ssh -p 41122 user@host' in console and then, after connection in on, proceed 'timedatectl' on remote host. But in this way it's not clear the profit of sysmted's -H key and this functionality looks redundant as for me.
Solutions: ========== 1. To formalize the systemd-via-ssh connections like it was done for snmpssh [RFC5592] for example. 'grep snmp < /etc/services': snmp 161/tcp # SNMP snmp 161/udp # SNMP snmptrap 162/tcp # SNMPTRAP [Marshall_Rose] snmptrap 162/udp # SNMPTRAP [Marshall_Rose] snmp-tcp-port 1993/tcp # cisco SNMP TCP portsnmp-tcp-port 1993/udp # cisco SNMP TCP portoce-snmp-trap 2697/tcp # Oce SNMP Trap Port [Peter_Teeuwen] oce-snmp-trap 2697/udp # Oce SNMP Trap Port [Peter_Teeuwen] websphere-snmp 3427/tcp # WebSphere SNMP [Richard_Mills] websphere-snmp 3427/udp # WebSphere SNMP [Richard_Mills] snmpssh 5161/tcp # SNMP over SSH Transport Model [RFC5592] snmpssh-trap 5162/tcp # SNMP Notification over SSH Transport Model [RFC5592] patrol-snmp 8161/tcp # Patrol SNMP [Portnoy_Boxman] patrol-snmp 8161/udp # Patrol SNMP [Portnoy_Boxman] snmptls 10161/tcp # SNMP-TLS [RFC6353] snmpdtls 10161/udp # SNMP-DTLS [RFC6353] snmptls-trap 10162/tcp # SNMP-Trap-TLS [RFC6353] snmpdtls-trap 10162/udp # SNMP-Trap-DTLS [RFC6353] suncacao-snmp 11161/tcp # sun cacao snmp access point [Nick_Stephen] suncacao-snmp 11161/udp # sun cacao snmp access point [Nick_Stephen] So, we'll have systemd-ssh via hard-defined tcp\udp port described in RFC. And if there's no systemd on remote host, user will get a message like "Cannot proceed on non-systemd host". 2. To extend current -H key functionality with other ssh options (e.g. -p). 3. To delete the redundant functionality (-H key) from systemd services and to continue to use traditional non-systemd-ways (ssh -p 123 user@host). By the way, I think the 1. is also acceptable to systemd-journal-gatewayd\-upload\-remote, if their functionality would be extended with ssh-transmission suppotring (via scp). Thank you! _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
