Difference between revisions of "Talk:OpenSSH"

From ArchWiki
Jump to navigation Jump to search
(last edit to page)
 
(53 intermediate revisions by 16 users not shown)
Line 5: Line 5:
  
 
simply specifing -X option to ssh works for me. [The preceding unsigned comment was added 2010-01-11T15:41:54 by [[User:Uwinkelvos|Uwinkelvos]] ([[User_talk:Uwinkelvos|Talk]] | [[Special:Contributions/Uwinkelvos|contribs]]).]
 
simply specifing -X option to ssh works for me. [The preceding unsigned comment was added 2010-01-11T15:41:54 by [[User:Uwinkelvos|Uwinkelvos]] ([[User_talk:Uwinkelvos|Talk]] | [[Special:Contributions/Uwinkelvos|contribs]]).]
 +
 +
 +
Upon another look at the SSH Forwarding section, as per the comment in the Stack Exchange link provided [https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely#comment17148_12772] the {{Pkg|xorg-xhost}} package is not needed on either the remote side or client side.
 +
However the {{Pkg|xorg-xauth}} package is needed on the side client for the {{ic|ForwardX11Trusted}} or {{ic|-X}} options to work.
 +
[[User:Jamesp9|Jamesp9]] ([[User talk:Jamesp9|talk]]) 10:56, 2 September 2017 (UTC)
 +
 +
I have to use export DISPLAY=:10.0 on the server after logging in before I can actually run any programme requiring X. --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 22:25, 26 September 2017 (UTC)
  
 
== SendEnv ==
 
== SendEnv ==
Line 183: Line 190:
 
--[[User:Stellarpower|Stellarpower]] ([[User talk:Stellarpower|talk]]) 12:24, 4 May 2015 (UTC)
 
--[[User:Stellarpower|Stellarpower]] ([[User talk:Stellarpower|talk]]) 12:24, 4 May 2015 (UTC)
  
== <s>Disabling root leaves `su`; suggested addition there:</s> ==
+
== Pseudo-terminal will not be allocated because stdin is not a terminal ==
 +
 
 +
 
 +
When you connect to a ssh server via a ssh relay using command like:
 +
 
 +
ssh user2@relay ssh user3@localhost -p 2222
 +
 
 +
without {{ic|-t}}, you will get errors like this:
 +
 
 +
Pseudo-terminal will not be allocated because stdin is not a terminal.
 +
Host key verification failed.
 +
 
 +
Because, without {{ic|-t}}, ssh is not going to allocate a tty for command {{ic|ssh user3@localhost -p 2222}}. {{man|1|ssh}}
 +
 
 +
Basically, if you want to execute a command which needs interactions, you need add {{ic|-t}}.
 +
 
 +
For eamlple:
 +
ssh -t user@server "tmux"
 +
 
 +
If you just execute a command which just outputs and doesn't need interactions, you could just omit the {{ic|-t}}.
 +
 
 +
For example:
 +
ssh user@server "echo test"
 +
 
 +
{{unsigned|12:59, 13 July 2019‎|Edward-p}}
 +
 
 +
:Thanks, but the flag is about a different command. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:21, 13 July 2019 (UTC)
 +
 
 +
== <s>Daemon management</s> ==
 +
''Mac does it, therefore we should too''? What? The links arguing that loading ssh on demand is the best idea ever since sliced bread don't provide any security attestation or context but only convenience. Having systemd listening to anything exposes systemd to attacks and systemd is the last think I want to expose in a system. For instance, one argument is that we cannot restart ssh remotely without being disconnected. 1) How common is that 2) Sounds like a good practice because, what ''holds'' that session and how that ''hold'' can be exploited is not even considered.
 +
 
 +
{{unsigned|18:51, 7 September|2019‎}}
 +
 
 +
:[[OpenSSH#Daemon_management]] has significantly changed since September, closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:59, 4 October 2019 (UTC)
 +
 
 +
== sshd.socket warnings ==
 +
 
 +
The warning list at [[OpenSSH#Daemon_management]] reads like FUD to me. The warnings are not constructive, they look like they are designed to scare people away.
 +
 
 +
Examples:
 +
 
 +
# {{Warning|If you continue using {{ic|sshd.socket}}, be aware of its issues:}}
 +
#* This doesn't read well to a new person. They are not "continuing" to use anything. It's basically aimed at existing users.
 +
#* Labels socket activation as "having issues".
 +
# {{Warning|Using {{ic|sshd.socket}} negates the {{ic|ListenAddress}} setting, so it will allow connections over any address. To achieve the effect of setting {{ic|ListenAddress}}, you must specify the port ''and'' IP for {{ic|ListenStream}} (e.g. {{ic|1=ListenStream=192.168.1.100:22}}) by [[edit]]ing {{ic|sshd.socket}}. You must also add {{ic|1=FreeBind=true}} under {{ic|[Socket]}} or else setting the IP address will have the same drawback as setting {{ic|ListenAddress}}: the socket will fail to start if the network is not up in time.}}
 +
#* Not constructive.
 +
#* {{ic|sshd.service}} also listens on {{ic|0.0.0.0}} and {{ic|[::]}} by default, there is no difference. It sounds like this behavior is an "issue" with {{ic|sshd.socket}}.
 +
#* This criticism could rather have been pointed out as a paragraph or a tip: {{Tip|To let {{ic|sshd.socket}} listen on a specific address, [[edit]] {{ic|sshd.socket}}. Set {{ic|1=ListenStream=}}...}}
 +
# {{Warning|When using socket activation a transient instance of {{ic|sshd@.service}} will be started for each connection (with different instance names). Therefore, neither {{ic|sshd.socket}} nor the daemon's regular {{ic|sshd.service}} allow to monitor connection attempts in the log. The logs of socket-activated instances of SSH can be seen with {{ic|journalctl -u "sshd@*"}} or with {{ic|journalctl /usr/bin/sshd}}.}}
 +
#* This is a quite negative perspective.
 +
#* It's not true: {{ic|sshd.socket}} or {{ic|sshd.service}} don't ''disallow'' monitoring connection attempts in the log. I'm not quite sure what that statement even means. Everything is certainly logged, regardless of whether {{ic|sshd.service}} or {{ic|sshd.socket}} is used.
 +
#* This could suffice: {{Tip|To views logs of {{ic|sshd.socket}} activated instances, run for example {{ic|journalctl /usr/bin/sshd}}}}
 +
 
 +
It comes off as an attack on socket activation IMO, and while socket activation might not be wanted by everyone, it's certainly a valid thing to use:
 +
 
 +
* http://0pointer.de/blog/projects/systemd.html
 +
* http://0pointer.de/blog/projects/socket-activation.html
 +
* [[Improving_performance/Boot_process#Early_start_for_services]]
 +
 
 +
Does anybody else agree on it being overly negative? Should we change it to make it constructive?
 +
 
 +
[[User:Aude|Aude]] ([[User talk:Aude|talk]]) 11:43, 3 October 2019 (UTC)
 +
 
 +
:As you correctly guessed the warning is aimed at existing not new users. New users would not have {{ic|sshd.socket}} and {{ic|sshd@.service}} since they were removed from the {{Pkg|openssh}} package.
 +
:The criticism of placing it all in a [[Template:Warning]] is warranted, as previously it was split between a warning, note and tip. I rationalized it with the thought that after a while that whole warning could just be removed. I have now split them again, though differently than before.
 +
:There should be no issue if you want to make the section less scary, but keep in mind that it must be made clear that {{ic|sshd.socket}} is not supported by Arch and users are on their own if they use it.
 +
:-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:06, 3 October 2019 (UTC)
 +
 
 +
::That makes sense, I understand the rationale: {{ic|sshd.socket}} is deprecated.
 +
::The split you did now reads much better IMO.
 +
::What do you think about moving the {{ic|sshd.socket}} related stuff down to [[OpenSSH#Tips_and_tricks]]? I'm thinking it could make sense to move information about a deprecated feature out of the main information, to reduce noise.
 +
::[[User:Aude|Aude]] ([[User talk:Aude|talk]]) 08:53, 4 October 2019 (UTC)
 +
 
 +
:::You may move it to [[OpenSSH#Tips and tricks]], but then you should add example units or link to [https://git.archlinux.org/svntogit/packages.git/plain/trunk/sshd.socket?h=packages/openssh&id=303adf645ee1e9abbff35eee0e5c7c12e6121500 sshd.socket] & [https://git.archlinux.org/svntogit/packages.git/plain/trunk/sshd@.service?h=packages/openssh&id=303adf645ee1e9abbff35eee0e5c7c12e6121500 sshd@.service]. Also the first note must stay in [[OpenSSH#Daemon management]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:52, 4 October 2019 (UTC)
 +
 
 +
::::Okay, sounds good. I might do it. [[User:Aude|Aude]] ([[User talk:Aude|talk]]) 15:31, 5 October 2019 (UTC)
 +
 
 +
:Pointing out certain issues is not an attack on anything. I also don't think that the current wording is overly negative - certainly not more negative than the existence of the issues. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:56, 3 October 2019 (UTC)
 +
 
 +
== /etc/ssh/sshd_config ==
 +
 
 +
I added a critical security warning not to bind sshd to ports above 1024, but it was rolled back right after my edit. I have some more edits I'd make to the section, but I'll hold off if my contributions aren't welcome. Some things I'd address, in addition to general re-wording for clarity:
 +
 
 +
* The current section gives a "random" port that a non-root user could bind an arbitrary service to. It shouldn't be higher than 1024, as only root can bind to ports lower than that. If the sshd service failed to start for any reason (like mis-configuration), a malicious user could bind their own service to a port and pretend to be the sshd service if the port is higher than 1024. This is very bad.
 +
* The example of specifying a HostKey in the config uses rsa, but someone new to configuring this should probably see an example that uses ecdsa or ed25519 in case they follow the example.
 +
* The advice to disable passwords entirely should be more prominent, and mention that it should be enabled only long enough to copy over an authorized key.
 +
* The tip about listening to multiple ports is totally fine, but not really relevant to a section that should have some dense explanation of best practices in the first place someone looks when configuring sshd.
 +
 
 +
[[User:Szed|Szed]] ([[User talk:Szed|talk]]) 06:25, 1 December 2019 (UTC)
 +
 
 +
:Making significant changes to a critical page about security should always be discussed first. Your edit about ports >1024 was unsupported by '''any''' documentation. It is essentially FUD, as per https://security.stackexchange.com/questions/112072/risk-of-running-services-on-ports-1024 If you have got an authoratitive source, please incude it here. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 06:34, 1 December 2019 (UTC)
 +
 
 +
::Apologies, I'm new here and didn't mean to jump the gun on the edit. I am making the assumption that only ports up to 1024 are privileged on Arch as with other systems, but if that is indeed the case, an explanation of what that means is laid out in simple terms here https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html and further explanation here is more a comprehensive answer: https://stackoverflow.com/questions/10182798/why-are-ports-below-1024-privileged. These are all marginal risks; while running sshd on an unprivileged port certainly doesn't suddenly make a machine "hackable", neither does leaving it running on port 22, and an unprivileged port is a more appreciable risk to someone who is e.g. opening sshd on a desktop machine running other software like a web browser (which could therefore bind to the unprivileged port and pretend to be the sshd server). [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 06:57, 1 December 2019 (UTC)
 +
 
 +
:::I get the distinction between {,non-}privileged. What I was looking for was an authoratitive analysis of the risk around >1024 and how it is definitively "a bad thing". [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 07:06, 1 December 2019 (UTC)
 +
 
 +
:::: See RFC 7605 - Recommendations on Using Assigned Transport Port Numbers at https://tools.ietf.org/html/rfc7605. Details (though not particularly relevant) on how SSH received 22 at https://www.ssh.com/ssh/port. I'm not sure I can easily provide you an authoritative reference vis-a-vis the specific risk of running sshd on a port >1024, except to say there's no reason for privileged ports to exist besides this. [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 07:23, 1 December 2019 (UTC)
 +
 
 +
::::: After finally getting a change to review some more on this subject, I agree it isn't a big security issue worth concerning anyone over, though I do still think its important to add a note about the need to ensure the sshd service starts properly before allowing connections thought the firewall. Any feedback on my adding a note about using sshd -t to test that the config file throws no errors before enabling? [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 00:50, 6 December 2019 (UTC)
 +
 
 +
::::::I don't see how {{ic|sshd -t}} relates to unprivileged ports... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:16, 7 December 2019 (UTC)
 +
 
 +
:::::::I'm sorry to hear that. [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 19:01, 7 December 2019 (UTC)
 +
 
 +
=== suggestion: using test mode to avoid failed service on unprivileged port ===
 +
 
 +
Here's my proposed addition, at the top near the first mention of sshd_config, instead of making any mention of risks associated with failed services from this port conversation. [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 01:22, 6 December 2019 (UTC)
 +
 
 +
----
 +
 
 +
After editing this file, use test mode to check the configuration for errors:
 +
 
 +
{{ic|# sshd -t}}
 +
 
 +
If no errors are printed, the configuration is valid.
  
However, this does not disable {{ic|su}}, to do that, add users to wheel, and then disable
+
== disable known weak algorithms and ciphers ==
  
gpasswd -a $USER wheel
+
This is the currently listed order of algorithms recommended "disable known weak algorithms and ciphers" for this page.
  
And then uncomment the {{ic|auth required pam_wheel.so use_uid}} line in {{ic|/etc/pam.d/su}} [https://serverfault.com/questions/697607/ssh-su-root-or-sudo (src)][[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 18:22, 9 January 2017 (UTC)
+
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group18-sha512
 +
MACs umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
 +
HostKeyAlgorithms ssh-rsa,rsa-sha2-256,rsa-sha2-512
  
: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 does not reflect the security recommendations of the developers of OpenSSH, which can be found at https://man.openbsd.org/sshd_config. In particular, the HostKeyAlgorithms suggested here makes the least secure option the preferred first selection.Here are the orders from the default install's sshd_config in OpenBSD-current as of the OpenSSH 8.1 release, which I am using to update the wiki now:
  
: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)
+
  KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
 +
  MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 +
  HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
  
::The above gives {{ic|su}} to that user, you'd ssh into another user, which doesn't have wheel and isnt in sudoers. It closes those two avenues to get into root. {{ic|PermitRootLogin no}} is misleading, dont be detached from reality, it gives root login.
+
[[User:Szed|Szed]] ([[User talk:Szed|talk]]) 00:45, 6 December 2019 (UTC)
  
::The attack vector here is a compromised machine on the ssh-ing end here. There is a chance the password is guessable, it makes sense to try prevent that. Probably some other opening, sure, but then closing this hole is hardly much effort, at least if you're using a separate user already.[[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 14:44, 10 January 2017 (UTC)
+
:So you just copy-pasted the values from the OpenBSD's man page (which is the same as the one in Arch: {{man|5|sshd_config}}). This goes completely against the point of the section (first sentence): "The package's default configuration allows known weak algorithms and ciphers [...]" If the sentence is wrong/outdated, the whole section should be just removed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:12, 7 December 2019 (UTC)
  
:::I agree that the attack vector exists, but [[User:Lahwaacz|Lahwaacz]] is right in saying that that has nothing to do with [[Secure Shell]], and so it shouldn't be included on this page. If someone is truly worried about that attack, best practice is to [[Secure_Shell#Force_public_key_authentication]] and/or [[Secure_Shell#Protecting_against_brute_force_attacks]] -- [[User:Etskinner|Etskinner]] ([[User talk:Etskinner|talk]]) 15:45, 10 January 2017 (UTC)
+
:: "OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak." via source: https://www.openssh.com/legacy.html. Sounds like you should delete the whole section then. [[User:Szed|Szed]] ([[User talk:Szed|talk]]) 19:01, 7 December 2019 (UTC)

Latest revision as of 19:02, 7 December 2019

X11 forwarding

regarding X11 forwarding: i don't think it is necessary to enable X11Forwarding on the client on a global base: "Enable the ForwardX11 option in ssh_config on the client."

simply specifing -X option to ssh works for me. [The preceding unsigned comment was added 2010-01-11T15:41:54 by Uwinkelvos (Talk | contribs).]


Upon another look at the SSH Forwarding section, as per the comment in the Stack Exchange link provided [1] the xorg-xhost package is not needed on either the remote side or client side. However the xorg-xauth package is needed on the side client for the ForwardX11Trusted or -X options to work. Jamesp9 (talk) 10:56, 2 September 2017 (UTC)

I have to use export DISPLAY=:10.0 on the server after logging in before I can actually run any programme requiring X. --cfr (talk) 22:25, 26 September 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/


artomason (talk) 20:32, 7 February 2013 (UTC)

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.

Matyilona200 (talk) 13:45, 16 May 2013 (UTC)


follow_symlinks

The option 'transform_symlinks' does not work anymore, 'follow_symlinks' is the new one.

1. Should we correct that at the autossh section?

2. Should we write that somewhere?

--Greenway (talk) 17:14, 26 April 2014 (UTC)

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.
-- Kynikos (talk) 03:12, 28 April 2014 (UTC)


Sorry for this discussion and thank you for correcting me. I referred to this question: http://askubuntu.com/questions/75094/sshfs-transform-symlinks-is-broken Anyway I tested both parameters:

1) sshfs bar: foo

-a --> /etc     l
-b --> c/c1     l
-c              d 
--c1            f

2) sshfs -o follow_symlinks bar: foo

-a              d
-b              d
-c              d
--c1            f

(works as expected)

3) sshfs -o transform_symlinks bar: foo

(same as without the option.)

Here' s the wiki explanation

Following symlinks on the server side

The -o follow_symlinks option will enable this.

Making absolute symlinks work

Use the -o transform_symlinks option, which will transform absolute symlinks (ones which point somewhere inside the mount) into relative ones.


--Greenway (talk) 20:38, 28 April 2014 (UTC)

Regenerate host keys

I am using pre-load arch linux image on Raspberry Pi, which had openssh configured, so I want to regenerate new host keys, which could be archived on Debian with

rm /etc/ssh/ssh_host_* && dpkg-reconfigure openssh-server

Do we have equivalent command on Arch? I can't find them on the wiki

 ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
 ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
 ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key

should be enough? Or more setting is required?

Ref:

--Lefthaha (talk) 24 May 2014

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.

Running AutoSSH this way worked for me for a Socks 5 proxy:

autossh -f -M 1111 -N -i /home/username/.ssh/id_rsa username@server -D 8080

--Twofive0 (talk) 18:24, 12 August 2014 (UTC)

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:
~/.config/systemd/user/autossh.service
[Unit]
Description=SSH tunnel

[Service]
Type=simple
Restart=always
RestartSec=1min
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N foo@bar

[Install]
WantedBy=default.target
This seems a little nicer to me, but I'm not sure how I would edit the article to include it.
Silverhammermba (talk) 00:32, 12 February 2015 (UTC)

Additional steps to setup Dropbear

Noticed that you need to create some keys before Dropbear will run:

dropbearkey -t dss -f /etc/dropbear/dropbear.dss
dropbearkey -t rsa -s 4096 -f /etc/dropbear/dropbear.rsa

Maybe it's a good idea to chmod this to 600 or something? —This unsigned comment is by MindTooth (talk) 5 December 2014. Please sign your posts with ~~~~!

To note: Not relating to dropbear, but generally #Regenerate_host_keys above suggests the addition of a setup step for that as well. --Indigo (talk) 14:19, 5 December 2014 (UTC)

Allowing SSH Users to Shutdown, Mount, etc. Without Root authentication

Merged from Allow users to shutdown. -- Alad (talk) 20:48, 23 May 2015 (UTC)

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:

polkit.addRule(function(action, subject) {
	if (	action.id == "org.freedesktop.login1.power-off" ||
		action.id == "org.freedesktop.login1.power-off-multiple-sessions" ||
		
		action.id == "org.freedesktop.login1.reboot" ||
		action.id == "org.freedesktop.login1.reboot-multiple-sessions" ||
		
		action.id == "org.freedesktop.login1.suspend" ||
		action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
        
		action.id == "org.freedesktop.login1.hibernate" ||
		action.id == "org.freedesktop.login1.hibernate-multiple-sessions"	) {

		if ( subject.isInGroup("mypowergroup") ){
			return polkit.Result.YES;
	}
}); 

There might be a neater way to do this rather than enumerating all the actions but I don't speak JavaScript. EDIT: See below:

https://gist.github.com/wooptoo/4013294/ccacedd69d54de7f2fd5881b546d5192d6a2bddb

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.

Thanks in advance for any advice --Stellarpower (talk) 12:24, 4 May 2015 (UTC)

Pseudo-terminal will not be allocated because stdin is not a terminal

When you connect to a ssh server via a ssh relay using command like:

ssh user2@relay ssh user3@localhost -p 2222

without -t, you will get errors like this:

Pseudo-terminal will not be allocated because stdin is not a terminal.
Host key verification failed.

Because, without -t, ssh is not going to allocate a tty for command ssh user3@localhost -p 2222. ssh(1)

Basically, if you want to execute a command which needs interactions, you need add -t.

For eamlple:

ssh -t user@server "tmux"

If you just execute a command which just outputs and doesn't need interactions, you could just omit the -t.

For example:

ssh user@server "echo test"

—This unsigned comment is by Edward-p (talk) 12:59, 13 July 2019‎. Please sign your posts with ~~~~!

Thanks, but the flag is about a different command. -- Lahwaacz (talk) 13:21, 13 July 2019 (UTC)

Daemon management

Mac does it, therefore we should too? What? The links arguing that loading ssh on demand is the best idea ever since sliced bread don't provide any security attestation or context but only convenience. Having systemd listening to anything exposes systemd to attacks and systemd is the last think I want to expose in a system. For instance, one argument is that we cannot restart ssh remotely without being disconnected. 1) How common is that 2) Sounds like a good practice because, what holds that session and how that hold can be exploited is not even considered.

—This unsigned comment is by 2019‎ (talk) 18:51, 7 September. Please sign your posts with ~~~~!

OpenSSH#Daemon_management has significantly changed since September, closing. -- Lahwaacz (talk) 10:59, 4 October 2019 (UTC)

sshd.socket warnings

The warning list at OpenSSH#Daemon_management reads like FUD to me. The warnings are not constructive, they look like they are designed to scare people away.

Examples:

  1. Warning: If you continue using sshd.socket, be aware of its issues:
    • This doesn't read well to a new person. They are not "continuing" to use anything. It's basically aimed at existing users.
    • Labels socket activation as "having issues".
  2. Warning: Using sshd.socket negates the ListenAddress setting, so it will allow connections over any address. To achieve the effect of setting ListenAddress, you must specify the port and IP for ListenStream (e.g. ListenStream=192.168.1.100:22) by editing sshd.socket. You must also add FreeBind=true under [Socket] or else setting the IP address will have the same drawback as setting ListenAddress: the socket will fail to start if the network is not up in time.
    • Not constructive.
    • sshd.service also listens on 0.0.0.0 and [::] by default, there is no difference. It sounds like this behavior is an "issue" with sshd.socket.
    • This criticism could rather have been pointed out as a paragraph or a tip:
      Tip: To let sshd.socket listen on a specific address, edit sshd.socket. Set ListenStream=...
  3. Warning: When using socket activation a transient instance of sshd@.service will be started for each connection (with different instance names). Therefore, neither sshd.socket nor the daemon's regular sshd.service allow to monitor connection attempts in the log. The logs of socket-activated instances of SSH can be seen with journalctl -u "sshd@*" or with journalctl /usr/bin/sshd.
    • This is a quite negative perspective.
    • It's not true: sshd.socket or sshd.service don't disallow monitoring connection attempts in the log. I'm not quite sure what that statement even means. Everything is certainly logged, regardless of whether sshd.service or sshd.socket is used.
    • This could suffice:
      Tip: To views logs of sshd.socket activated instances, run for example journalctl /usr/bin/sshd

It comes off as an attack on socket activation IMO, and while socket activation might not be wanted by everyone, it's certainly a valid thing to use:

Does anybody else agree on it being overly negative? Should we change it to make it constructive?

Aude (talk) 11:43, 3 October 2019 (UTC)

As you correctly guessed the warning is aimed at existing not new users. New users would not have sshd.socket and sshd@.service since they were removed from the openssh package.
The criticism of placing it all in a Template:Warning is warranted, as previously it was split between a warning, note and tip. I rationalized it with the thought that after a while that whole warning could just be removed. I have now split them again, though differently than before.
There should be no issue if you want to make the section less scary, but keep in mind that it must be made clear that sshd.socket is not supported by Arch and users are on their own if they use it.
-- nl6720 (talk) 12:06, 3 October 2019 (UTC)
That makes sense, I understand the rationale: sshd.socket is deprecated.
The split you did now reads much better IMO.
What do you think about moving the sshd.socket related stuff down to OpenSSH#Tips_and_tricks? I'm thinking it could make sense to move information about a deprecated feature out of the main information, to reduce noise.
Aude (talk) 08:53, 4 October 2019 (UTC)
You may move it to OpenSSH#Tips and tricks, but then you should add example units or link to sshd.socket & sshd@.service. Also the first note must stay in OpenSSH#Daemon management. -- nl6720 (talk) 09:52, 4 October 2019 (UTC)
Okay, sounds good. I might do it. Aude (talk) 15:31, 5 October 2019 (UTC)
Pointing out certain issues is not an attack on anything. I also don't think that the current wording is overly negative - certainly not more negative than the existence of the issues. -- Lahwaacz (talk) 18:56, 3 October 2019 (UTC)

/etc/ssh/sshd_config

I added a critical security warning not to bind sshd to ports above 1024, but it was rolled back right after my edit. I have some more edits I'd make to the section, but I'll hold off if my contributions aren't welcome. Some things I'd address, in addition to general re-wording for clarity:

  • The current section gives a "random" port that a non-root user could bind an arbitrary service to. It shouldn't be higher than 1024, as only root can bind to ports lower than that. If the sshd service failed to start for any reason (like mis-configuration), a malicious user could bind their own service to a port and pretend to be the sshd service if the port is higher than 1024. This is very bad.
  • The example of specifying a HostKey in the config uses rsa, but someone new to configuring this should probably see an example that uses ecdsa or ed25519 in case they follow the example.
  • The advice to disable passwords entirely should be more prominent, and mention that it should be enabled only long enough to copy over an authorized key.
  • The tip about listening to multiple ports is totally fine, but not really relevant to a section that should have some dense explanation of best practices in the first place someone looks when configuring sshd.

Szed (talk) 06:25, 1 December 2019 (UTC)

Making significant changes to a critical page about security should always be discussed first. Your edit about ports >1024 was unsupported by any documentation. It is essentially FUD, as per https://security.stackexchange.com/questions/112072/risk-of-running-services-on-ports-1024 If you have got an authoratitive source, please incude it here. Jasonwryan (talk) 06:34, 1 December 2019 (UTC)
Apologies, I'm new here and didn't mean to jump the gun on the edit. I am making the assumption that only ports up to 1024 are privileged on Arch as with other systems, but if that is indeed the case, an explanation of what that means is laid out in simple terms here https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html and further explanation here is more a comprehensive answer: https://stackoverflow.com/questions/10182798/why-are-ports-below-1024-privileged. These are all marginal risks; while running sshd on an unprivileged port certainly doesn't suddenly make a machine "hackable", neither does leaving it running on port 22, and an unprivileged port is a more appreciable risk to someone who is e.g. opening sshd on a desktop machine running other software like a web browser (which could therefore bind to the unprivileged port and pretend to be the sshd server). Szed (talk) 06:57, 1 December 2019 (UTC)
I get the distinction between {,non-}privileged. What I was looking for was an authoratitive analysis of the risk around >1024 and how it is definitively "a bad thing". Jasonwryan (talk) 07:06, 1 December 2019 (UTC)
See RFC 7605 - Recommendations on Using Assigned Transport Port Numbers at https://tools.ietf.org/html/rfc7605. Details (though not particularly relevant) on how SSH received 22 at https://www.ssh.com/ssh/port. I'm not sure I can easily provide you an authoritative reference vis-a-vis the specific risk of running sshd on a port >1024, except to say there's no reason for privileged ports to exist besides this. Szed (talk) 07:23, 1 December 2019 (UTC)
After finally getting a change to review some more on this subject, I agree it isn't a big security issue worth concerning anyone over, though I do still think its important to add a note about the need to ensure the sshd service starts properly before allowing connections thought the firewall. Any feedback on my adding a note about using sshd -t to test that the config file throws no errors before enabling? Szed (talk) 00:50, 6 December 2019 (UTC)
I don't see how sshd -t relates to unprivileged ports... -- Lahwaacz (talk) 15:16, 7 December 2019 (UTC)
I'm sorry to hear that. Szed (talk) 19:01, 7 December 2019 (UTC)

suggestion: using test mode to avoid failed service on unprivileged port

Here's my proposed addition, at the top near the first mention of sshd_config, instead of making any mention of risks associated with failed services from this port conversation. Szed (talk) 01:22, 6 December 2019 (UTC)


After editing this file, use test mode to check the configuration for errors:

# sshd -t

If no errors are printed, the configuration is valid.

disable known weak algorithms and ciphers

This is the currently listed order of algorithms recommended "disable known weak algorithms and ciphers" for this page.

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group18-sha512
MACs umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-rsa,rsa-sha2-256,rsa-sha2-512

This does not reflect the security recommendations of the developers of OpenSSH, which can be found at https://man.openbsd.org/sshd_config. In particular, the HostKeyAlgorithms suggested here makes the least secure option the preferred first selection.Here are the orders from the default install's sshd_config in OpenBSD-current as of the OpenSSH 8.1 release, which I am using to update the wiki now:

 KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
 MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa 

Szed (talk) 00:45, 6 December 2019 (UTC)

So you just copy-pasted the values from the OpenBSD's man page (which is the same as the one in Arch: sshd_config(5)). This goes completely against the point of the section (first sentence): "The package's default configuration allows known weak algorithms and ciphers [...]" If the sentence is wrong/outdated, the whole section should be just removed. -- Lahwaacz (talk) 15:12, 7 December 2019 (UTC)
"OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak." via source: https://www.openssh.com/legacy.html. Sounds like you should delete the whole section then. Szed (talk) 19:01, 7 December 2019 (UTC)