Differences between revisions 19 and 99 (spanning 80 versions)
Revision 19 as of 2008-08-11 02:02:47
Size: 4993
Editor: WernerZarth
Comment:
Revision 99 as of 2021-10-21 14:37:18
Size: 17750
Comment: make translation header easy to include in translated pages
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from ssh
Line 2: Line 3:
~-Translation(s): [:fr/ssh:Français].-~

[[TableOfContents]]
##For Translators - to have a constantly up to date translation header in you page, you can just add a line like the following (with the comment's character at the start of the line removed)
## <<Include(SSH, ,from="^##TAG:TRANSLATION-HEADER-START",to="^##TAG:TRANSLATION-HEADER-END")>>
##TAG:TRANSLATION-HEADER-START
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[de/SSH|Deutsch]] - [[SSH|English]] - [[fr/SSH|Français]] - [[it/SSH|Italiano]] - [[es/SSH|Español]] - [[pt_BR/SSH|Português Brasileiro]]-~
##TAG:TRANSLATION-HEADER-END


<<TableOfContents>>
Line 9: Line 15:
ssh stands for '''s'''ecure '''sh'''ell and is a program for remote logins into other computers and for running single commands on other computers in a save way, see [http://en.wikipedia.org/wiki/Secure_Shell Wikipedia - Secure Shell] for more general information and [http://www.openssh.org/ OpenSSH] for the ssh homepage. (ssh replaces the unencrypted WikiPedia:telnet protocol, and add many features)

Throughout this document it will be assumed that the following two variables are defined

'''SSH''' stands for '''S'''ecure '''Sh'''ell and is a protocol for secure remote login and other secure network services over an insecure network<<FootNote(https://tools.ietf.org/html/rfc4252)>>.
See [[WikiPedia:Secure_Shell|Wikipedia - Secure Shell]] for more general information and DebPkg:ssh, DebPkg:lsh-client or DebPkg:dropbear for the SSH software implementations out of which [[https://www.openssh.com/|OpenSSH]] is the most popular and most widely used<<FootNote(https://www.openssh.com/users.html)>>.
SSH replaces the unencrypted [[WikiPedia:Telnet|telnet]],[[WikiPedia:Rlogin|rlogin]] and [[WikiPedia:Remote_shell|rsh]] and adds many features.

In this document we'll be using the OpenSSH command suite, it will also be assumed that the following two variables are defined:
Line 17: Line 26:
Line 19: Line 29:
== Installation ==

=== Installation of the client ===

Normally the client is installed by default. If not it suffices to run as root:

{{{
apt install openssh-client
}}}

=== Installation of the server ===

The server allows to connect remotely and gets installed by running as root:

{{{
apt install openssh-server
}}}

== Configuration files ==

The main configuration files are in the directory ''/etc/ssh'' :

 * '''ssh_config''' : client configuration file
 * '''sshd_config''' : server configuration file

Starting with Bullseye, configuration files will also be read from the following subfolders :

 * '''/etc/ssh/ssh_config.d/*.conf''' : client configuration file
 * '''/etc/ssh/sshd_config.d/*.conf''' : server configuration file

These have been enabled with the '''Include''' parameter in ssh_config and sshd_confg. Making changes locally using these directories can ease configuration management, and avoid issues with upgrades that make changes to package managed configuration files.

In addition the ''/etc/ssh'' directory contains the private/public key pairs
identifying your host :

 * ssh_host_dsa_key
 * ssh_host_dsa_key.pub
 * ssh_host_rsa_key
 * ssh_host_rsa_key.pub

Since OpenSSH 5.7<<FootNote(https://www.openssh.com/txt/release-5.7)>>, a new private/public key pair is available:

 * ssh_host_ecdsa_key
 * ssh_host_ecdsa_key.pub

Since OpenSSH 6.5<<FootNote(https://www.openssh.com/txt/release-6.5)>>, a new private/public key pair is available:

 * ssh_host_ed25519_key
 * ssh_host_ed25519_key.pub

=== Regenerating host keys ===

{{{
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
}}}
Line 20: Line 87:

=== With password ===
Line 25: Line 95:

and then type in your password.
Line 30: Line 103:
If this is the first time you login to the remote machine, ssh will ask you whether you are sure you want to connect to the remote computer. Answer 'yes' and then type in your password, and ssh will do a remote login for you.
If this is the first time you login to the remote computer, ssh will ask you whether you are sure you want to connect to the remote computer. Answer 'yes' after you verified the remote computer's fingerprint, type in your password, and ssh will connect you to the remote host.

=== Using shared keys ===

One of the functions of ssh is using a pair of private/public keys to connect to a remote host. Also known as '''''SSH keys'''''. This method allows you to login to a remote host without typing your password every time. To do this you must generate a pair of private/public keys on your local machine and deposit the public key on the remote host.

To generate the key, use the program ssh-keygen as follows

{{{
ssh-keygen -t rsa
}}}

This program generates a pair of private/public keys in the directory ~/.ssh. The program first asks for the destination files for the keys, by default located in ~/.ssh. Afterwards a passphrase is requested.

Note: We recommend not to leave the passphrase empty. An attacker who gets hold of your private key can otherwise connect to the hosts where you deposited you public key since the passphrase is empty. Choose a long and complex passphrase.

Your private key is id_rsa (don't give it to someone else), your public key is id_rsa.pub.

You copy your public key to a remote host with the command '''ssh-copy-id'''

{{{
ssh-copy-id -i ~/.ssh/id_rsa.pub $remote_user@$remote_host
}}}

Now you can connect simply to the remote host and the passphase is asked for. Once done, you get connected to the remote host. In case of a new connection the passphrase does not get asked for again during your entire session.

== Keys management ==

=== Using GUI ===

Optionally, DebPkg:seahorse is a GNOME application which easily manage encryption keys and passwords through an intuitive Graphical User Interface (GUI). Seahorse is able to do various operations. Such as create SSH or PGP keys, configure them, and cache them. [[Seahorse|Read more]].

== Securing ==

=== SSH Server ===

By default a SSH server is relatively secure. With the help of some good practices, configuration options, and external utilities it is possible to make it even harder for 'robots' and ''crackers''

==== Good practices with SSH Server ====

 * /!\ Apply DebPkg:openssh-server security updates as soon as possible. Which allows to protect against known security holes.
 * [[#Configuration_Options|Activate SSH keys authentication]] only with passwords/passphrases. Deactivate password only authentication.
 * Consider using DebPkg:fail2ban which is a log file monitor that automatically bans an IP address after a predefined number of failed login attempts. Which automatically guards against [[https://en.wikipedia.org/wiki/Brute-force_attack|brute-force attacks]].
 * More good practices for using ssh at https://lackof.org/taggart/hacking/ssh/

==== Configuration Options ====

(!) One should edit the file /etc/ssh/sshd_config to change the parameters and then restart the ssh server with

{{{
service ssh restart
}}}

 * Deactivate using passwords for authentication (''!PasswordAuthentication no'').
 * Deactivate using the root account (''!PermitRootLogin no'').
 * Only allow login by certain users or groups (''!AllowUsers'' and ''!AllowGroups'')

{i} The options ''!AllowUsers'' and ''!AllowGroups'' do not improve the security of a SSH server. But in certain cases their use allows to resist a ''brute force'' attack a little longer.

You can list your current sshd settings with the following command:

{{{
sshd -T | sort
}}}

==== External Utilities ====

 * DebianPkg:fail2ban : allows to automatically blacklist IPs attempting to ''brute force'' a SSH server with the help of DebianPkg:iptables.
 * DebianPkg:denyhosts : as DebianPkg:fail2ban, DebianPkg:denyhosts allows to block IP addresses trying to brute force a connection to ssh. But in contrast to DebPkg:fail2ban it does not use DebPkg:iptables, but the file ''/etc/hosts.deny''.

=== SSH Client ===

==== Good practices with SSH Client ====

 * /!\ Apply DebPkg:openssh-client security updates as soon as possible. Which allows to protect against known security holes.
 * Use [[#Using_shared_keys|SSH keys]] authentication. Rather than password authentication.
 * Add [[WikiPedia:Password_strength#Guidelines_for_strong_passwords|strong passwords]]/passphrases to your SSH keys. This reduce risk of [[WikiPedia:Brute-force_attack|brute-force attacks]].

== Additional Functions ==

=== View files in GUI ===

In file managers like Konqueror, Dolphin, Krusader and Midnight Commander you can use FISH to view files in a GUI using:

{{{
fish://username@server_name_or_ip
}}}

== Additional Commands ==

=== scp ===

''scp'' is a command line utility allowing to transfer files between two machines.

 * Sending a file:
{{{
scp $source_file $remote_user@$remote_host:$destination_file
}}}
 * Copying a file to the local machine:
{{{
scp $remote_user@$remote_host:$source_file $destination_file
}}}

=== sftp ===
[empty for now]

==== text mode ====
[empty for now]

==== graphical mode ====
[empty for now]

=== clusterssh ===
[empty for now]

=== ssh-agent and ssh-add ===

''ssh-agent'' is a useful utility to manage private keys and their passphrases. Most desktop environments in Debian will already be setup to run ssh-agent (through systemd user services or /etc/X11/Xsession), so you shouldn't need to start it manually.

{{{
# Check if ssh-agent is running
env | grep -i ssh
}}}

You will still need to tell the agent to manage your keys.

{{{
# List keys managed by the agent
ssh-add -l
# Add your ssh key
ssh-add ~/.ssh/your_private_key
}}}

When a private key is first needed, you are prompted for its passphrase. ssh-agent will then remember the key so that your passphrase doesn't get asked anymore.

=== keychain ===

[[https://www.funtoo.org/Keychain|Keychain]], provided by the package DebPkg:keychain, is a shell script allowing to use the ssh agent in multiple sessions of the same computer. In effect after the first start ssh-agent creates a permanent socket allowing the communication with ssh. This socket is referenced only in the environment of the session in which the agent was started. Keychain allows to detect the agent and propagate the access to this agent to other sessions; this allows to use a single instance of ssh-agent per user on a machine.

=== ssh-askpass ===

''DebPkg:ssh-askpass'' is an utility to simply the question for the password of a private key when using it. Several implementations exist:

   * '''x11-ssh-askpass''' : version for X11
   * '''kaskpass''' : integration of ssh-askpass into the KDE environment
   * '''ssh-askpass-gnome''' : integration of ssh-askpass into the Gnome environment

=== libpam-usb ===

''DebianPkg:libpam-usb'' is an utility (only available up to Debian Jessie) allowing authentication with an USB stick. This package includes a useful utilty : ''pamusb-agent''. This utility, once correctly configured, allows to load the SSH keys present on the USB stick once it is connected and to unload them when it is disconnected.

----
Line 33: Line 258:
If you just want to run one command on the remote computer, you don't need to login. You can tell ssh to run the command without login, For instance,
If you just want to run one command on the remote computer, you don't need to login. You can tell ssh to run the command without login, for instance,
Line 38: Line 264:
lists all files with extension .txt on the remote computer. This works with single tick quotes '...' as shown here, with double tick qoutes "...", and without quotes. There may be differences between these three cases, though, not yet documented here.

== ssh without password ==
If you work on a remote computer often, typing in the password each time you use ssh becomes annoying. You can configure ssh such that it does not ask you for a password anymore for that particular connection. You have to generate a private and public encryption key on your local machine and provide the public key to the remote machine.

To generate the keys run

{{{
ssh-keygen -t dsa
}}}
and reply to all questions just with return.

To provide the public key to the remote machine first create there an .ssh directory (if not present already) and then append the public key of your local machine to the authorized_keys file on the remote machine.

{{{
ssh $remote_user@$remote_host mkdir -p .ssh
cat .ssh/id_dsa.pub | ssh $remote_user@$remote_host 'cat >> .ssh/authorized_keys'
}}}
Note that here the cat command within the ssh command takes its input from the pipe.

From now on, you should be able to login with ssh without password.

 . '''REMARK:''' If the usernames on the local and the remote machine are identical, and if the local and the remote computer have access to the same home-directory of that user, e.g. because they are different clients in the same LAN with a common home directory mounted via nfs, then the private key, the public key, and the authorized_keys file all reside in the same directory. Thus you cannot only login without password from the local to the remote machine but also vice versa. In fact you can login from any computer in the LAN to any other computer. (The username@hostname entry at the end of the public key in the authorized_keys file has no relevance to ssh, you may delete it or change it if you like (I think)).
 '''REMARK:''' The example above assumes ssh protocol 2 and uses DSA encryption, which is currently recommended. One could also use RSA encryption for ssh protocol 2. ssh protocol 1 uses yet another encryption, but is obsolete.
 '''TROUBLESHOOTING (ssh still asks for a password):''' Login without password does not work if group or world has write permissions for the home directory on the remote machine. To fix that, run
 {{{
ssh $remote_user@$remote_host chmod g-w,o-w /home/$remote_user
}}}
 '''SOURCE:''' Mathias Kettner, ''SSH login without password'', http://www.linuxproblem.org/art_9.html, visited 2007-10-06.
lists all files with extension .txt on the remote computer. This works with single tick quotes '...' as shown here, with double tick quotes "...", and without quotes. There may be differences between these three cases, though, not yet documented here.
Line 68: Line 267:
 * [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] is a [:TerminalEmulator:terminal emulator] application which can act as a client for  ssh. It'is widely used by Windows users.
* [[https://www.chiark.greenend.org.uk/~sgtatham/putty/|PuTTY]] is a [[TerminalEmulator|terminal emulator]] application which can act as a client for ssh. It's widely used by Windows users.
Line 70: Line 270:
== SSH and security ==
=== SSH Server ===
 * Consider using DebPkg:fail2ban which is a log file monitor that automatically bans an ip address after a predefined number of failed login attempts. Guards against brute force attacks.
 * Use SSH keys rather than password.
=== SSH Client ===
 * http://lackof.org/taggart/hacking/ssh/ - Good practices for using ssh

== Good practices of SSH usage ==

You '''must''' read this: https://lackof.org/taggart/hacking/ssh/

This document sums up many good practices that regular SSH users should follow in order to avoid compromising the security of their accounts (and of the whole machine at the same time).

Configure your {{{~/.ssh/config}}} to send only the right key.

{{{
Host master.debian.org
    User account
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
}}}


== Troubleshooting ==

=== OpenSSL version mismatch. Built against 1000105f, you have 10001060 ===

If you get an error message like this when starting the `ssh` daemon, you need to run:

{{{
apt install openssh-server openssh-client
}}}

Also see [[DebianBug:732940|bug #732940]].

=== SSH hangs ===

'''Issue'''

You are trying to SSH into a remote computer. But during SSH log-in the session hangs/freezes indefinitely. Thus you are not presented with the command prompt. And you are not able to use any SSH commands :(
When using SSH debug mode the session hangs at this line '''''{{{debug2: channel 0: open confirm rwindow 0 rmax 32768}}}'''''

'''Possible cause'''

With some routers behind NAT and when using OpenSSH. During session setup, after the password has been given, OpenSSH sets the TOS (type of service) field in the IP datagram. The router choke on this. The effect is that your SSH session hangs indefinitely. In other words, SSH commands or connections are seldom working or not working at all.

==== Resolution with IPQoS 0x00 ====

Until your router manufacturer fix their firmware. Here is one option to resolve that issue:

 1. Double check your DebPkg:openssh-server and DebPkg:openssh-client version are 5.7 or more recent. For example the resolution below should work with Debian 7.11 Wheezy or more recent as it comes with OpenSSH version 6.0.
 1. Edit one of the following two files located at: {{{
~/.ssh/config
}}} or {{{
/etc/ssh/ssh_config
}}} Note: '''''{{{config}}}''''' file is per user and '''''{{{ssh_config}}}''''' file is for all users and system wide. If unsure edit the appropriate user '''''{{{config}}}''''' file.

 File content before {{{
Host *
}}}
 File content after {{{
Host *
  IPQoS 0x00
}}}
 1. If you have any Terminal/Console window(s) already open. Fully close all of them. Doing so will close any active SSH sessions.
 1. No need to restart OpenSSH or your Debian. Try again to SSH into any remote server. It should work. Done you have successfully fixed that issue :)
 
 Thanks to Joe and catmaker for this tip :)
 
 Related documentation at https://www.openssh.com/txt/release-5.7

==== Resolution with netcat ====

/!\ '''WARNING:''' It is suggested to consider using [[#Resolution_with_IPQoS_0x00|that other resolution with IPQoS 0x00]] instead of using netcat/'''''{{{ProxyCommand nc %h %p}}}''''' option. Because '''''{{{IPQoS 0x00}}}''''' is the official built-in OpenSSH option. Also '''''{{{IPQoS 0x00}}}''''' is a more direct way to resolve that issue, and potentially more secure option. Because '''''{{{IPQoS 0x00}}}''''' uses SSH's built in encryption for secure transfers. Compare to netcat's ''not'' encrypted transfers. Sources: [[https://nc110.sourceforge.io/|1]] [[https://www.ndchost.com/wiki/server-administration/netcat-over-ssh#using-dd-over-netcat|2]]. If you choose to use netcat/'''''{{{ProxyCommand nc %h %p}}}''''' option read on.

Another option to resolve that SSH hangs issue is to use '''''{{{ProxyCommand nc %h %p}}}'''''. To do so follow the same steps as [[#Resolution_with_IPQoS_0x00|that above resolution with IPQoS 0x00]]. But replace '''''{{{IPQoS 0x00}}}''''' with{{{
ProxyCommand nc %h %p
}}}

=== Keep SSH connection alive ===

For security reason, by default a SSH connection is automatically closed after a set period of time. But in some cases you want to keep that connection open. Such as cloud storage over SSH connection.

/!\ '''WARNING:''' Before activating that keep SSH connection alive option. It is suggested to consider [[#Securing|securing]] both your SSH Client and SSH Server. Because for example, there is a risk that if your users leave their SSH session open, and their computer unattended and unlocked. Anyone can approach that computer, then exploit that open SSH connection. For example by using the {{{passwd}}} command, and change the password. And thus gain access to the server. In other words, before activating that keep SSH connection alive option, it is suggested to use your best judgment and good security practices.

==== For Debian 7.x server ====

Steps to keep SSH connection alive.

On the SSH server edit {{{/etc/ssh/sshd_config}}} file and add the following at the bottom of that file.

{{{
# Keep client SSH connection alive by sending every 300 seconds a small keep-alive packet to the server in order to use ssh connection. 300 seconds equal 5 minutes.
ClientAliveInterval 300
 
# Disconnect client after 3333 "ClientAlive" requests. Format is (ClientAliveInterval x ClientAliveCountMax). In this example (300 seconds x 3333) = ~999,900 seconds = ~16,665 minutes = ~277 hours = ~11 days.
ClientAliveCountMax 3333
}}}

As {{{root}}} user restart the SSH service:

{{{
service sshd restart
}}}

Please note that on recent Debian systems (e.g. Wheezy 7 with current updates as of Nov. 2015), the above command no longer works and returns the error:

{{{
sudo service sshd restart
sshd: unrecognized service
}}}

However, the following works:

{{{
sudo service ssh restart
[ ok ] Restarting OpenBSD Secure Shell server: sshd.
}}}

== See also ==

 * DebianPkg:screen - terminal multiplexer with VT100/ANSI terminal emulation
 * DebianPkg:tmux - alternative terminal multiplexer

----
CategoryNetwork CategorySoftware

Translation(s): Deutsch - English - Français - Italiano - Español - Português Brasileiro

ToDo: merge (and translate) this page and the french one (more complete)

Introduction

SSH stands for Secure Shell and is a protocol for secure remote login and other secure network services over an insecure network1. See Wikipedia - Secure Shell for more general information and ssh, lsh-client or dropbear for the SSH software implementations out of which OpenSSH is the most popular and most widely used2. SSH replaces the unencrypted telnet,rlogin and rsh and adds many features.

In this document we'll be using the OpenSSH command suite, it will also be assumed that the following two variables are defined:

remote_host=<the remote computer>
remote_user=<your user name on $remote_host>

So, if you want to use the recipes below, first set these variables to the remote computer name and the user name on that remote computer. Then cut and paste of the commands below should work. remote_host may also be an IP-address.

Installation

Installation of the client

Normally the client is installed by default. If not it suffices to run as root:

apt install openssh-client

Installation of the server

The server allows to connect remotely and gets installed by running as root:

apt install openssh-server

Configuration files

The main configuration files are in the directory /etc/ssh :

  • ssh_config : client configuration file

  • sshd_config : server configuration file

Starting with Bullseye, configuration files will also be read from the following subfolders :

  • /etc/ssh/ssh_config.d/*.conf : client configuration file

  • /etc/ssh/sshd_config.d/*.conf : server configuration file

These have been enabled with the Include parameter in ssh_config and sshd_confg. Making changes locally using these directories can ease configuration management, and avoid issues with upgrades that make changes to package managed configuration files.

In addition the /etc/ssh directory contains the private/public key pairs identifying your host :

  • ssh_host_dsa_key
  • ssh_host_dsa_key.pub
  • ssh_host_rsa_key
  • ssh_host_rsa_key.pub

Since OpenSSH 5.73, a new private/public key pair is available:

  • ssh_host_ecdsa_key
  • ssh_host_ecdsa_key.pub

Since OpenSSH 6.54, a new private/public key pair is available:

  • ssh_host_ed25519_key
  • ssh_host_ed25519_key.pub

Regenerating host keys

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

Remote login

With password

If you want to login to $remote_host as user $remote_user simply type

ssh $remote_user@$remote_host

and then type in your password.

If the usernames on the local and the remote computer are identical, you can drop the $remote_user@-part and simply write

ssh $remote_host

If this is the first time you login to the remote computer, ssh will ask you whether you are sure you want to connect to the remote computer. Answer 'yes' after you verified the remote computer's fingerprint, type in your password, and ssh will connect you to the remote host.

Using shared keys

One of the functions of ssh is using a pair of private/public keys to connect to a remote host. Also known as SSH keys. This method allows you to login to a remote host without typing your password every time. To do this you must generate a pair of private/public keys on your local machine and deposit the public key on the remote host.

To generate the key, use the program ssh-keygen as follows

ssh-keygen -t rsa

This program generates a pair of private/public keys in the directory ~/.ssh. The program first asks for the destination files for the keys, by default located in ~/.ssh. Afterwards a passphrase is requested.

Note: We recommend not to leave the passphrase empty. An attacker who gets hold of your private key can otherwise connect to the hosts where you deposited you public key since the passphrase is empty. Choose a long and complex passphrase.

Your private key is id_rsa (don't give it to someone else), your public key is id_rsa.pub.

You copy your public key to a remote host with the command ssh-copy-id

ssh-copy-id -i ~/.ssh/id_rsa.pub $remote_user@$remote_host

Now you can connect simply to the remote host and the passphase is asked for. Once done, you get connected to the remote host. In case of a new connection the passphrase does not get asked for again during your entire session.

Keys management

Using GUI

Optionally, seahorse is a GNOME application which easily manage encryption keys and passwords through an intuitive Graphical User Interface (GUI). Seahorse is able to do various operations. Such as create SSH or PGP keys, configure them, and cache them. Read more.

Securing

SSH Server

By default a SSH server is relatively secure. With the help of some good practices, configuration options, and external utilities it is possible to make it even harder for 'robots' and crackers

Good practices with SSH Server

Configuration Options

(!) One should edit the file /etc/ssh/sshd_config to change the parameters and then restart the ssh server with

service ssh restart
  • Deactivate using passwords for authentication (PasswordAuthentication no).

  • Deactivate using the root account (PermitRootLogin no).

  • Only allow login by certain users or groups (AllowUsers and AllowGroups)

{i} The options AllowUsers and AllowGroups do not improve the security of a SSH server. But in certain cases their use allows to resist a brute force attack a little longer.

You can list your current sshd settings with the following command:

sshd -T | sort

External Utilities

  • fail2ban : allows to automatically blacklist IPs attempting to brute force a SSH server with the help of iptables.

  • denyhosts : as fail2ban, denyhosts allows to block IP addresses trying to brute force a connection to ssh. But in contrast to fail2ban it does not use iptables, but the file /etc/hosts.deny.

SSH Client

Good practices with SSH Client

Additional Functions

View files in GUI

In file managers like Konqueror, Dolphin, Krusader and Midnight Commander you can use FISH to view files in a GUI using:

fish://username@server_name_or_ip

Additional Commands

scp

scp is a command line utility allowing to transfer files between two machines.

  • Sending a file:

scp $source_file $remote_user@$remote_host:$destination_file
  • Copying a file to the local machine:

scp $remote_user@$remote_host:$source_file $destination_file

sftp

[empty for now]

text mode

[empty for now]

graphical mode

[empty for now]

clusterssh

[empty for now]

ssh-agent and ssh-add

ssh-agent is a useful utility to manage private keys and their passphrases. Most desktop environments in Debian will already be setup to run ssh-agent (through systemd user services or /etc/X11/Xsession), so you shouldn't need to start it manually.

# Check if ssh-agent is running
env | grep -i ssh

You will still need to tell the agent to manage your keys.

# List keys managed by the agent
ssh-add -l
# Add your ssh key
ssh-add ~/.ssh/your_private_key

When a private key is first needed, you are prompted for its passphrase. ssh-agent will then remember the key so that your passphrase doesn't get asked anymore.

keychain

Keychain, provided by the package keychain, is a shell script allowing to use the ssh agent in multiple sessions of the same computer. In effect after the first start ssh-agent creates a permanent socket allowing the communication with ssh. This socket is referenced only in the environment of the session in which the agent was started. Keychain allows to detect the agent and propagate the access to this agent to other sessions; this allows to use a single instance of ssh-agent per user on a machine.

ssh-askpass

ssh-askpass is an utility to simply the question for the password of a private key when using it. Several implementations exist:

  • x11-ssh-askpass : version for X11

  • kaskpass : integration of ssh-askpass into the KDE environment

  • ssh-askpass-gnome : integration of ssh-askpass into the Gnome environment

libpam-usb

libpam-usb is an utility (only available up to Debian Jessie) allowing authentication with an USB stick. This package includes a useful utilty : pamusb-agent. This utility, once correctly configured, allows to load the SSH keys present on the USB stick once it is connected and to unload them when it is disconnected.


Remote commands

If you just want to run one command on the remote computer, you don't need to login. You can tell ssh to run the command without login, for instance,

ssh $remote_user@$remote_host 'ls *.txt'

lists all files with extension .txt on the remote computer. This works with single tick quotes '...' as shown here, with double tick quotes "...", and without quotes. There may be differences between these three cases, though, not yet documented here.

SSH into Debian from another OS

Good practices of SSH usage

You must read this: https://lackof.org/taggart/hacking/ssh/

This document sums up many good practices that regular SSH users should follow in order to avoid compromising the security of their accounts (and of the whole machine at the same time).

Configure your ~/.ssh/config to send only the right key.

Host master.debian.org
    User account
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Troubleshooting

OpenSSL version mismatch. Built against 1000105f, you have 10001060

If you get an error message like this when starting the ssh daemon, you need to run:

apt install openssh-server openssh-client

Also see bug #732940.

SSH hangs

Issue

You are trying to SSH into a remote computer. But during SSH log-in the session hangs/freezes indefinitely. Thus you are not presented with the command prompt. And you are not able to use any SSH commands :( When using SSH debug mode the session hangs at this line debug2: channel 0: open confirm rwindow 0 rmax 32768

Possible cause

With some routers behind NAT and when using OpenSSH. During session setup, after the password has been given, OpenSSH sets the TOS (type of service) field in the IP datagram. The router choke on this. The effect is that your SSH session hangs indefinitely. In other words, SSH commands or connections are seldom working or not working at all.

Resolution with IPQoS 0x00

Until your router manufacturer fix their firmware. Here is one option to resolve that issue:

  1. Double check your openssh-server and openssh-client version are 5.7 or more recent. For example the resolution below should work with Debian 7.11 Wheezy or more recent as it comes with OpenSSH version 6.0.

  2. Edit one of the following two files located at:

    ~/.ssh/config

    or

    /etc/ssh/ssh_config

    Note: config file is per user and ssh_config file is for all users and system wide. If unsure edit the appropriate user config file.

    File content before

    Host *

    File content after

    Host *
      IPQoS 0x00
  3. If you have any Terminal/Console window(s) already open. Fully close all of them. Doing so will close any active SSH sessions.
  4. No need to restart OpenSSH or your Debian. Try again to SSH into any remote server. It should work. Done you have successfully fixed that issue :)

    Thanks to Joe and catmaker for this tip :)

    Related documentation at https://www.openssh.com/txt/release-5.7

Resolution with netcat

/!\ WARNING: It is suggested to consider using that other resolution with IPQoS 0x00 instead of using netcat/ProxyCommand nc %h %p option. Because IPQoS 0x00 is the official built-in OpenSSH option. Also IPQoS 0x00 is a more direct way to resolve that issue, and potentially more secure option. Because IPQoS 0x00 uses SSH's built in encryption for secure transfers. Compare to netcat's not encrypted transfers. Sources: 1 2. If you choose to use netcat/ProxyCommand nc %h %p option read on.

Another option to resolve that SSH hangs issue is to use ProxyCommand nc %h %p. To do so follow the same steps as that above resolution with IPQoS 0x00. But replace IPQoS 0x00 with

ProxyCommand nc %h %p

Keep SSH connection alive

For security reason, by default a SSH connection is automatically closed after a set period of time. But in some cases you want to keep that connection open. Such as cloud storage over SSH connection.

/!\ WARNING: Before activating that keep SSH connection alive option. It is suggested to consider securing both your SSH Client and SSH Server. Because for example, there is a risk that if your users leave their SSH session open, and their computer unattended and unlocked. Anyone can approach that computer, then exploit that open SSH connection. For example by using the passwd command, and change the password. And thus gain access to the server. In other words, before activating that keep SSH connection alive option, it is suggested to use your best judgment and good security practices.

For Debian 7.x server

Steps to keep SSH connection alive.

On the SSH server edit /etc/ssh/sshd_config file and add the following at the bottom of that file.

# Keep client SSH connection alive by sending every 300 seconds a small keep-alive packet to the server in order to use ssh connection. 300 seconds equal 5 minutes.
ClientAliveInterval 300
 
# Disconnect client after 3333 "ClientAlive" requests. Format is (ClientAliveInterval x ClientAliveCountMax). In this example  (300 seconds x 3333) = ~999,900 seconds = ~16,665 minutes = ~277 hours = ~11 days.
ClientAliveCountMax 3333

As root user restart the SSH service:

service sshd restart

Please note that on recent Debian systems (e.g. Wheezy 7 with current updates as of Nov. 2015), the above command no longer works and returns the error:

sudo service sshd restart
sshd: unrecognized service

However, the following works:

sudo service ssh restart
[ ok ] Restarting OpenBSD Secure Shell server: sshd.

See also

  • screen - terminal multiplexer with VT100/ANSI terminal emulation

  • tmux - alternative terminal multiplexer


CategoryNetwork CategorySoftware