https://wiki.archlinux.org/api.php?action=feedcontributions&user=Cteeto&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:40:39ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=OpenSSH&diff=224772OpenSSH2012-09-23T22:23:34Z<p>Cteeto: </p>
<hr />
<div>[[Category:Daemons and system services]]<br />
[[Category:Secure Shell]]<br />
[[es:Secure Shell]]<br />
[[fr:ssh]]<br />
[[it:Secure Shell]]<br />
[[ko:Secure Shell]]<br />
[[pl:Secure Shell]]<br />
[[pt:Secure Shell]]<br />
[[ru:Secure Shell]]<br />
[[sr:Secure Shell]]<br />
[[zh-CN:Secure Shell]]<br />
'''Secure Shell''' ('''SSH''') is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an ''sshd'' daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
(Source: [[Wikipedia:Secure Shell]])<br />
<br />
== OpenSSH ==<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
=== Installing OpenSSH ===<br />
[[pacman|Install]] {{Pkg|openssh}} from the [[official repositories]].<br />
<br />
=== Configuring SSH ===<br />
====Client====<br />
The SSH client configuration file can be found and edited in {{ic|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{hc|/etc/ssh/ssh_config|<br />
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
# Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
# ProxyCommand ssh -q -W %h:%p gateway.example.com<br />
}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
====Daemon====<br />
The SSH daemon configuration file can be found and edited in {{ic|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{hc|/etc/ssh/sshd_config|2=<br />
# $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#AddressFamily any<br />
#ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# The default requires explicit activation of protocol 1<br />
#Protocol 2<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh_host_key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh_host_rsa_key<br />
#HostKey /etc/ssh/ssh_host_dsa_key<br />
#HostKey /etc/ssh/ssh_host_ecdsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 1024<br />
<br />
# Logging<br />
# obsoletes QuietMode and FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you do not trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
ChallengeResponseAuthentication no<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing, <br />
# and session processing. If this is enabled, PAM authentication will <br />
# be allowed through the ChallengeResponseAuthentication and<br />
# PasswordAuthentication. Depending on your PAM configuration,<br />
# PAM authentication via ChallengeResponseAuthentication may bypass<br />
# the setting of "PermitRootLogin without-password".<br />
# If you just want the PAM account and session checks to run without<br />
# PAM authentication, then enable this but set PasswordAuthentication<br />
# and ChallengeResponseAuthentication to 'no'.<br />
UsePAM yes<br />
<br />
#AllowAgentForwarding yes<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression delayed<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
#PermitTunnel no<br />
#ChrootDirectory none<br />
<br />
# no default banner path<br />
#Banner none<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server<br />
<br />
# Example of overriding settings on a per-user basis<br />
#Match User anoncvs<br />
# X11Forwarding no<br />
# AllowTcpForwarding no<br />
# ForceCommand cvs server<br />
}}<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
To disable root login over SSH, change the PermitRootLogin line into this:<br />
PermitRootLogin no<br />
<br />
To add a nice welcome message edit the file {{ic|/etc/issue}} and change the Banner line into this:<br />
Banner /etc/issue<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts. To help select a port review the [[Wikipedia:List of TCP and UDP port numbers|list of TCP and UDP port numbers]].<br />
<br />
{{Tip|Disabling password logins entirely will greatly increase security, see [[SSH Keys]] for more information.}}<br />
<br />
=== Managing the sshd daemon ===<br />
Just add sshd to the "DAEMONS" array of your {{ic|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# rc.d {start|stop|restart} sshd<br />
<br />
=== Enabling the sshd daemon under a native systemd system === <br />
You can enable the sshd daemon at startup with the following command:<br />
<br />
{{bc|# systemctl enable sshd.service}}<br />
<br />
Or you can enable SSH Daemon socket so the daemon is started on the first incoming connection :<br />
<br />
{{bc|# systemctl enable sshd.socket}}<br />
<br />
===Connecting to the server===<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
== Other SSH clients and servers ==<br />
<br />
Apart from OpenSSH, there are many [http://en.wikipedia.org/wiki/Comparison_of_SSH_clients SSH clients] and [http://en.wikipedia.org/wiki/Comparison_of_SSH_servers servers] avaliable.<br />
<br />
=== Dropbear ===<br />
<br />
[http://en.wikipedia.org/wiki/Dropbear_%28software%29 Dropbear] is ssh 2 client and server. It's only SSH2 capable (protocol 1 is considered insecure). You could install via [https://aur.archlinux.org/packages.php?ID=1657 AUR]<br />
<br />
The commandline ssh client is named dbclient. You could alias via<br />
<br />
alias ssh='dbclient'<br />
<br />
== Tips and tricks ==<br />
<br />
=== Mobile Shell - responsive, survives disconnects ===<br />
<br />
From the Mosh website [http://mosh.mit.edu/] :<br />
<br />
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.<br />
<br />
[[pacman|Install]] {{Pkg|mosh}} from the [[official repositories]] or the latest revision from {{AUR|mosh-git}}.<br />
<br />
If you get "mosh requires a UTF-8 locale.", see the FAQ on the website.<br />
<br />
=== Encrypted SOCKS tunnel ===<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.<br />
<br />
==== Step 1: start the connection ====<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Ic|"user"}} is your username at the SSH server running at the {{Ic|"host"}}. It will ask for your password, and then you're connected! The {{Ic|"N"}} flag disables the interactive prompt, and the {{Ic|"D"}} flag specifies the local port on which to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{ic|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Ic|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Ic|"sshtunnel"}} command :)<br />
<br />
==== Step 2: configure your browser (or other programs) ====<br />
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.<br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:<br />
<br />
# Type about:config into the Firefox location bar.<br />
# Search for network.proxy.socks_remote_dns<br />
# Set the value to true.<br />
# Restart the browser.<br />
<br />
* For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your {{ic|.bashrc}}:<br />
function secure_chromium {<br />
port=4711<br />
export SOCKS_SERVER=localhost:$port<br />
export SOCKS_VERSION=5<br />
chromium &<br />
exit<br />
}<br />
OR<br />
function secure_chromium {<br />
port=4711<br />
chromium --proxy-server="socks://localhost:$port" &<br />
exit<br />
}<br />
<br />
Now open a terminal and just do:<br />
$ secure_chromium<br />
<br />
Enjoy your secure tunnel!<br />
<br />
=== X11 forwarding ===<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client (here "client" means your (desktop) machine your X11 Server runs on, and you will run X applications on the "server").<br />
<br />
[[pacman|Install]] {{Pkg|xorg-xauth}} from the [[official repositories]] onto the server.<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{ic|ssh'''d'''_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
Also:<br />
* Enable the '''ForwardX11''' option in {{ic|ssh_config}} on the '''client'''.<br />
<br />
Enable the '''ForwardX11Trusted''' can help when gui drawing badly.<br />
<br />
You need to restart the ssh daemon on the server for these changes to take effect, of course.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
$ ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
$ ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
$ xclock<br />
<br />
<br />
If you get "Cannot open display" errors try the following command as the non root user:<br />
$ xhost +<br />
<br />
the above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:<br />
$ xhost +hostname<br />
<br />
where hostname is the name of the particular host you want to forward to. Type "man xhost" for more details.<br />
<br />
Be careful with some applications as they check for a running instance on the local machine. Firefox is an example. Either close running Firefox or use the following start parameter to start a remote instance on the local machine<br />
$ firefox -no-remote<br />
<br />
If you get "X11 forwarding request failed on channel 0" when you connect (and the server /var/log/errors.log shows "Failed to allocate internet-domain X11 display socket"), try to either<br />
* Enable the '''AddressFamily any''' option in {{ic|ssh'''d'''_config}} on the '''server''', or<br />
* Set the '''AddressFamily''' option in {{ic|ssh'''d'''_config}} on the '''server''' to inet.<br />
Setting it to inet may fix problems with Ubuntu clients on IPv4.<br />
<br />
=== Forwarding other ports ===<br />
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.<br />
<br />
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the {{Ic|-L}} switch and it's accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -L 1000:mail.google.com:25 192.168.0.100<br />
<br />
will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.<br />
<br />
Similarly:<br />
<br />
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100<br />
<br />
will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.<br />
<br />
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200<br />
<br />
will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.<br />
<br />
Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel, {{Ic|localhost}}, {{Ic|*}} (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{Ic|sshd_config(5)}} for more information.<br />
<br />
=== Speeding up SSH ===<br />
You can make all sessions to the same host use a single connection, which will greatly speed up subsequent logins, by adding these lines under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. '''Please do not do this unless you know what you are doing; arcfour has a number of known weaknesses'''. To use them, run SSH with the {{Ic|"c"}} flag, like this:<br />
$ ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Ic|"C"}} flag. A permanent solution is to add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Ic|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{ic|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
<br />
==== Troubleshooting ====<br />
Make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
$ ssh -X user@server-address<br />
server $ echo $DISPLAY<br />
localhost:10.0<br />
server $ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to {{ic|/etc/hosts}}.<br />
<br />
=== Mounting a remote filesystem with SSHFS ===<br />
<br />
[[pacman|Install]] {{Pkg|sshfs}} from the [[official repositories]].<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{ic|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{ic|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Ic|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto,allow_other 0 0<br />
<br />
=== Keep alive ===<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to {{ic|~/.ssh/config}} or to {{ic|/etc/ssh/ssh_config}} on the client.<br />
<br />
ServerAliveInterval 120<br />
<br />
This will send a "keep alive" signal to the server every 120 seconds.<br />
<br />
Conversely, to keep incoming connections alive, you can set<br />
<br />
ClientAliveInterval 120<br />
<br />
(or some other number greater than 0) in {{ic|/etc/ssh/sshd_config}} on the server.<br />
<br />
=== Saving connection data in ssh config ===<br />
Whenever you want to connect to a ssh server, you usually have to type at least its address and the username. To save that typing work for servers you regularly connect to, you can use the personal {{ic|$HOME/.ssh/config}} or the global {{ic|/etc/ssh/ssh_config}} files as shown in the following example:<br />
<br />
{{hc|$HOME/.ssh/config|<br />
Host myserver<br />
HostName 123.123.123.123<br />
Port 12345<br />
User bob<br />
Host other_server<br />
HostName test.something.org<br />
User alice<br />
CheckHostIP no<br />
Cipher blowfish<br />
}}<br />
<br />
Now you can simply connect to the server by using the name you specified:<br />
<br />
$ ssh myserver<br />
<br />
To see a complete list of the possible options, check out ssh_config's manpage on your system or the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config documentation] on the official website.<br />
<br />
=== Changing the Bash prompt when logged in over SSH ===<br />
It can sometimes be useful to make a difference between your local and your remote prompt, in particular when they are both configured in the same way. To do that, just insert this in the remote server's bashrc file:<br />
<br />
{{hc|$HOME/.bashrc|2=<br />
if [ -n "$SSH_CLIENT" ]; then<br />
PS1='\[\e[0;33m\]\u@\h:\wSSH$\[\e[m\] '<br />
else<br />
PS1='\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\ e[m\] '<br />
fi<br />
}}<br />
<br />
See [[Color Bash Prompt]] for more information about the PS1 variable customization.<br />
<br />
=== Automatically logout all SSH users when the sshd daemon is shutdown ===<br />
To automatically log out all remote ssh users when the sshd server system shuts down, for reboot or halt, add this line to /etc/rc.local.shutdown on the sshd server:<br />
<br />
who | cut -d " " -f1 | uniq | xargs pkill -KILL -u<br />
<br />
This prevents ssh client terminals from hanging during a lengthy timeout, which eventually ends with:<br />
<br />
Write failed: Broken pipe<br />
<br />
=== Autossh - automatically restarts SSH sessions and tunnels ===<br />
When a ssh session or tunnel cannot be kept alive, because for example bad network conditions cause the sshd client to disconnect, you can use [http://www.harding.motd.ca/autossh/ Autossh] to automatically restart them. Autossh can be installed from the [[official repositories]]. <br />
<br />
Usage examples:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com<br />
Combined with [[ sshfs ]]:<br />
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example <br />
Connecting through a SOCKS-proxy set by [[ Proxy_settings ]]:<br />
$ autossh -M 0 "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com <br />
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively.<br />
<br />
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.<br />
<br />
== Troubleshooting ==<br />
=== Connection refused or timeout problem ===<br />
<br />
==== Is your router doing port forwarding? ====<br />
The first thing is to make sure that your router knows to forward any incoming ssh connection to your machine. Your external IP is given to you by your ISP, and it is associated with any requests coming out of your router. So your router needs to know that any incoming ssh connection to your external IP needs to be forwarded to your machine running sshd.<br />
<br />
Find your internal network address.<br />
<br />
ifconfig<br />
<br />
Find your interface device and look for the inet field. Then access your router's configuration web interface, using your router's IP (find this on the web). Tell your router to forward it to your inet IP. Go to [http://portforward.com/] for more instructions on how to do so for your particular router.<br />
<br />
==== Is SSH running and listening? ====<br />
# netstat -tnlp | grep ssh<br />
<br />
If the above command doesn't display anything, then SSH is NOT running. Check {{ic|/var/log/messages}} for errors etc.<br />
<br />
==== Are there firewall rules blocking the connection? ====<br />
Flush your iptables rules to make sure they are not interfering:<br />
<br />
# rc.d stop iptables<br />
<br />
or:<br />
<br />
# iptables -P INPUT ACCEPT<br />
# iptables -P OUTPUT ACCEPT<br />
# iptables -F INPUT<br />
# iptables -F OUTPUT<br />
<br />
==== Is the traffic even getting to your computer? ====<br />
Start a traffic dump on the computer you're having problems with:<br />
<br />
# tcpdump -lnn -i any port ssh and tcp-syn<br />
<br />
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).<br />
<br />
==== Your ISP or a third party blocking default port? ====<br />
{{Note|Try this step if you '''KNOW''' you aren't running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still doesn't work. Here you will find diagnostic steps and a possible solution.}}<br />
<br />
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely. <br />
<br />
If you get an error message comparable to this:<br />
ssh: connect to host www.inet.hr port 22: Connection refused<br />
<br />
That means the port '''ISN'T ''' being blocked by the ISP, but the server doesn't run SSH on that port (See [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).<br />
<br />
However, if you get an error message comparable to this:<br />
ssh: connect to host 111.222.333.444 port 22: Operation timed out <br />
<br />
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervetion (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you aren't running any firewall on your computer, and you know that Gremlins aren't growing in your routers and switches, then your ISP is blocking the traffic.<br />
<br />
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (See [http://en.wikipedia.org/wiki/TCP/IP_model IP Network stack]), if you don't receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.<br />
<br />
===== Diagnosis via Wireshark =====<br />
<br />
First install Wireshark using pacman.<br />
pacman -Sy wireshark-cli <br />
<br />
And then run it using,<br />
tshark -f "tcp port 22" -i NET_IF<br />
<br />
where NET_IF is the network interface for a WAN connection (see {{ic|ifconfig}} to check). If you aren't receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.<br />
<br />
===== Possible solution =====<br />
The solution is just to use some other port that the ISP isn't blocking. Open the {{ic|/etc/ssh/sshd_config}} and configure the file to use different ports. For example, add:<br />
<br />
Port 22<br />
Port 1234<br />
<br />
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" won't solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports. <br />
<br />
Restart the server {{ic|/etc/rc.d/sshd restart}} and you're almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let's cover two of them here.<br />
<br />
===== Client configuration (Quick/Greedy fix) =====<br />
<br />
Create an alias in your {{ic|.bashrc}}. Instead of using {{ic|ssh -p 1234 user@myssh.domain.com}} every time you connect, create an alias. For example, add <br />
alias myssh='ssh -p 1234 user@myssh.domain.com' <br />
to your {{ic|.bashrc}} and restart bash. Just type {{ic|myssh}} and you'll connect !<br />
<br />
===== Client configuration 2 (Recommended/Systematic approach) =====<br />
<br />
Create or use {{ic|~/.ssh/config}} to solve the issue. Add the following lines:<br />
Host myssh.domain.com<br />
Port 1234<br />
<br />
And ssh will automatically use port 1234 on connecting without you excplicitly having to define the port while connecting. <br />
<br />
==== Read from socket failed: connection reset by peer ====<br />
Recent versions of openssh sometimes fail with the above error message, due to a bug involving elliptic curve cryptography. In that case, edit the file<br />
<br />
~/.ssh/config<br />
<br />
or create it, if it does not already exist. Add the line<br />
<br />
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss<br />
<br />
With openssh 5.9, the above fix doesn't work. Instead, put the following lines in {{ic|~/.ssh/config}}:<br />
<br />
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc <br />
MACs hmac-md5,hmac-sha1,hmac-ripemd160<br />
<br />
See also the [http://www.gossamer-threads.com/lists/openssh/dev/51339 discussion] on the openssh bug forum.<br />
<br />
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===<br />
<br />
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries. Another reason can be that the user is no member of the ''network'' group.<br />
<br />
== See also ==<br />
*[[SSH Keys]]<br />
*[[Pam abl]]<br />
*[[fail2ban]]<br />
*[[sshguard]]<br />
*[[Sshfs]]<br />
*[[Syslog-ng]] : To send ssh log data to another file<br />
<br />
== Links & references ==<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]<br />
*[http://www.ibm.com/developerworks/library/l-keyc/index.html OpenSSH key management, Part 1] and [http://www.ibm.com/developerworks/library/l-keyc2 Part 2] on IBM developerWorks</div>Cteeto