From ArchWiki
Jump to navigation Jump to search

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)


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 to the after line.

[Unit] Description = Permit User Sessions

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

After =

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)


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: 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?


--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:
Description=SSH tunnel

ExecStart=/usr/bin/ssh -F %h/.ssh/config -N foo@bar

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 ( == "org.freedesktop.login1.power-off" || == "org.freedesktop.login1.power-off-multiple-sessions" || == "org.freedesktop.login1.reboot" || == "org.freedesktop.login1.reboot-multiple-sessions" || == "org.freedesktop.login1.suspend" || == "org.freedesktop.login1.suspend-multiple-sessions" ||
  == "org.freedesktop.login1.hibernate" || == "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:

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)

Run command at login

Regarding the consideration for removal:

1) Using RemoteCommand and RequestTTY in the config breaks execution of custom commands like ssh host some command

Maybe a warning would be appropriate. Also you might never meed to execute remote commands on some specific host (for example if you are only using SSH for debugging purposes in an automated infrastructure. My typical use case is to always sudo -i [please don't comment on the security implications I am aware of]). You could also be willing to explicitly (or through an alias) remove the RemoteCommand and RequestTTY.

2) using ssh -t host "cat /etc/os-release

You can set an alias, or use it in an SSH wrapper.

3) There is no point in showing these hacks.

One of the point of showing use cases was to inform about the necessity to call you shell at the end, maybe a note would be more appropriate.

Overall, I agree that there is room for improvement, but I believe examples are useful for a quick introduction, and to prevent easily made mistakes. Apollo22 (talk) 20:45, 15 June 2019 (UTC)

If you always run sudo -i after logging in with SSH, you should log in directly as root using your SSH key instead. There is no point in showing hacks which need more warnings than the number of their sensible use cases. -- Lahwaacz (talk) 21:54, 15 June 2019 (UTC)
I use a central authentication scheme (FreeIPA), no keys stored on the hosts on a multi admin system (so every sudo is recorded). This is the reason I didn't use sudo -i as the example. -- Apollo22 (talk) 10:30, 16 June 2019 (UTC)
I don't see how FreeIPA makes this approach recommendable. If you're trying to automate management of your remote servers, you shouldn't try to reinvent the wheel. Closing. -- Lahwaacz (talk) 11:56, 13 July 2019 (UTC)
I never said anything about management automation. I usually use it for debug, when I need to access files that cannot be read bu other users.

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)