:This has nothing to do with SSH and is already mentioned on the [[su]] page. Closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:13, 9 January 2017 (UTC)

:This has nothing to do with SSH and is already mentioned on the [[su]] page. Closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:13, 9 January 2017 (UTC)

+

+

:I agree, I think that most people aren't interested in disabling su in this context, not to mention it provides no real security benefit (being able to sudo is nearly the same as being able to su, the top answer of your link even explains this). -- [[User:Etskinner|Etskinner]] ([[User talk:Etskinner|talk]]) 02:07, 10 January 2017 (UTC)

SendEnv

I think we should add something about accent/UTF-8/encoding.
Setting SendEnv LANG LC_* in /etc/ssh/ssh_config (client side) would be very useful.
—This unsigned comment is by LeCrayonVert (talk) 22 August 2010. Please sign your posts with ~~~~!

Automatically logout all SSH users when the sshd daemon is shutdown.

edit /lib/systemd/system/systemd-user-sessions.service and append network.target to the after line.

[Unit]
Description = Permit User Sessions

Documentation = man:systemd-user-sessions.service(8)

After = network.target remote-fs.target

then symlink /lib/systemd/system/systemd-user-sessions.service to /etc/systemd/system/

systemd failed to start sshd

It might be good to add, if systemctl status sshd shows that sshd failed, try and run /usr/sbin/sshd. This way if there is a bad configuration option (ie typo in /etc/ssh/sshd_conf), it is listed with line number.

Are you sure? I've just installed sshfs and the man page still mentions both options as separate functions. If transform_symlinks is really not working anymore, that's more likely a bug that must be reported upstream.

Anyway I'm just mentioning that also the sshfs article would be affected.

AutoSSH as a Service

AutoSSH doesn't like to run as a service without specifying a port. Using -M 0 and -f parameters in combination will result in the service not starting. Also, when starting as a service (-f option) SSH will not look in ~/.ssh for public keys. If you're using key authentication, the public key will need to be specified with the -i parameter. I assume this limitation would also apply when running as a systemd service.

Autossh as a service seems to be a little redundant, since autossh itself is basically just a service to restart ssh when it exits. I was about write a .service file for autossh when I realized I could cut out the middleman entirely:

The following describes what I did to allow power [EDIT: and mounting] operations on my machine from a SSH login. I'd be very grateful if anyone could tell me if this was correct and if so, I'll add this section to the page and add a link on the polkit examples.

I have a miniature server machine I use at home for automatic backups, and I used WOL to startup without user intervention, however I found out that issuing

systemctl poweroff

and friends works from a tty but from a remote login I get a message starting:

==== AUTHENTICATING FOR org.freedesktop.login1.power-off ====

and asking for a root password. After searching online it seemed that the right thing to do (but I'm not sure) was to write a polkit rule overriding the and place this before the defaults in /etc/polkit-1/rules.d/. Below is my rule:

Someone somewhere seemed to mention that polkit rules weren't the right way to go and there was something wrong with integration with logind/systemd but I didn't understand what he really meant and it was in a different context.

Disabling root leaves `su`; suggested addition there:

However, this does not disable su, to do that, add users to wheel, and then disable

gpasswd -a $USER wheel

And then uncomment the auth required pam_wheel.so use_uid line in /etc/pam.d/su(src)Jasper1984 (talk) 18:22, 9 January 2017 (UTC)

This has nothing to do with SSH and is already mentioned on the su page. Closing. -- Lahwaacz (talk) 22:13, 9 January 2017 (UTC)

I agree, I think that most people aren't interested in disabling su in this context, not to mention it provides no real security benefit (being able to sudo is nearly the same as being able to su, the top answer of your link even explains this). -- Etskinner (talk) 02:07, 10 January 2017 (UTC)