|Source Repository:||No results|
Summary: Port of OpenBSD's free SSH release
- Disable EC/RC5 algorithms in OpenSSL for patent reasons.
- Enable high performance ssh
- Add support for storing SSH public keys in LDAP
- Use LDNS for DNSSEC/SSHFP validation.
- Enable root password logins for live-cd environment.
- Support the legacy/weak SSH1 protocol
- Enable additional crypto algorithms via OpenSSL
- Adds support for X.509 certificate authentication
Latest InnovationsThis news item documents the latest innovations now available under Funtoo Linux.
Kits Are Go (And Ego Needs a Manual Bump)An update on kits and how to manually update to ego-1.1.3-r3 (required steps for some)
SSH is a cryptographically confidential network protocol for data transmission between 2 networked computers. There are 2 protocol versions; SSH-1 and SSH-2.
Funtoo uses the OpenSSH daemon (sshd) to provide the SSH service by default. sshd is a member of OpenRC's default runlevel.
By default login is allowed for all non-root users via the ssh daemon on port 22 with any valid username and password combination.
There are 2 means of configuring
sshd. The first is required, the second is optional.
sshdreads its configuration data from
sshdmay be configured to use PAM.
Permission may be granted or denied via PAM, allowing you to store usernames etc. using text files.
Protocol version selection
The default protocol version is SSH-2. SSH-1 requires explicit activation. To select a protocol version, use the
Ciphers directive specifies the ciphers allowed for protocol version 2.
Single authentication method
- Password authentication
This is enabled by default, it is configured using the
PasswordAuthenticationdirective. Valid parameters are
PasswordAuthentication yesis configured, the state of the
PermitEmptyPasswordsdirective is evaluated.
- Public key authentication
This is enabled with combinations of
On your client, run
# ssh-keygen -t rsa
This command will generate a public and private key, stored at
~/.ssh/id_rsa respectively. The private key should not be shared with anyone. The pubilc key can be freely shared, and can only be used to grant you access to remote systems by use of your private key. To grant yourself access to a remote account, append the contents of
~/.ssh/id_rsa.pub to the file
~/.ssh/authorized_keys on a remote system. Note that
~/.ssh/authorized_keys must not be readable by anyone but the user for OpenSSH to process the file -- do this by running
chmod -R go-rwx ~/.ssh on the remote system.
Providing a passphrase for your private key will cause it to be stored in an encrypted format, using this passphrase. Before you can use your private key, you will be prompted by OpenSSH to type in this passphrase. This is similar to typing in a password, but with the use of this authentication method, your password is not sent over the network at all.
ssh-agent exists to allow decrypted private keys to be cached in memory for easy access, so you do not need to type in your passphrase every time. It can still be quite complex to use, so it's recommended to use a front-end for
ssh-agent -- see the Keychain page to learn about such a tool. Keychain is also part of Funtoo.
Create a user, or select which user the client will be accessing the server as, then place clients id_rsa.pub file into the users
Single Machine Testing
# ssh-keygen -t rsa
Press enter several times to accept default settings.
# cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
# ssh localhost
- Host-based authentication
Requiring multiple authentication factors
These options are only available for SSH-2. The default is not to require multiple authentication. To identify to the daemon that you wish to require more than one authentication, you must use the
AuthenticationMethods directive. This directive is followed by one or more comma separated lists of authentication method names. Lists are separated with a space. Successful authentication requires completion of every method in at least one of these lists.
AuthenticationMethods "password,publickey password,keyboard-interactive"
Password authentication using
The following 4 directives are listed in order of evaluation by OpenSSH. They are configured directly; within
sshd_config. Only user or group _names_ are valid, numerical IDs are not recognized. If the pattern takes the form
USER@HOST then access is restricted to the
USER when originating from the
DenyUsers PATTERN PATTERN ...
- Login is forbidden for users whose username matches one of the patterns
AllowUsers PATTERN PATTERN ...
- Login is permitted to users whose username matches one of the patterns
DenyGroups PATTERN PATTERN ...
- Login is forbidden for users whose primary group or supplementary group list matches one of the patterns
AllowGroups PATTERN PATTERN ...
- Login is permitted to users whose primary group or supplementary group list matches one of the patterns
Public key authentication
Host based authentication
Controlling root access
Access by the root user can be controlled using the
Permit empty passwords
Access to accounts with empty (i.e. blank) passwords can be controlled using the
GSSAPIAuthenticaion GSSAPICleanupCredentials GSSAPIStrictAcceptorCheck HostBasedAuthentication HostBasedUsesNameFromPacketOnly HostCertificate HostKey HostKeyAgent LoginGraceTime MAC MaxAuthTries MaxSessions MaxStartups PasswordAuthentication PermitEmptyPasswords PubkeyAuthentication RevokedKeys RhostsRSAAuthentication RSAAuthentication TrustedUserCAKeys UseLogin UsePAM
By default X11 forwarding is disabled in OpenSSHd,
If you would like to forward X11 from your Funtoo box to a remote system you must first edit your /etc/ssh/sshd_config file
#X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes
X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes
X forwarding will now be enabled from that machine, so if you connect from your remote with 'ssh -X <user>@<ipaddress>' X sessions will be forwarded
HPN-SSH is a patch set designed to remove a networking bottleneck in the base OpenSSH code. Removing this bottleneck can improve performance drastically.
SSH implements a multiplexed connection protocol so a single TCP/IP connection can host multiple SSH sessions at the same time. This means that SSH also has to implement a flow control mechanism in order to make sure that the network connection isn't overwhelmed. Much like TCP/IP it uses a recieve buffer to indicate how much data the sender should be sending at any one point. The developers of OpenSSH have set this buffer size to 64KiloBytes. This is often too small for very high speed connections over long distances. HPN-SSH allows this buffer to grow well past 64KB allowing transfers at very high rates.
As a general rule of thumb, the farther away the destination and the faster your connection the greater the improvement will be. You can determine how much HPN-SSH will help by multiplying the bandwidth to the destination by the RTT (Round Trip Time). This is called the BDP (Bandwidth Delay Product) and is expressed as BDP = BW(B/s) * RTT(s) and gives you the number of bytes that can be in transit between any two hosts at one time. If this value is less than the previous mention receive buffer on the receiving host then the potential throughput of the connection will be near line rates*. If the BDP is greater than the receive buffer the throughput will be limited in direct proprotion to the difference between the BDP and the receive buffer. As a rule of thumb you will generally need at least a 10Mb/s connection to the internet to see a benefit from HPN-SSH.
Add these settings into /etc/ssh/sshd_config:
HPNDisabled no TcpRcvBufPoll yes HPNBufferSize 8192 NoneEnabled yes # Enable none cipher
The NONE Cipher
The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted. Additionally, while the data is no longer encrypted each packet is still digitially signed and protected against in transit manipulation of the information. Anytime the NONE cipher is used a warning will be printed to screen saying "WARNING: NONE CIPHER ENABLED". If you do not see that warning then the None cipher is not in use.
Is it safe to switch off encryption? That depends entirelly on what you are trying to do. First off, you can't use the NONE Cipher Switch in an interactive session and is designed to be only used in the transfer of bulk data - like with scp. Second, you should be aware of what kind of data you are transfering. If you are copying financial or medical data then you would not want to use the NONE cipher. However, if you are copying non-sensitive data like MP3s, archives, images, and so forth it may make sense to use the NONE Cipher Switch. You will have to make that determination yourself. Lastly, since the authentication process is still encrypted hackers and eavesdroppers will not be able to steal your password.
You must use both -oNoneSwitch=yes and -oNoneEnabled=yes on the client command line. Additionally, the None cipher must be enabled on the server with NoneEnabled=yes in the sshd_config file or on the command line. Anytime the None cipher is used a warning will be printed to screen saying "WARNING: NONE CIPHER ENABLED". If you do not see that warning then the NONE cipher is not in use.
The multi-threaded AES-CTR
As of HPN13v1 there has been introduced a multi-threaded AES-CTR (MT-AES-CTR) patch that will allow SSH to make use of multiple cores. This can significantly improve throughput performance. In test environments one can commonly see near GigE line rate speeds - more than a 100% improvement over the default AES-CTR mode cipher.
To enable the multi-threaded variant use either -oCipher=aes[128|192|256]-ctr or -caes[128|192|256]-ctr. The cipher stream is indistinguishable from the single threaded version and will be understood also by all compliant (single-threaded) implementations of AES-CTR.
ssh is a commonly attacked service. Package:Sshguard monitors logs, and black list remote users who have repeatedly failed to login.