From ArchWiki
Revision as of 13:42, 5 December 2014 by MindTooth (talk | contribs) (Additional steps to setup Dropbear: new section)
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).]


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.

Encrypted Socks Tunnel

It would be good to add how to configure chromium to use with the socks tunnel. I recommend this:

Add to your .bashrc the next lines:

   function unblock() {
       export SOCKS_SERVER=localhost:$port
       export SOCKS_VERSION=5
       chromium &

So, the next time you want to use chromium with the secure tunnel,

  $ unblock

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)

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?