May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

SSH Tips

News SSH Recommended Links passwordless  login SSH troubleshooting FAQs
bash Tips and Tricks Unix Sysadmin Tips SSH autologin SSH Usage in Pipes Port Forwarding Reverse SSH Tunnels
ssh-keygen scp SCP Tips VNC over SSH X11 forwaring over ssh sftp
Free SSH Windows clients SSH SOCKS4 proxy SSH History Sysadmin Horror Stories Humor Etc

There are tremendous amount of tricks about ssh. Here three of my favorites:

Piping vis ssh

Because SSH command syntax descends from the rsh syntax, several neat tricks are possible.

My favorite is piping data through SSH to a program on the remote side. You can run

cat /my/file/to/print.txt | ssh jon@my.remote.printhost lpr -Pwhich_printer,

which pipes the file to the program lpr on the remote side of things. Essentially, anything after the destination host on the SSH command is passed as a command to the remote server.

If disk space is tight, you can also use that trick to tar files to a storage place on a different system: tar cvf - source_directory | ssh user@remote_host 'cat > my-tar-file.tar'.

The quotes are necessary to ensure that the remote system, not the local system, redirects output.

One trap associated with executing commands via SSH is that interactive programs tend to die reluctantly. That is generally because they expect a terminal to be available, and SSH does not allocate a terminal for commands that it does not believe to be interactive. For example, I keep nethack on one system and I execute it via a script that calls ssh jon@remote-system nethack. For a long time I did not understand why nethack failed to run properly, but then I discovered SSH's -t option, which forces allocation of a pseudo-TTY. Using ssh -t jon@remote-system nethack does the trick just fine.

The SSH client drop back to the rsh program if the remote system does not have SSH installed. Your SSH client should print out an error message under those circumstances, and you would be ill-advised to ignore it. You can disable that behavior with a line reading FallBackToRsh No in your ssh_config configuration file or equvalent in Putty or Teraterm.

I've recently freed myself from the annoyance of typing passwords frequently. As a system administrator, I find that using SSH to run commands on remote systems helps me manage them efficiently, both in executing the same command on multiple systems (such as package upgrades) and in collecting remote data (such as running uptime and sending the output to a file). As a user, I find that, once ssh-agent is configured properly, my workday proceeds more smoothly.

Scp pseudo filesystem

Total Commander, Nautilus, MC and several other file managers allow you to create pseudo-filesystem based on scp. Extremely convenient for file operations on the remote server. With the Nautilus file manager, launch the file manager, click the File menu and select Connect to Server.

Slow response of ssh

Sometimes ssh start ridiculously slow with the response delayed for 20 sec or so. This is typically due to broken DNS lookup, for example

usrklxbck01:~/bin # nslookup

** server can't find NXDOMAIN

Top Visited
Past week
Past month


Old News ;-)

[Oct 17, 2017] 5 SSH alias examples in Linux - The Linux Juggernaut

Oct 17, 2017 |


As a Linux user, we use ssh command to log in to remote machines. The more you use ssh command, the more time you are wasting in typing some significant commands. We can use either alias defined in your .bashrc file or functions to minimize the time you spend on CLI. But this is not a better solution. The better solution is to use SSH-alias in ssh config file.

A couple of examples where we can better the ssh commands we use.

Connecting to ssh to AWS instance is a pain. Just to type below command, every time is complete waste your time as well.

ssh -p 3000 -i /home/surendra/mysshkey.pem


ssh aws1

Connecting to a system when debugging.

ssh -vvv


ssh xyz

In this post, we will see how to achieve shorting of your ssh commands without using bash alias or functions. The main advantage of ssh alias is that all your ssh command shortcuts are stored in a single file and easy to maintain. The other advantage is we can use same alias for both SSH and SCP commands alike

Before we jump into actual configurations, we should know difference between /etc/ssh/ssh_config, /etc/ssh/sshd_config, and ~/.ssh/config files. Below is the explanation for these files.

System-level SSH configurations are stored in /etc/ssh/ssh_config. Whereas user-level ssh configurations are stored in ~/.ssh/config file.

System-level SSH configurations are stored in /etc/ssh/ssh_config. Whereas system level SSH server configurations are stored in /etc/ssh/sshd_config file.

... ... ...

Example1: Create SSH alias for a host(

Edit file ~/.ssh/config with following content

Host tlj
  User root
  port 22

... ... ...

Examaple5: Resolve SSH timeout issues in Linux. By default, your ssh logins are timed out if you don't activily use the terminial.

SSH timeouts are one more pain where you have to re-login to a remote machine after a certain time. We can set SSH time out right in side your ~/.ssh/config file to make your session active for whatever time you want. To achieve this we will use two SSH options for keeping the session alive. One ServerAliveInterval keeps your session live for number of seconds and ServerAliveCountMax will initial session after session for a given number.

ServerAliveInterval A
ServerAliveCountMax B


Host tlj linuxnix
  User root
  port 22
  ServerAliveInterval 60
  ServerAliveCountMax 30

We will see some other exiting howto in our next post. Keep visiting

[Aug 14, 2017] How-To: Thwart brute force SSH attacks in CentOS/RHEL 5

Aug 14, 2017 |

5 Replies

UPDATE: This was a good exercise but I decided to replace the script with denyhosts: . In CentOS, just install the EPEL repo first, then you can install it via yum.

This is one of the problems that my team encountered when we opened up a firewall for SSH connections. Brute force SSH attacks using botnets are just everywhere! And if you're not careful, it's quite a headache if one of your servers was compromised.

Lot of tips can be found in the Internet and this is the approach that I came up with based on numerous sites that I've read.

  1. strong passwords
    DUH! This is obvious but most people ignore it. Don't be lazy.
  2. disable root access through SSH
    Most of the time, direct root access is not needed. Disabling it is highly recommended.
    • open /etc/ssh/sshd_config
    • enable and set this SSH config to no: PermitRootLogin no
    • restart SSH: service sshd restart
  3. limit users who can log-in through SSH
    Users who can use the SSH service can be specified. Botnets often use user names that were added by an application, so listing the users can lessen the vulnerability.
    • open /etc/ssh/sshd_config
    • enable and list the users with this SSH config: AllowUsers user1 user2 user3
    • restart SSH: service sshd restart
  4. use a script to automatically block malicious IPs
    Utilizing SSH daemon's log file (in CentOS/RHEL, it's in /var/log/secure ), a simple script can be written that can automatically block malicious IPs using tcp_wrapper's host.deny
    If AllowUsers is enabled, the SSH daemon will log invalid attempts in this format:
    sshd[8207]: User apache from not allowed because not listed in AllowUsers
    sshd[15398]: User ftp from not allowed because not listed in AllowUsers

    SSH also logs invalid attempts in this format: sshd[6419]: Failed password for invalid user zabbix from port 50962 ssh2 Based on the information above, I came up with this script:

    # always exclude these IPs
    if [[ -e $tmp_list ]]
        rm $tmp_list
    # set the separator to new lines only
    # REGEX filter
    filter="^$(date +%b\\s*%e).+(not listed in AllowUsers|\
    Failed password.+invalid user)"
    for ip in $( pcregrep  $filter $file_log \
      | perl -ne 'if (m/from\s+([^\s]+)\s+(not|port)/) { print $1,"\n"; }' )
        if [[ $ip ]]
            echo "ALL: $ip" >> $tmp_list
    # reset
    unset IFS
    cat $file_host_deny >> $tmp_list
    sort -u $tmp_list  | pcregrep -v $exclude_ips > $file_host_deny

    I deployed the script in root's crontab and set it to run every minute 🙂

There, of course YMMV. Always test deployments and I'm pretty sure there are a lot of other tools available 🙂 This entry was posted in bash , centos/rhel , how to , linux , security , ssh and tagged security , ssh on July 8, 2010 by tar .

[Aug 04, 2017] SSH Troubleshooting - Metawerx Java Wiki

Jun 97, 2007 |
SSH Troubleshooting

This page shows common problems experienced with SSH in general, and when establishing an SSH tunnel , and solutions for each problem.

Tip: Most port-forwarding problems are caused by a basic misunderstanding of how an SSH tunnel actually works, so it is highly recommended that you read the SSH Tunnel page before continuing.

Table of Contents

Connection Problems Unable to open connection: Host does not exist Connection fails with the following error:
Unable to open connection:
Host does not exist
This error occurs when:
ping servername
Unable to open connection: gethostbyname: unknown error Connection fails with the
    following error:
Unable to open connection:
gethostbyname: unknown error
This error occurs when:

Connection refused Connection fails with the following error:

Failed to connect to Network error: Connection refused
Network error: Connection refused
FATAL ERROR: Network error: Connection refused

This error occurs when:

Failed to add the host to the list of known hosts (/home/USERNAME/.ssh/known_hosts) Connection works, but the following warning is issued
Failed to add the host to the list of known hosts (/home/USERNAME/.ssh/known_hosts)

This error occurs when:

To fix, execute these commands (as root) to reset the permissions to their correct values (replace USERNAME with the appropriate username)

cd ~
chown USERNAME /home/username
chown USERNAME -R /home/username/.ssh
chmod 700 /home/USERNAME/.ssh
chmod 600 /home/USERNAME/.ssh/*
Authentication Problems When using a key, you are prompted for a password (instead of automatically authenticating)

This can be caused be:

Unable to use key file "keys\KEYNAME.ppk" (unable to open file)

This is caused by an inability to open the specified SSH key file.

Tunnel Problems / Port Forwarding Problems

Note that some of these errors will only appear if verbose-output (-v) is switched on for the PLINK command or SSH commands. PuTTY hides them, but PLINK can be used with exactly the same command line arguments, so test with PLINK and the -v command line option.

Forwarded connection refused by server: Administratively prohibited [open failed], or channel N: open failed: administratively prohibited: open failed

This error appears in the PLINK/PuTTY/ssh window when:

For example, you have tried to connect to using an SSH command line argument such as:

However, does not exist, is not permitted, or cannot be resolved correctly by the remote server. Unfortunately, the error message is quite vague, and always makes it look like a security issue. Verify the server name is correct and try again, then check with your administrator.

When this is the problem the following will appear in the SSH server logs (eg: /var/log/auth.log in Linux):

Nov 28 17:00:57 server sshd[27850]: error: connect_to unknown host (Name or service not known)


Aug 26 17:48:10 server sshd[24180]: Received request to connect to host port NNNN, but the request was denied.

Forwarded connection refused by server: Connect failed [Connection refused]

This error appears in the PLINK/PuTTY/ssh window, when you try to establish a connection to the tunnel, and the server cannot connect to the remote port specified.

For example, you have specified that the tunnel goes to using an SSH command line argument such as:

When you then try to telnet to on the client machine, this is tunnelled through to the server, which then attempts to connect to However, that that connection between the server and is refused.

Check the tunnel server:port is correct, or ensure that the server is able to connect to the specified server:port.

Service lookup failed for destination port ""

This error appears in the PLINK/PuTTY/ssh window, if your tunnel definition is incomplete or incorrect.

For example, the additional space after "3500:" in the following line will cause this error:

line which causes error:
correct line:
Local port forwarding to nnn.nnn.nnn.nnn:nnnnn failed: Network error: Permission denied

This error appears in the PLINK/PuTTY/ssh window, if your PuTTY client cannot listen on the local port you have specified.

This normally occurs because of another service already running on that port.

For example, the tunnel below will fail if you have a local version of SQL/Server already listening on port 1433:


To fix, close the program that is listening on that port (ie: SQL/Server in the example above).

Advanced: You can also adjust to tunnel from another port, such as or However, with SQL/Server, the Management Console application will only allow connections to 1433. Additionally, it listens on, preventing use of port 1433 on any other IP address. Therefore, unless you first adjust the SQL/Server registry settings to listen on a specific IP first, it is not possible to have SQL/Server running at the same time as a local tunnel.

<some program>: not found

If you have connected successfully, but get errors when you try to enter commands at the tunnel prompt, this is because you have access to the tunnel itself, but not to an SSH prompt or any tools on the server. You should not be running these commands at the SSH prompt itself.

Example errors:

If you were trying to establish an SSH tunnel, you have already accomplished this part. Your tunnel should be listening on<some port>. The commands you are trying to execute should be performed in a new Command Prompt or Shell.

Remember - the tunnel is providing access to a remote service, on your local machine, as if the server is your own computer.

You can therefore use any command line or GUI tools at your disposal, and connect directly to<whatever port>.

If you are confused about how this works, see the SSH Tunnel page for diagrams and a full explanation.

See Also
Problem not found / not solved? Something to add?

[Aug 04, 2017] John E. McCarthy

Dec 20, 2016 |
Contributors: Christopher Hollowell, John DeStefano There are a number of problems that can cause failures when connecting to the RACF. Here are some things to look at and try in order to resolve your problem.
  1. Private and Public Key Issues
  2. Username Issues
  3. Ownership/Access Rights Issues
  4. PuTTY Issues
  5. Viewing Your Public Key
  6. Frozen Sessions and Terminals
  7. Host Key Issues
  8. Error: Agent admitted failure to sign using the key
  9. Further Troubleshooting
Private and Public Key Issues Username Issues

If your username on your local system is different from your username at the RACF, then you must specify your RACF username when you connect to the RACF, using the -l option to the ssh commmand:

ssh -l [username] [RACF-hostname]

or prepending username@ to the SSH gateway system name (no space between the @ and the SSH gateway system name):

ssh [username]@[RACF-hostname]

In Windows SSH clients, there is typically a text box in which you type in your username.

Ownership/Access Rights Issues

If you are using a Linux/UNIX based SSH client, please check the ownership and access rights of your ~/.ssh/ directory and
the private key file in that directory. Both must be owned by your local user account (not necessarily the same as your
RACF user account). The rights on your ~/.ssh/ directory should be 700 , and the rights on the private key file (possibly,
but not definitely, named ~/.ssh/id_rsa ), should be 600 . The important thing here is that "group" and "other" access rights
must be 00 .

PuTTY Issues

If you are using PuTTY in Windows , then you have to either import your private key , or somehow tell PuTTY where the key file is.

In the main PuTTY Configuration, click on SSH and then Auth . The window will have a text box where you can put the path
of the key or browse for it. See Windows SSH Key Generation for more information on generating SSH keys for use with PuTTY.

You may also need to forward your private key through a remote gateway machine to another server. See SSH Agent for more information on storing and forwarding your private key.

Viewing Your Public Key

You can view the contents of the public key you uploaded to the RACF by directing your Web client to:
and clicking on SSH Public Key File Viewing Utility . You can check this against the public key that may be on your local
system (the public key is not required to be on your local system; the private key is required to be there). If they
are not the same, then the private key on your local system may not paired with the public key you uploaded to the RACF.

If you have both private and public keys on your local system, check the date/time stamps on them, as they should be the same. If they are not the same, then the private key on your local system may not be paired with the public key that you uploaded to the RACF. If you are using the openssh client, then you can also check to see if your local private key is paired to the public key that you uploaded to the RACF. Run the command:

ssh-keygen -y

on your local system. It will ask for the filename of your private key and its passphrase and will display the public
key (without the trailing comment field) that is paired with it. Check this against the results of viewing the public key
you uploaded to the RACF as described above.

Frozen Sessions and Terminals

If your connection or session intermittently freezes, try adding a server keep-alive option to your usual SSH command:

ssh ... -o ServerAliveInterval=120

This ensures that a set of request and acknowledgment packets will be sent between the connection every two minutes, even when no other data has been requested. You can also add this option to your SSH configuration file ( ~/.ssh/config ) instead of specifying it with each SSH command:

 ServerAliveInterval 120
Host Key Issues

Sometimes host key problems can close the ssh connection before login completes. If you see an error like this:

ssh_exchange_identification: Connection closed by remote host

Then you might try removing the offending host key from your ~/.ssh/known_hosts file and try again.

Error: Agent admitted failure to sign using the key

This error might occur if you accidentally load the wrong SSH identity for a specific key, if you've uploaded a new public key that hasn't yet been synced with your account (or uploaded multiple or invalid keys), or if you're trying to load too many SSH identities at one time. Your best recourse is usually to:

  1. Log out of all current sessions
  2. Log back in
  3. Add your identity with the ssh-add command.
Further Troubleshooting

Some additional SSH-related sites and resources:

If all else fails, try running this command, substituting your account user name for [username] :

... ... ...

[Aug 04, 2017] Troubleshooting SSH Connections

Aug 04, 2017 |

I've helped a few people recently who have had trouble getting OpenSSH working properly; I've also had my share of issues over the years. Generally problems with SSH connections fall into two groups - network related and server related. Most of these problems can be fixed fairly quickly if you know what to look for.

Network Related Problems

These will typically be caused by improper routing or firewall configurations. Here are some things to check.

1. If your SSH server sits behind a firewall or router, make sure the default route of your internal SSH server points back to that firewall or router. Seems obvious, but it's common to forget about the return trip packets need to make. This will display your default gateway:

netstat -rn | grep UG

Sometimes the default gateway is just one of your server interfaces, this is OK as long as that interface is directly connected to something that knows how to get back to your client.

2. While you're at it, make sure the incoming SSH packets are actually getting to your SSH server. Tcpdump works very nicely for this, you'll need to be root to run it on the server:

tcpdump -n -i eth0 tcp port 22 and host [IP address of client]

Just replace eth0 by your client-facing interface name. If you don't see incoming SSH packets during connection attempts, it's probably due to a firewall or router access list.

SSH Server Problems

All of these issues revolve around SSH server configuration settings - not misconfigurations necessarily, just settings you may not be aware of.

1. Permissions can be a problem - in its default configuration, OpenSSH sets StrictModes to yes and won't allow any connections if the account you're trying to SSH into has group- or world-writable permissions on its home directory, ~/.ssh directory, or ~/.ssh/authorized_keys file. I typically just make the two directories mode 700 and the authorized_keys file mode 600. The sshd man page suggests this one-liner:

chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys

2. On Debian or Ubuntu systems, it is possible the keys you are using to connect are blacklisted. This is only an issue on Debian or Debian-based clients, and stems from this now-famous vulnerability in May of 2008 . To detect any such blacklisted keys, run ssh-vulnkey on the client, while logged into the account you are connecting from. Debian and Ubuntu SSH servers will reject any such keys unless the PermitBlacklistedKeys directive in the /etc/ssh/sshd_config file is set to no . I don't recommend you actually leave this security check disabled, but it can be useful to temporarily disable it during testing.

3. Finally, if all else fails, you can see exactly what the SSH server is doing by running it in debug mode on a non-standard port:

/usr/sbin/sshd -d -p 2222

Then, on the client, connect and watch the server output:

ssh -vv -p 2222 [Server IP]

Note the -vv option to provide verbose client output. This alone can sometimes help debug connection issues (and try -vvv for even more output).

[Aug 03, 2017] centos - SELinux preventing ssh via public key

Notable quotes:
"... When I have SELinux enabled I am unable to ssh into the server using the public key. If I setenabled 0 , $USER can now log in. ..."
Jun 13, 2014 |


I have user $USER which is a system user account with an authorized users file. When I have SELinux enabled I am unable to ssh into the server using the public key. If I setenabled 0 , $USER can now log in.

What SELinux bool/policy should I change to correct this behaviour without disabling SELinux entirely?

It's worth noting that $USER can login with a password under this default SELinux configuration, I'd appreciate some insight as to what is happening here, and why SELinux isn't blocking that. (I will be disabling


Assuming the filesystem permissions are correct on ~/.ssh/*, then check the output of
sealert -a /var/log/audit/audit.log

There should be a clue in an AVC entry there. Most likely the solution will boil down to running:
restorecon -R -v ~/.ssh

[Aug 03, 2017] SSH Permission denied on Correct Password Authentication - Super User

Aug 03, 2017 |
could successfully SSH into my machine yesterday with the exact same credentials I am using today. The machine is running Centos 6.3 . But now for some reason it is giving me permission denied. Here is my -v print out, sshd_config, and ssh_config files.
$ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to devilsmilk [] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type -1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_dsa type -1
debug1: identity file /home/kgraves/.ssh/id_dsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA de:1c:37:d7:84:0b:f8:f9:5e:da:11:49:57:4f:b8:f1
debug1: Host 'devilsmilk' is known and matches the ECDSA host key.
debug1: Found key in /home/kgraves/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kgraves/.ssh/id_rsa
debug1: Trying private key: /home/kgraves/.ssh/id_dsa
debug1: Trying private key: /home/kgraves/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
debug1: Next authentication method: password
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
Permission denied, please try again.
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
Permission denied, please try again.
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).

Here is my sshd_config file on devilsmilk:

#   $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22
#AddressFamily any
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
# HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes 
StrictModes no
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication yes
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

# Accept locale-related environment variables

#AllowAgentForwarding yes
AllowTcpForwarding yes
GatewayPorts yes
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   ForceCommand cvs server

And here is my ssh_config file:

#   $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#Host * 
# GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
    ForwardX11Trusted yes
# Send locale-related environment variables

UPDATE REQUEST 1: /var/log/secure

Jan 29 12:26:26 localhost sshd[2317]: Server listening on port 22.
Jan 29 12:26:26 localhost sshd[2317]: Server listening on :: port 22.
Jan 29 12:26:34 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:36:09 localhost pam: gdm-password[3029]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 12:36:09 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:36:11 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:53:39 localhost polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session2 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.freedesktop.packagekit.system-update for system-bus-name::1.64 [gpk-update-viewer] (owned by unix-user:misfitred)
Jan 29 12:54:02 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 12:54:06 localhost sshd[2317]: Received signal 15; terminating.
Jan 29 12:54:06 localhost sshd[3948]: Server listening on port 22.
Jan 29 12:54:06 localhost sshd[3948]: Server listening on :: port 22.
Jan 29 12:55:46 localhost su: pam_unix(su:session): session closed for user root
Jan 29 12:55:56 localhost pam: gdm-password[3029]: pam_unix(gdm-password:session): session closed for user misfitred
Jan 29 12:55:56 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:55:58 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name :1.78 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:56:29 localhost pam: gdm-password[4044]: pam_unix(gdm-password:auth): conversation failed
Jan 29 12:56:29 localhost pam: gdm-password[4044]: pam_unix(gdm-password:auth): auth could not identify password for [misfitred]
Jan 29 12:56:29 localhost pam: gdm-password[4044]: gkr-pam: no password is available for user
Jan 29 12:57:11 localhost pam: gdm-password[4051]: pam_selinux_permit(gdm-password:auth): Cannot determine the user's name
Jan 29 12:57:11 localhost pam: gdm-password[4051]: pam_succeed_if(gdm-password:auth): error retrieving user name: Conversation error
Jan 29 12:57:11 localhost pam: gdm-password[4051]: gkr-pam: couldn't get the user name: Conversation error
Jan 29 12:57:17 localhost pam: gdm-password[4053]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 12:57:17 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name :1.78, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:57:17 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.93 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:57:49 localhost unix_chkpwd[4495]: password check failed for user (root)
Jan 29 12:57:49 localhost su: pam_unix(su:auth): authentication failure; logname=misfitred uid=501 euid=0 tty=pts/0 ruser=misfitred rhost=  user=root
Jan 29 12:58:04 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:16:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:18:05 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:21:14 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:21:40 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:24:17 localhost su: pam_unix(su:session): session opened for user misfitred by misfitred(uid=0)
Jan 29 13:27:10 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user misfitred
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:29:00 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:31:48 localhost sshd[3948]: Received signal 15; terminating.
Jan 29 13:31:48 localhost sshd[5498]: Server listening on port 22.
Jan 29 13:31:48 localhost sshd[5498]: Server listening on :: port 22.
Jan 29 13:44:58 localhost sshd[5498]: Received signal 15; terminating.
Jan 29 13:44:58 localhost sshd[5711]: Server listening on port 22.
Jan 29 13:44:58 localhost sshd[5711]: Server listening on :: port 22.
Jan 29 14:00:19 localhost sshd[5711]: Received signal 15; terminating.
Jan 29 14:00:19 localhost sshd[5956]: Server listening on port 22.
Jan 29 14:00:19 localhost sshd[5956]: Server listening on :: port 22.
Jan 29 15:03:00 localhost sshd[5956]: Received signal 15; terminating.
Jan 29 15:10:23 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:10:38 localhost pam: gdm-password[4053]: pam_unix(gdm-password:session): session closed for user misfitred
Jan 29 15:10:38 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.93, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 15:11:21 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 15:11:32 localhost pam: gdm-password[2919]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 15:11:32 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 15:11:33 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 15:15:10 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:30:24 localhost userhelper[3700]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'root'
Jan 29 15:32:00 localhost su: pam_unix(su:session): session opened for user misfitred by misfitred(uid=0)
Jan 29 15:32:23 localhost passwd: gkr-pam: changed password for 'login' keyring
Jan 29 15:32:39 localhost passwd: pam_unix(passwd:chauthtok): password changed for misfitred
Jan 29 15:32:39 localhost passwd: gkr-pam: couldn't change password for 'login' keyring: 1
Jan 29 15:33:06 localhost passwd: pam_unix(passwd:chauthtok): password changed for misfitred
Jan 29 15:33:06 localhost passwd: gkr-pam: changed password for 'login' keyring
Jan 29 15:37:08 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user misfitred
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:38:25 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:42:47 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:47:13 localhost sshd[4111]: pam_unix(sshd:session): session opened for user misfitred by (uid=0)
Jan 29 16:49:40 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 16:55:19 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 30 08:34:57 localhost sshd[4111]: pam_unix(sshd:session): session closed for user misfitred
Jan 30 08:34:57 localhost su: pam_unix(su:session): session closed for user root
Jan 30 08:35:24 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
ssh permissions centos user-accounts openssh
share improve this question edited Jan 30 '13 at 13:40 asked Jan 29 '13 at 20:24 Kentgrav 743 16
Have you tried another user? Or changing the password for this one? – fboaventura Jan 29 '13 at 20:46
I agree with fboaventura; The configs look fine; try changing the password for your user to what you think it should be, also check that it isn't expired/account locked. And try another user just in case. Also, are you able to log in locally as that user? i.e. is the error specific to SSH or is it having an error via other auth mechs. – Justin Jan 29 '13 at 22:56
(1) caplock? (2) From server, post related error in /var/log/secure John Siu Jan 29 '13 at 23:18
@ fboaventura & Justin I did try another user and I also changed the password and tried it again with no success. I can login locally just fine and I can also SSH to localhost just fine. – Kentgrav Jan 30 '13 at 13:33
@ John Siu I added the /var/log/secure and I attempted the SSH right before I copied it. And nothing was added to it. Hope it helps. – Kentgrav Jan 30 '13 at 13:41
add a comment |
3 Answers active oldest votes
up vote 19 down vote server's /etc/ssh/sshd_config :
  1. To enable password authentication, uncomment
    #PasswordAuthentication yes
  2. To enable root login, uncomment
    #PermitRootLogin yes
  3. To enable ssh key login, uncomment
    #PubkeyAuthentication yes
    #AuthorizedKeysFile .ssh/authorized_keys

I believe (1) is what you're looking for.

share improve this answer edited Jul 10 '16 at 11:54 The Sexiest Man in Jamaica 113 answered Jan 30 '13 at 14:02 John Siu 4,542 10 20
Yeah I did this already I actually figured out what the problem was. And as I was the one thing that should have been blatantly obvious. – Kentgrav Jan 30 '13 at 16:08
For anyone else who is wondering you can find it sshd_config here: /etc/ssh/sshd_config – Oliver Dixon Aug 21 '15 at 9:20
The problem with this answer is that the defaults are commented out by default as the comments in the file explain. It doesn't matter if (1) is commented or not because the default is "yes". The correct answer is below. It's probably a DNS problem and can easily test by using the IP address instead of the domain name. – Colin Keenan Sep 18 '15 at 4:41
and you will have to restart the ssh service – Radu Gabriel May 24 at 12:56

[Aug 02, 2017] Why am I still getting a password prompt with ssh with public key authentication

Aug 02, 2017 |

Thom , asked Apr 16 '12 at 14:38

I'm working from the URL I found here:

My ssh client is Ubuntu 64 bit 11.10 desktop and my server is Centos 6.2 64 bit. I have followed the directions. I still get a password prompt on ssh.

I'm not sure what to do next.

Rob , answered Apr 17 '12 at 15:28

Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

¹ Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group.

Tgr , answered Nov 12 '12 at 7:55

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, e.g.:
service ssh stop      # will not kill existing ssh connections
/usr/sbin/sshd -d     # full path to sshd executable needed, 'which sshd' can help
...debug output...
service ssh start

(If you can access the server through any port, you can just use /usr/sbin/sshd -d -p <port number> to avoid having to stop the SSH server. You still need to be root though.)

In the debug output, look for something like

debug1: trying public key file /path/to/home/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /path/to/home/

cee , answered Sep 23 '12 at 9:31

Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config .

What I ended up doing was create a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authorized_keys file in there. Then changed the AuthorizedKeysFile directive in /etc/ssh/config to :

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

This allows multiple users to have this ssh access without compromising permissions.

Sahil , answered Jul 3 '12 at 7:34

I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.

gusior , answered Nov 7 '13 at 0:16

After copying keys to the remote machine and putting them inside the authorized_keys you've got to do something like this:
ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Ravindra , answered May 17 '13 at 8:46

Just try these following commands
  1. ssh-keygen

    Press Enter key till you get the prompt

  2. ssh-copy-id -i root@ip_address

    (It will once ask for the password of the host system)

  3. ssh root@ip_address

    Now you should be able to login without any password

David Mackintosh , answered Sep 8 '14 at 18:44

SELinux on RedHat/CentOS 6 has an issue with pubkey authentication , probably when some of the files are created selinux is not setting its ACLs correctly.

To manually fix the SElinux ACLs for the root user:

restorecon -R -v /root/.ssh

Joachim Nilsson , answered Nov 6 '14 at 9:34

We ran into the same problem and we followed the steps in the answer. But it still did not work for us. Our problem was that login worked from one client but not from another (the .ssh directory was NFS mounted and both clients were using the same keys).

So we had to go one step further. By running the ssh command in verbose mode you get a lot of information.

ssh -vv user@host

What we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277

Obviously this will not work from any other client.

So the solution in our case was to switch the default rsa key to the one that contained user@myclient. When a key is default, there is no checking for client name.

Then we ran into another problem, after the switch. Apparently the keys are cached in the local ssh agent and we got the following error on the debug log:

'Agent admitted failure to sign using the key'

This was solved by reloading the keys to the ssh agent:



It would be SSH miss configuration at server end. Server side sshd_config file has to be edited. Located in /etc/ssh/sshd_config . In that file, change variables

Based on

[Mar 04, 2017] shell - How to scp a folder from remote to local - Stack Overflow

Notable quotes:
"... Did not know about the config file, this is awesome! ..."
Feb 18, 2017 |
How to scp a folder from remote to local? [closed]
Ask Question up vote 1197 down vote favorite 340

I am not sure whether it is possible to scp a folder from remote to local, but still I am left with no other options. I use ssh to log into my server and from there I would like to copy the folder foo to home/user/Desktop (my local). Is there any command so that I can do this?

To use full power of scp you need to go through next steps:

  1. Public key authorisation
  2. Create ssh aliases

Then, for example if you'll have this ~/.ssh/config :


you'll save yourself from password entry and simplify scp syntax like this:

r prod
# copy to local

r prod
foo test
# copy from remote prod to remote test

More over, you will be able to use remote path-completion:

scp test
# press tab twice
y or n


For enabling remote bash-completion you need to have bash-shell on both <source> and <target> hosts, and properly working bash-completion. For more information see related questions:

How to enable autocompletion for remote paths when using scp?
SCP filename tab completion

Did not know about the config file, this is awesome! dmastylo Mar 1 '14 at 20:27

What I always use is:

r username@IP

. (dot) : it means current folder . so copy from server and paste here only.

IP : can be an IP address like or it can be host like .

[Feb 18, 2017] ssh - scp without replacing existing files in the destination - Unix Linux Stack Exchange

Notable quotes:
"... scp will overwrite the files only if you have write permissions to them. In other words: You can make scp effectively skip said files by temporarily removing the write permissions on them (if you are the files' owner, that is). ..."
"... before running scp (it will complain and skip the existing files). And change them back afterward ( chmod +w to get umask based value). If the files do not all have write permission according to your umask, you would somehow have to store the permissions so that you can restore them. (Gilles' answer overwrites existing files if locally they are newer, I lost valuable data that way. Do not understand why that wrong and harmful answer has so many up votes). I don't get it: how did rsync --ignore-existing cause you to lose data? – ..."
"... Unable to create temporary file Clock skew detected ..."
"... In my case - I could not do this and the solution was: lftp . lftp 's usage for syncronization is below: ..."
"... To copy a whole bunch of files, it's faster to tar them. By using -k you also prevent tar from overwriting files when unpacking it on the target system. ..."
Feb 18, 2017 |

scp without replacing existing files in the destination

How do I copy an entire directory into a directory of the same name without replacing the content in the destination directory? (instead, I would like to add to the contents of the destination folder) ssh rsync scp synchronization

Use rsync , and pass -u if you want to only update files that are newer in the original directory, or --ignore-existing to skip all files that already exist in the destination.
rsync -au /local/directory/ host:/remote/directory/
rsync -a --ignore-existing /local/directory/ host:/remote/directory/

(Note the / on the source side: without it rsync would create /remote/directory/directory .)

@Anthon I don't understand your comment and I don't see an answer or comment by chandra. --ignore-existing does add without replacing, what data loss do you see? – Gilles Nov 27 '13 at 9:59

Sorry, I only looked at your first example that is where you can have data loss (and is IMHO not what the OP asked for), if you include --ignore-existing data-loss should not happen. – Anthon Nov 27 '13 at 10:08

This does not help if the remote system does not have rsync easily available.... (Like Win32-OpenSSH) – Gert van den Berg Oct 25 '16 at 8:00

@GertvandenBerg rsync is pretty easy to install on Windows, no harder than SSH. – Gilles Oct 25 '16 at 11:51

@Gilles: True, but all of the options seems to involve Cygwin DLLs... (The current state of the MS port of OpenSSH is such that enabling compression on scp is enough to break SCP...) (Getting rsync functional over Win32-OpenSSH also seems non-trivial - hopefully that improves over time) (Solaris 10 is the other example, where a third party package and --rsync-path is needed) – Gert van den Berg Oct 25 '16 at 13:01

scp will overwrite the files only if you have write permissions to them. In other words: You can make scp effectively skip said files by temporarily removing the write permissions on them (if you are the files' owner, that is).

Anthon 49.6k 14 68 132 answered Oct 15 '12 at 21:10 Reimund 491 4 2

Thanks for this. Was exactly the trick I was looking for. – saccharine Jul 16 '13 at 21:02

make sure you copy the files back you add a * to do so. Example scp -r* /local/location/ Rick May 27 '15 at 19:16

find . -type f -exec chown root:root {} \; – ling Aug 21 '16 at 19:58

You can copy only new files by date. Use find

scp  `find /data/*.gz -type f -mtime +7` USER@SERVER:/backup/


If you can make the destination file contents read-only:

find . -type f -exec chmod a-w

before running scp (it will complain and skip the existing files). And change 
      them back afterward ( chmod +w to get umask based value). If the files do not all 
      have write permission according to your umask, you would somehow have to store the permissions 
      so that you can restore them. 

(Gilles' answer overwrites existing files if locally they are newer, I lost valuable data that way. Do not understand why that wrong and harmful answer has so many up votes).

I don't get it: how did rsync --ignore-existing cause you to lose data? – Gilles Nov 27 '13 at 10:01 add a comment |

I had a similar task, in my case I could not use rsync , csync , or FUSE because my storage has only SFTP. rsync could not change the date and time for the file, some other utilities (like csync ) showed me other errors: " Unable to create temporary file Clock skew detected ".

If you have access to the storage-server - just install openssh-server or launch rsync as a daemon here.

In my case - I could not do this and the solution was: lftp . lftp 's usage for syncronization is below:

lftp -c "open -u login,password sftp://sft.domain.tld/; \
    mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder"

/src/folder - is the folder on my PC, /rem/folder - is sftp://sft.domain.tld/rem/folder .

You may find man pages by the link:

scp does overwrite files and there's no switch to stop it doing that, but you can copy things out the way, do the scp and then copy the existing files back. Examples:

  1. Copy all existing files out the way
    mkdir original_files ; cp -r * original_files/
  2. Copy everything using scp
    scp -r user@server:dir/* ./
  3. Copy the original files over anything scp has written over:
    cp -r original_files/* ./

This method doesn't help when you're trying to pull files over from a remote and pick up where you left off. I.e. if the whole purpose is to save time. – Oliver Williams Dec 1 '16 at 17:58

>To copy a whole bunch of files, it's faster to tar them. By using -k you also prevent tar from overwriting files when unpacking it on the target system.

tar -c <source-dir> | ssh <name>@<host> 'tar -kxzf - -C <target-dir>' 

It does make a remote connection. First it tar's the source, pipes it into the ssh connection and unpacks it on the remote system. – huembi Aug 22 '16 at 21:17

[Feb 16, 2017] How to create ssh aliases by Alexander Yancharuk

Dec 4 2013 |

To use full power of scp you need to go through next steps:

  1. Public key authorisation
  2. Create ssh aliases

Then, for example if you'll have this ~/.ssh/config:

Host test
    User testuser
    Port 22022

Host prod
    User produser
    Port 22022

you'll save yourself from password entry and simplify scp syntax like this:

scp -r prod:/path/foo /home/user/Desktop   # copy to local
scp -r prod:/path/foo test:/tmp            # copy from remote prod to remote test

More over, you will be able to use remote path-completion:

scp test:/var/log/  # press tab twice
Display all 151 possibilities? (y or n)


For enabling remote bash-completion you need to have bash-shell on both <source> and <target> hosts, and properly working bash-completion. For more information see related questions:

How to enable autocompletion for remote paths when using scp?
SCP filename tab completion

[Dec 26, 2016] How To Stop SSH Session From Disconnecting In Linux

Notable quotes:
"... The following steps needs to be performed in your SSH client, not in the remote server. ..."
Dec 26, 2016 |

The following steps needs to be performed in your SSH client, not in the remote server.

To configure the current user, edit SSH config file:

sudo nano ~/.ssh/config

Add the following lines:

Host *
 ServerAliveInterval 60

Please ensure you indent the second line with a space . Let me explain what these lines do. Once you added these lines in your SSH client system, it will send a packet called no-op (No Operation) to your Remote system. The no-op packet will inform the remote system "Nothing to do". Also it tells the SSH client is still connected with the remote system, hence do not close the TCP connection and log you out.

Here "Host *" indicates this configuration is applicable for all remote hosts. "ServerAliveInterval 60" indicates the number of seconds to wait to send a no-op packet.

... ... ...

To apply this settings for all users (globally) in your system, add or modify the following line in /etc/ssh/ssh_config file.

ServerAliveInterval 60

[Nov 08, 2015] Single command shell accounts

Notable quotes:
"... /etc/ssh/sshd_config ..."
"... /home/restricteduser/.ssh/authorized_keys ..."

There are times when you will want a single purpose user account – an account that cannot get a shell, not can it do anything but run a single command. This can come in useful for a few reasons – for me, I use it to force an svn update on machines that can't use user generated crontabs. Others have used this setup to allow multiple users run some arbitrary command, without giving them shell access.

Add the user

Add the user as you'd add any user. You'll need a home directory, as I want to use ssh keys so I don't need a password and it can be scripted from the master server.

 root@slave1# adduser restricteduser
Set the users password

Select a nice strong password. I like using $pwgen 32

 root@slave1# passwd restricteduser
Copy your ssh-key to the server

Some Linux distros don't have the following command, in this case, contact your distro mailing list or Google.

 root@master# ssh-copy-id restricteduser@slave1
Lock out the user

Password lock out the user. This contradicts the above step, but it ensures that restricteduser can't update their password.

 root@slave1# passwd -l restricteduser
Edit the sshd config

Depending on your system, this can be in a number of places. On Debian, it's in /etc/ssh/sshd_config. Put it down the bottom.

 Match User restricteduser
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand /bin/foobar_command
Restart ssh
 root@slave1# service ssh restart
Add more ssh keys

Add any additional ssh key to /home/restricteduser/.ssh/authorized_keys

Some Tips To Make SSH-SCP Usage More Convenient HowtoForge - Linux Howtos and Tutorials

I guess many of us rely heavily on ssh/scp to access/maintain remote hosts. In this short article I would like to share some experiences I find useful for ssh/scp usage.

First let's have a look how things started:

I use a simple trick to get out of this mess: I have a simple script named ssh-generic that looks as follows:

case "$0" in
    echo "unsupported name: $0"
    exit 1

case "$0" in
    echo running ssh -p $port $account "$@"
    ssh -p $port $account "$@"
    echo running scp -P $port "$@" $account:
    scp -P $port "$@" $account:$scpdir
    echo scp -P $port $account:$1 .
    scp -P $port $account:$1 .
    echo "unsupported name: $0"
    exit 1

Then I make ssh-host1, scp-to-host1 and scp-from-host1 as symlink to the above script (ie ssh-generic). Usage is trivial:

Similar for host2 and host3. When we get another host, it's easy to edit ssh-generic, add the relevant entry and make needed symlinks. For example, let's add another host with ip, port for ssh 2222 and user id admin2. We want to access this host by simply saying ssh-host4. This turns out to be easy:


A bonus is that we can say in the command line eg ssh-host<Tab> to free ourselves from remembering the hostnames, connection details and hence from making mistakes. There are some cosmetic details that I left out from the script for clarity, like automatically setting the title of current xshell before running ssh/scp, or a dryrun option for the script.

I also have a companion script that can be used to ease uploading ssh keys. I named it "enable-ssh" (a bit poor chosen name, should be renamed to something better) and it looks as follows:

if test -z "$1"; then
        echo Usage: $0 '[-p <port>] <host>'
        exit 1

if ! test -s $HOME/.ssh/; then
    ssh-keygen -t rsa

cat $HOME/.ssh/ | \
    ssh "$@" "mkdir -p .ssh; touch .ssh/authorized_keys; cat >> .ssh/authorized_keys"


That's it. I hope you find this useful.

[May 08, 2014] 8 Cool Ways To Use SCP

October 14, 2011 |
Edit a file on a remote host using vim
vim scp://username@host//path/to/somefile
Colored diff ( via vim ) on 2 remotes files on your local computer.
vimdiff scp:// scp://
Restrict the bandwidth for the SCP command
scp -l10* .

the command is obvious, I know, but maybe not everyone knows that using the parameter "-l" you can limit the use of bandwidth command scp.

In this example fetch all files from the directory zutaniddu and I copy them locally using only 10 Kbs

Compare a remote file with a local file
vimdiff  scp://[@]/
Easily scp a file back to the host you're connecting from
mecp () { scp "$@" ${SSH_CLIENT%% *}:Desktop/; }

Place in .bashrc and invoke like this: "mecp /path/to/file", and it will copy the specified file(s) back to the desktop of the host you're ssh'ing in from. To easily upload a file from the host you're ssh'ing in from use this:

ucp (){ scp ${SSH_CLIENT%% *}:Desktop/upload/* .; }
scp file from hostb to hostc while logged into hosta
scp user@hostb:file user@hostc:

While at the command line of of hosta, scp a file from remote hostb to remote hostc. This saves the step of logging into hostb and then issuing the scp command to hostc.

Copy something to multiple SSH hosts with a Bash loop
for h in host1 host2 host3 host4 ; { scp file user@$h:/destination_path/ ; }

Just a quick and simple one to demonstrate Bash For loop. Copies 'file' to multiple ssh hosts.

scp with compression.
scp -C /path/to/backup.sql

[May 08, 2014] 25 Best SSH Commands

Tricks UrFix's Blog
1) Copy ssh keys to user@host to enable password-less ssh logins.

ssh-copy-id user@host

To generate the keys use the command ssh-keygen

2) Start a tunnel from some machine's port 80 to your local post 2001

ssh -N -L2001:localhost:80 somemachine

Now you can acces the website by going to http://localhost:2001/

3) Output your microphone to a remote computer's speaker

dd if=/dev/dsp | ssh -c arcfour -C username@host dd of=/dev/dsp

This will output the sound from your microphone port to the ssh target computer's speaker port. The sound quality is very bad, so you will hear a lot of hissing.

4) Compare a remote file with a local file

ssh user@host cat /path/to/remotefile | diff /path/to/localfile -

Useful for checking if there are differences between local and remote files.

5) Mount folder/filesystem through SSH

sshfs name@server:/path/to/folder /path/to/mount/point

Install SSHFS from
Will allow you to mount a folder security over a network.

6) SSH connection through host in the middle

ssh -t reachable_host ssh unreachable_host

Unreachable_host is unavailable from local network, but it's available from reachable_host's network. This command creates a connection to unreachable_host through "hidden" connection to reachable_host.

7) Copy from host1 to host2, through your host

ssh root@host1 "cd /somedir/tocopy/ && tar -cf - ." | ssh root@host2 "cd /samedir/tocopyto/ && tar -xf -"

Good if only you have access to host1 and host2, but they have no access to your host (so ncat won't work) and they have no direct access to each other.

8) Run any GUI program remotely

ssh -fX <user>@<host> <program>

The SSH server configuration requires:

X11Forwarding yes # this is default in Debian

And it's convenient too:

Compression delayed

9) Create a persistent connection to a machine

ssh -MNf <user>@<host>

Create a persistent SSH connection to the host in the background. Combine this with settings in your ~/.ssh/config:
Host host
ControlPath ~/.ssh/master-%r@%h:%p
ControlMaster no
All the SSH connections to the machine will then go through the persisten SSH socket. This is very useful if you are using SSH to synchronize files (using rsync/sftp/cvs/svn) on a regular basis because it won't create a new socket each time to open an ssh connection.

10) Attach screen over ssh

ssh -t remote_host screen -r

Directly attach a remote screen session (saves a useless parent bash process)

11) Port Knocking!

knock <host> 3000 4000 5000 && ssh -p <port> user@host && knock <host> 5000 4000 3000

Knock on ports to open a port to a service (ssh for example) and knock again to close the port. You have to install knockd.

See example config file below.
logfile = /var/log/knockd.log
sequence = 3000,4000,5000
seq_timeout = 5
command = /sbin/iptables -A INPUT -i eth0 -s %IP% -p tcp -dport 22 -j ACCEPT
tcpflags = syn
sequence = 5000,4000,3000
seq_timeout = 5
command = /sbin/iptables -D INPUT -i eth0 -s %IP% -p tcp -dport 22 -j ACCEPT
tcpflags = syn

12) Remove a line in a text file. Useful to fix

ssh-keygen -R <the_offending_host>

In this case it's better do to use the dedicated tool

13) Run complex remote shell cmds over ssh, without escaping quotes

ssh host -l user $(<cmd.txt)

Much simpler method. More portable version: ssh host -l user "`cat cmd.txt`"

14) Copy a MySQL Database to a new Server via SSH with one command

mysqldump -add-drop-table -extended-insert -force -log-error=error.log -uUSER -pPASS OLD_DB_NAME | ssh -C user@newhost "mysql -uUSER -pPASS NEW_DB_NAME"

Dumps a MySQL database over a compressed SSH tunnel and uses it as input to mysql - i think that is the fastest and best way to migrate a DB to a new server!

15) Remove a line in a text file. Useful to fix "ssh host key change" warnings

sed -i 8d ~/.ssh/known_hosts

16) Copy your ssh public key to a server from a machine that doesn't have ssh-copy-id

cat ~/.ssh/ | ssh user@machine "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

If you use Mac OS X or some other *nix variant that doesn't come with ssh-copy-id, this one-liner will allow you to add your public key to a remote machine so you can subsequently ssh to that machine without a password.

17) Live ssh network throughput test

yes | pv | ssh $host "cat > /dev/null"

connects to host via ssh and displays the live transfer speed, directing all transferred data to /dev/null
needs pv installed

Debian: 'apt-get install pv'
Fedora: 'yum install pv' (may need the 'extras' repository enabled)

18) How to establish a remote Gnu screen session that you can re-connect to

ssh -t /usr/bin/screen -xRR

Long before tabbed terminals existed, people have been using Gnu screen to open many shells in a single text terminal. Combined with ssh, it gives you the ability to have many open shells with a single remote connection using the above options. If you detach with "Ctrl-a d" or if the ssh session is accidentally terminated, all processes running in your remote shells remain undisturbed, ready for you to reconnect. Other useful screen commands are "Ctrl-a c" (open new shell) and "Ctrl-a a" (alternate between shells). Read this quick reference for more screen commands:

19) Resume scp of a big file

rsync -partial -progress -rsh=ssh $file_source $user@$host:$destination_file

It can resume a failed secure copy ( usefull when you transfer big files like db dumps through vpn ) using rsync.
It requires rsync installed in both hosts.
rsync -partial -progress -rsh=ssh $file_source $user@$host:$destination_file local -> remote
rsync -partial -progress -rsh=ssh $user@$host:$remote_file $destination_file remote -> local

20) Analyze traffic remotely over ssh w/ wireshark

ssh 'tshark -f "port !22" -w -' | wireshark -k -i -

This captures traffic on a remote machine with tshark, sends the raw pcap data over the ssh link, and displays it in wireshark. Hitting ctrl+C will stop the capture and unfortunately close your wireshark window. This can be worked-around by passing -c # to tshark to only capture a certain # of packets, or redirecting the data through a named pipe rather than piping directly from ssh to wireshark. I recommend filtering as much as you can in the tshark command to conserve bandwidth. tshark can be replaced with tcpdump thusly:
ssh tcpdump -w - 'port !22′ | wireshark -k -i -

21) Have an ssh session open forever

autossh -M50000 -t 'screen -raAd mysession'

Open a ssh session opened forever, great on laptops losing Internet connectivity when switching WIFI spots.

22) Harder, Faster, Stronger SSH clients

ssh -4 -C -c blowfish-cbc

We force IPv4, compress the stream, specify the cypher stream to be Blowfish. I suppose you could use aes256-ctr as well for cypher spec. I'm of course leaving out things like master control sessions and such as that may not be available on your shell although that would speed things up as well.

23) Throttle bandwidth with cstream

tar -cj /backup | cstream -t 777k | ssh host 'tar -xj -C /backup'

this bzips a folder and transfers it over the network to "host" at 777k bit/s.
cstream can do a lot more, have a look
for example:

echo w00t, i'm 733+ | cstream -b1 -t2
24) Transfer SSH public key to another machine in one step

ssh-keygen; ssh-copy-id user@host; ssh user@host

This command sequence allows simple setup of (gasp!) password-less SSH logins. Be careful, as if you already have an SSH keypair in your ~/.ssh directory on the local machine, there is a possibility ssh-keygen may overwrite them. ssh-copy-id copies the public key to the remote host and appends it to the remote account's ~/.ssh/authorized_keys file. When trying ssh, if you used no passphrase for your key, the remote shell appears soon after invoking ssh user@host.

25) Copy stdin to your X11 buffer

ssh user@host cat /path/to/some/file | xclip

Have you ever had to scp a file to your work machine in order to copy its contents to a mail? xclip can help you with that. It copies its stdin to the X11 buffer, so all you have to do is middle-click to paste the content of that looong file :)

Have Fun

Please comment if you have any other good SSH Commands OR Tricks.


Dofus says:

Related to your 19.
I've got a nice alias in my bashRc, called rescp.

alias rescp='rsync -size-only -partial -progress -stats -inplace'

I just use it in place of scp, and it work great!

Doug says:

Good list overall.

I'm not sure I see a the difference between #1 and #7. Are they dups?

Same goes for #10, #18, and somewhat #21 - While slightly different invocations, they ultimately do the same thing, right? My preference is using the #21 syntax to always ensure connection back to the same screen session.

Also #6 and #8 seem to be identical as well.

And #12 looks like it is incomplete.

Isaiah says:

@Doug you are absolutely right! # 1 and #8 are exactly the same, I didn't even notice, thank you for pointing that out, I'm going to have to add a replacement command for that one as far #18 the -x switch allows you to connect to a non-datached screen and #21 has the -m switch which ignore $STY variable, do create a new screen session.
#6 and #8 are exactly the same and once again sorry for that.
but #12 is good

eliasp says:

#15 makes more sense like this:

sed -i '/^name-of-offending-host/d' ~/.ssh/known_hosts

My personal Favorite is the reverse of #2:

ssh firewalledhost
export http_proxy=localhost:3128

If firewalledhost can't reach the public internet or the machine someSquidProxy, but your machine can, this opens a tunnel via SSH. I use it a lot to download patches to machines that normally can't get them directly.

Diogo Melo says:


very nice tricks

I wrote a set of SSH Tricks myself

Lazy Linux: 10 essential tricks for admins by Vallard Benincosa Certified Technical Sales Specialist, IBM

20 Jul 2008 | IBM DeveloperWorks

Trick 5: SSH back door

Many times I'll be at a site where I need remote support from someone who is blocked on the outside by a company firewall. Few people realize that if you can get out to the world through a firewall, then it is relatively easy to open a hole so that the world can come into you.

In its crudest form, this is called "poking a hole in the firewall." I'll call it an SSH back door. To use it, you'll need a machine on the Internet that you can use as an intermediary.

In our example, we'll call our machine The machine behind the company firewall is called ginger. Finally, the machine that technical support is on will be called tech. Figure 4 explains how this is set up.

Figure 4. Poking a hole in the firewall
Poking a hole in the firewall

Here's how to proceed:

  1. Check that what you're doing is allowed, but make sure you ask the right people. Most people will cringe that you're opening the firewall, but what they don't understand is that it is completely encrypted. Furthermore, someone would need to hack your outside machine before getting into your company. Instead, you may belong to the school of "ask-for-forgiveness-instead-of-permission." Either way, use your judgment and don't blame me if this doesn't go your way.

  2. SSH from ginger to with the -R flag. I'll assume that you're the root user on ginger and that tech will need the root user ID to help you with the system. With the -R flag, you'll forward instructions of port 2222 on blackbox to port 22 on ginger. This is how you set up an SSH tunnel. Note that only SSH traffic can come into ginger: You're not putting ginger out on the Internet naked.

    You can do this with the following syntax:

    ~# ssh -R 2222:localhost:22

    Once you are into blackbox, you just need to stay logged in. I usually enter a command like:

    thedude@blackbox:~$ while [ 1 ]; do date; sleep 300; done

    to keep the machine busy. And minimize the window.

  3. Now instruct your friends at tech to SSH as thedude into blackbox without using any special SSH flags. You'll have to give them your password:

    root@tech:~# ssh .

  4. Once tech is on the blackbox, they can SSH to ginger using the following command:

    thedude@blackbox:~$: ssh -p 2222 root@localhost

  5. Tech will then be prompted for a password. They should enter the root password of ginger.

  6. Now you and support from tech can work together and solve the problem. You may even want to use screen together! (See Trick 4.)

Trick 6: Remote VNC session through an SSH tunnel

VNC or virtual network computing has been around a long time. I typically find myself needing to use it when the remote server has some type of graphical program that is only available on that server.

For example, suppose in Trick 5, ginger is a storage server. Many storage devices come with a GUI program to manage the storage controllers. Often these GUI management tools need a direct connection to the storage through a network that is at times kept in a private subnet. Therefore, the only way to access this GUI is to do it from ginger.

You can try SSH'ing to ginger with the -X option and launch it that way, but many times the bandwidth required is too much and you'll get frustrated waiting. VNC is a much more network-friendly tool and is readily available for nearly all operating systems.

Let's assume that the setup is the same as in Trick 5, but you want tech to be able to get VNC access instead of SSH. In this case, you'll do something similar but forward VNC ports instead. Here's what you do:

  1. Start a VNC server session on ginger. This is done by running something like:

    root@ginger:~# vncserver -geometry 1024x768 -depth 24 :99

    The options tell the VNC server to start up with a resolution of 1024x768 and a pixel depth of 24 bits per pixel. If you are using a really slow connection setting, 8 may be a better option. Using :99 specifies the port the VNC server will be accessible from. The VNC protocol starts at 5900 so specifying :99 means the server is accessible from port 5999.

    When you start the session, you'll be asked to specify a password. The user ID will be the same user that you launched the VNC server from. (In our case, this is root.)

  2. SSH from ginger to forwarding the port 5999 on blackbox to ginger. This is done from ginger by running the command:

    root@ginger:~# ssh -R 5999:localhost:5999

    Once you run this command, you'll need to keep this SSH session open in order to keep the port forwarded to ginger. At this point if you were on blackbox, you could now access the VNC session on ginger by just running:

    thedude@blackbox:~$ vncviewer localhost:99

    That would forward the port through SSH to ginger. But we're interested in letting tech get VNC access to ginger. To accomplish this, you'll need another tunnel.

  3. From tech, you open a tunnel via SSH to forward your port 5999 to port 5999 on blackbox. This would be done by running:

    root@tech:~# ssh -L 5999:localhost:5999

    This time the SSH flag we used was -L, which instead of pushing 5999 to blackbox, pulled from it. Once you are in on blackbox, you'll need to leave this session open. Now you're ready to VNC from tech!

  4. From tech, VNC to ginger by running the command:

    root@tech:~# vncviewer localhost:99 .

    Tech will now have a VNC session directly to ginger.

While the effort might seem like a bit much to set up, it beats flying across the country to fix the storage arrays. Also, if you practice this a few times, it becomes quite easy.

Let me add a trick to this trick: If tech was running the Windows® operating system and didn't have a command-line SSH client, then tech can run Putty. Putty can be set to forward SSH ports by looking in the options in the sidebar. If the port were 5902 instead of our example of 5999, then you would enter something like in Figure 5.

Figure 5. Putty can forward SSH ports for tunneling
Putty can forward SSH ports for tunneling

If this were set up, then tech could VNC to localhost:2 just as if tech were running the Linux operating system.

[Aug 09, 2012] Speaking UNIX: The best-kept secrets of UNIX power users by Martin Streicher, Software Developer, Pixel, Byte, and Comma

May 25, 2010 | IBM DeveloperWorld

Shhh . . . secrets about SSH

Secure Shell (SSH) is a rich subsystem used to log in to remote systems, copy files, and tunnel through firewalls-securely. Since SSH is a subsystem, it offers plenty of options to customize and streamline its operation. In fact, SSH provides an entire "dot directory", named $HOME/.ssh, to contain all its data. (Your .ssh directory must be mode 600 to preclude access by others. A mode other than 600 interferes with proper operation.) Specifically, the file $HOME/.ssh/config can define lots of shortcuts, including aliases for machine names, per-host access controls, and more.

Here is a typical block found in $HOME/.ssh/config to customize SSH for a specific host:

Host worker
IdentityFile ~/.ssh/id_rsa_worker
User joeuser

Each block in ~/.ssh/config configures one or more hosts. Separate individual blocks with a blank line. This block uses four options: Host, HostName, IdentityFile, and User. Host establishes a nickname for the machine specified by HostName. A nickname allows you to type ssh worker instead of ssh Moreover, the IdentityFile and User options dictate how to log in to worker. The former option points to a private key to use with the host; the latter option provides the login ID. Thus, this block is the equivalent of the command:
ssh -i ~/.ssh/id_rsa_worker

A powerful but little-known option is ControlMaster. If set, multiple SSH sessions to the same host share a single connection. Once the first connection is established, credentials are not required for subsequent connections, eliminating the drudgery of typing a password each and every time you connect to the same machine. ControlMaster is so handy, you'll likely want to enable it for every machine. That's accomplished easily enough with the host wildcard, *:
Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

As you might guess, a block tagged Host * applies to every host, even those not explicitly named in the config file. ControlMaster auto tries to reuse an existing connection but will create a new connection if a shared connection cannot be found. ControlPath points to a file to persist a control socket for sharing. %r is replaced by the remote login user name, %h is replaced by the target host name, and %p stands in for the port used for the connection. (You can also use %l; it is replaced with the local host name.) The specification above creates control sockets with file names akin to:

Each control socket is removed when all connections to the remote host are severed. If you want to know which machines you are connected to at any time, simply type ls ~/.ssh and look at the host name portion of the control socket (%h).

The SSH configuration file is so expansive, it too has its own man page. Type man ssh_config to see all possible options. And here's a clever SSH trick: You can tunnel from a local system to a remote one via SSH. The command line to use looks something like this:

$ ssh -L 5000:localhost:3306

This command says, "Connect via and establish a tunnel between port 5000 on the local machine and port 3306 [the MySQL server port] on the machine named 'localhost.'" Because localhost is interpreted on as the tunnel is established, localhost is With the outbound tunnel-formally called a local forward-established, local clients can connect to port 5000 and talk to the MySQL server running on

This is the general form of tunneling:

$ ssh proxyhost localport:targethost:targetport

Here, proxyhost is a machine you can access via SSH and one that has a network connection (not via SSH) to targethost. localport is a non-privileged port (any unused port above 1024) on your local system, and targetport is the port of the service you want to connect to.

The previous command tunnels out from your machine to the outside world. You can also use SSH to tunnel in, or connect to your local system from the outside world. This is the general form of an inbound tunnel:

$ ssh user@proxyhost -R proxyport:targethosttargetport

When establishing an inbound tunnel-formally called a remote forward-the roles of proxyhost and targethost are reversed: The target is your local machine, and the proxy is the remote machine. user is your login on the proxy. This command provides a concrete example:
$ ssh -R 8080:localhost:80

The command reads, "Connect to as joe, and connect the remote port 8080 to local port 80." This command gives users on a tunnel to Joe's machine. A remote user can connect to 8080 to hit the Web server on Joe's machine.

In addition to -L and -R for local and remote forwards, respectively, SSH offers -D to create an HTTP proxy on a remote machine. See the SSH man page for the proper syntax.

Martin Streicher is a freelance Ruby on Rails developer and the former Editor-in-Chief of Linux Magazine. Martin holds a Masters of Science degree in computer science from Purdue University and has programmed UNIX-like systems since 1986. He collects art and toys. You can reach Martin at

[May 27, 2012] 5 Cool Things You Can Do With an SSH Server - How-To Geek

Visualizing Key Fingerprints

When you connect to your SSH server from another system, you'll see a warning message if the system doesn't already know its key. This message helps you ensure the remote system isn't being impersonated by another system.

However, you may have trouble remembering the long string that identifies the remote system's public key. To make the key's fingerprint easier to remember, enable the "visual host key" feature.

You can enable this in your SSH config file or just specify it as an option while running the SSH command. For example, run the following command to connect to an SSH server with VisualHostKey enabled:

ssh -o VisualHostKey=yes user@host

Now you'll only have to remember the picture, not a long string.

Do you have any other tips to share? Leave a comment and let us know.

[Nov 26, 2011] User Access Control Lists

Sshd user access control lists (ACLs) can be specified in the server configuration file. No other part of the operating system honors this ACL. You can either specifically allow or deny individual users or groups. The default is to allow access to anyone with a valid account. You can use ACLs to limit access to particular users in NIS environments, without resorting to custom pluggable authentication modules. Use only one of the following four ACL keywords in the server configuration file: AllowGroups, AllowUsers, DenyGroups or DenyUsers.

 # Allow only the sysadmin staff
 AllowGroups staff
 # Prevent unauthorized users.
 DenyUsers cheng atkinson

[Aug 27, 2010] How To Execute SSH and SCP in Batch Mode (Only when Passwordless login is enabled) by Ramesh Natarajan

October 28, 2009

When you have the password-less login enabled, you may be either using SSH to execute command in the batch mode on a remote machine or using SCP to copy files from/to the remote machine.

If there are some issues with the password less login, your batch program may end up in a loop or timeout.

In this article, let us review how instruct ssh/scp to do the operation only if you can do without waiting for password.

Before you try this out, make sure password less login is setup between your local host and remote host.

1. ssh -o "BatchMode yes" Usage Example

If you have the password less login enabled, following example will login to the remote host and execute the who command without asking for the password.

local-host# ssh ramesh@remote-host whoIf the password less login is not enabled, it will prompt for the password 
	on the remote host as shown below.
local-host# ssh ramesh@remote-host who
ramesh@remote-host's password:

If you use ssh -o "BatchMode yes", then it will do ssh only if the password-less login is enabled, else it will return error and continues.

local-host# ssh -o "BatchMode yes" ramesh@remote-host Command

Batch mode command execution using SSH - success case

local-host# ssh -o "BatchMode yes" ramesh@remote-host who
[Note: This will display the output of remote-host's who command]

Batch mode command execution using SSH - Failure case

local-host# ssh -o "BatchMode yes" ramesh@remote-host who
Permission denied (publickey,password).

Note: If you didn't use -o "BatchMode yes", the above command would've asked for the password for my account on the remote host. This is the key difference in using the BatchMode yes option.

2. scp -B option Usage Example

If you use scp -B option, it will execute scp only if the passwordless login is enabled, else it will exit immediately without waiting for password.

$ scp -B file root@IP:PATH

SCP in Batch mode - Successful Case

local-host# scp -B /etc/yp.conf ramesh@remote-host:/tmp
yp.conf            100%   84     0.1KB/s   00:00

SCP in Batch mode - Failure Case

In this example, if scp is possible without authentication, the command will execute else it will exit as shown below.

local-host# scp -B /etc/yp.conf ramesh@remote-host:/tmp
Permission denied (publickey,password).
lost connection

[Aug 23, 2010] SSH Tips And Tricks You Need


Multiplexing Your Connection

Do you make a lot of connections to the same servers? You may not have noticed how slow an initial connection to a shell is. If you multiplex your connection you will definitely notice it though. Let's test the difference between a multiplexed connection using SSH keys and a non-multiplexed connection using SSH keys:

# Without multiplexing enabled:
$ time ssh uptime
 20:47:42 up 16 days,  1:13,  3 users,  load average: 0.00, 0.01, 0.00

real	0m1.215s
user	0m0.031s
sys	0m0.008s

# With multiplexing enabled:
$ time ssh uptime
 20:48:43 up 16 days,  1:14,  4 users,  load average: 0.00, 0.00, 0.00

real	0m0.174s
user	0m0.003s
sys	0m0.004s

We can see that multiplexing the connection is much faster, in this instance on an order of 7 times faster than not multiplexing the connection. Multiplexing allows us to have a "control" connection, which is your initial connection to a server, this is then turned into a UNIX socket file on your computer. All subsequent connections will use that socket to connect to the remote host. This allows us to save time by not requiring all the initial encryption, key exchanges, and negotiations for subsequent connections to the server.

To enable multiplexing do the following:

In a shell:

$ mkdir -p ~/.ssh/connections
$ chmod 700 ~/.ssh/connections

Add this to your ~/.ssh/config file:

Host *
ControlMaster auto
ControlPath ~/.ssh/connections/%r_%h_%p

A negative to this is that some uses of ssh may fail to work with your multiplexed connection. Most notably commands which use tunneling like git, svn or rsync, or forwarding a port. For these you can add the option -o ControlMaster=no. To prevent a specific host from using a multiplexed connection add the following to your ~/.ssh/config file:

MasterControl no

There are security precautions that one should take with this approach. Let's take a look at what actually happens when we connect a second connection:

$ ssh -v -i /dev/null
OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/symkat/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
Last login:
symkat@symkat:~$ exit

As we see no actual authentication took place. This poses a significant security risk if running it from a host that is not trusted, as a user who can read and write to the socket can easily make the connection without having to supply a password. Take the same care to secure the sockets as you take in protecting a private key.

Using SSH As A Proxy

Even Starbucks now has free WiFi in its stores. It seems the world has caught on to giving free Internet at most retail locations. The downside is that more teenagers with "Got Root?" stickers are camping out at these locations running the latest version of wireshark.

SSH's encryption can stand up to most any hostile network, but what about web traffic?

Most web browsers, and certainly all the popular ones, support using a proxy to tunnel your traffic. SSH can provide a SOCKS proxy on localhost that tunnels to your remote server with the -D option. You get all the encryption of SSH for your web traffic, and can rest assured no one will be capturing your login credentials to all those non-ssl websites you're using.

$ ssh -D1080 -oControlMaster=no

Now there is a proxy running on that can be used in a web browser or email client. Any application that supports SOCKS 4 or 5 proxies can use to tunnel its traffic.

$ nc -vvv 1080
Connection to 1080 port [tcp/socks] succeeded!

Using One-Off Commands

Often times you may want only a single piece of information from a remote host. "Is the file system full?" "What's the uptime on the server?" "Who is logged in?"

Normally you would need to login, type the command, see the output and then type exit (or Control-D for those in the know.) There is a better way: combine the ssh with the command you want to execute and get your result:

$ ssh uptime
 18:41:16 up 15 days, 23:07,  0 users,  load average: 0.00, 0.00, 0.00

This executed the ssh, logged in as symkat, and ran the command "uptime" on symkat. If you're not using SSH keys then you'll be presented with a password prompt before the command is executed.

$ ssh ps aux | echo $HOSTNAME

This executed the command ps aux on, sent the output to STDOUT, a pipe on my local laptop picked it up to execute "echo $HOSTNAME" locally. Although in most situations using auxiliary data processing like grep or awk will work flawlessly, there are many situations where you need your pipes and file IO redirects to work on the remote system instead of the local system. In that case you would want to wrap the command in single quotes:

$ ssh 'ps aux | echo $HOSTNAME'

As a basic rule if you're using > >> < - or | you're going to want to wrap in single quotes.

It is also worth noting that in using this method of executing a command some programs will not work. Notably anything that requires a terminal, such as screen, irssi, less, or a plethora of other interactive or curses based applications. To force a terminal to be allocated you can use the -t option:

$ ssh screen -r
Must be connected to a terminal.
$ ssh -t screen -r
$ This worked!

Making SSH A Pipe

Pipes are useful. The concept is simple: take the output from one program's STDOUT and feed it to another program's STDIN. OpenSSH can be used as a pipe into a remote system. Let's say that we would like to transfer a directory structure from one machine to another. The directory structure has a lot of files and sub directories.

We could make a tarball of the directory on our own server and scp it over. If the file system this directory is on lacks the space though we may be better off piping the tarballed content to the remote system.

$ tar -cz content | ssh 'tar -xz'
$ ssh symcat@symkat

What we did in this example was to create a new archive (-c) and to compress the archive with gzip (-z). Because we did not use -f to tell it to output to a file, the compressed archive was send to STDOUT. We then piped STDOUT with | to ssh. We used a one-off command in ssh to invoke tar with the extract (-x) and gzip compressed (-z) arguments. This read the compressed archive from the originating server and unpacked it into our server. We then logged in to see the listing of files.

Additionally, we can pipe in the other direction as well. Take for example a situation where you with to make a copy of a remote database, into a local database:

symkat@chard:~$ echo "create database backup" | mysql -uroot -ppassword
symkat@chard:~$ ssh 'mysqldump -udbuser -ppassword symkat' | mysql -uroot -ppassword backup
symkat@chard:~$ echo use backup;select count(*) from wp_links;" | mysql -uroot -ppassword

What we did here is to create the database "backup" on our local machine. Once we had the database created we used a one-off command to get a dump of the database from The SQL Dump came through STDOUT and was piped to another command. We used mysql to access the database, and read STDIN (which is where the data now is after piping it) to create the database on our local machine. We then ran a MySQL command to ensure that there is data in the backup table. As we can see, SSH can provide a true pipe in either direction.

To transfer a (large, complicated) file tree from one machine to another

Tuesday March 23, 2004 (04:52 PM GMT)

By: Graeme Winter

To transfer a (large, complicated) file tree from one machine to another, using stuff which is usually supported:

tar cf - stuff | ssh tar xf - -C /home/brian


(tar cf - stuff) - tar stuff to the standard output
(| ssh - pipe this to an ssh connection to wendy - where
(tar xf - -C /home/brian) - is run - which will untar the standard input and place the result in /home/brian....

Neat. This is better than using scp -r or tar then scp, because you can send > 4 gig files, and also retain softlinks etc which get broken by scp...

Eleven SSH Tricks

Issue 112: Eleven SSH Tricks
Posted on Friday, August 01, 2003 by Daniel Allen
Printer Friendly Page Send this Article to a Friend

Run remote GUI applications and tunnel any Net connection securely using a free utility that's probably already installed on your system.

SSH is the descendant of rsh and rlogin, which are non-encrypted programs for remote shell logins. Rsh and rlogin, like telnet, have a long lineage but now are outdated and insecure. However, these programs evolved a surprising number of nifty features over two decades of UNIX development, and the best of them made their way into SSH. Following are the 11 tricks I have found useful for squeezing the most power out of SSH.

Installation and Versions

OpenSSH is the most common free version of SSH and is available for virtually all UNIX-like operating systems. It is included by default with Debian, SuSE, Red Hat, Mandrake, Slackware, Caldera and Gentoo Linux, as well as OpenBSD, Cygwin for Windows and Mac OS X. This article is based on OpenSSH, so if you are using some other version, check your documentation before trying these tricks.

X11 Forwarding

You can encrypt X sessions over SSH. Not only is the traffic encrypted, but the DISPLAY environment variable on the remote system is set properly. So, if you are running X on your local computer, your remote X applications magically appear on your local screen.

Turn on X11 forwarding with ssh -X host. You should use X11 forwarding only for remote computers where you trust the administrators. Otherwise, you open yourself up to X11-based attacks.

A nifty trick using X11 forwarding displays images within an xterm window. Run the web browser w3m with the in-line image extension on the remote machine; see the Debian package w3m-img or the RPM w3m-imgdisplay. It uses X11 forwarding to open a borderless window on top of your xterm. If you read your e-mail remotely using SSH and a text-based client, it then is possible to bring up in-line images over the same xterm window.

Config File

SSH looks for the user config file in ~/.ssh/config. A sample might look like:

ForwardX11 yes
Protocol 2,1
Using ForwardX11 yes is the same as specifying -X on the command line. The Protocol line tells SSH to try SSH2 first and then fall back to SSH1. If you want to use only SSH2, delete the ,1.

The config file can include sections that take effect only for certain remote hosts by using the Host option. Another useful config file option is User, which specifies the remote user name. If you often log in to a machine with ssh -l remoteuser remotehost or ssh remoteuser@remotehost, you can shorten this by placing the following lines in your config file:

Host remotehost
ForwardX11 yes
User remoteuser

Host *
ForwardX11 no
Now, you can type ssh remotehost to log on as user remoteuser with the ForwardX11 option turned on. Otherwise, ForwardX11 is turned off, as recommended above. The asterisk matches all hosts, including hosts already matched in a Host section, but only the first matching option is used. Put specific Host sections before generic sections in your config file.

A system-wide SSH config file, /etc/ssh/ssh_config, also is available. SSH obtains configuration data in the following order: command-line options, user's configuration file and system-wide configuration file. All of the options can be explored by browsing man ssh_config.

Speeding Things Up: Compression and Ciphers

SSH can use gzip compression on any connection. The default compression level is equivalent to approximately 4× compression for text. Compression is a great idea if you are forwarding X sessions on a dial-up or slow network. Turn on compression with ssh -C or put Compression yes in your config file.

Another speed tweak involves changing your encryption cipher. The default cipher on many older systems is triple DES (3DES), which is slower than Blowfish and AES. New versions of OpenSSH default to Blowfish. You can change the cipher to blowfish with ssh -c blowfish.

Cipher changes to your config file depend on whether you are connecting with SSH1 or SSH2. For SSH1, use Cipher blowfish; for SSH2, use:

Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

Port Forwarding

Ports are the numbers representing different services on a server; such as port 80 for HTTP and port 110 for POP3. You can find the list of standard port numbers and their services in /etc/services. SSH can translate transparently all traffic from an arbitrary port on your computer to a remote server running SSH. The traffic then can be forwarded by SSH to an arbitrary port on another server. Why would you want to do this? Two reasons: encryption and tunneled connections.


Many applications use protocols where passwords and data are sent as clear text. These protocols include POP3, IMAP, SMTP and NNTP. SSH can encrypt these connections transparently. Say your e-mail program normally connects to the POP3 port (110) on Also, say you can't SSH directly to, but you have a shell login at You can instruct SSH to encrypt traffic from port 9110 (chosen arbitrarily) on your local computer and send it to port 110 on, using the SSH server at

ssh -L
That is, send local port 9110 to port 110, over an SSH connection to

Then, simply tell your e-mail program to connect to port 9110 on localhost. From there, data is encrypted, transmitted to over the SSH port, then decrypted and passed to over port 110. As a neat side effect, as far as the POP3 dæmon on knows, it is accepting traffic from

Tunneled Connections

SSH can act as a bridge through a firewall whether the firewall is protecting your computer, a remote server or both. All you need is an SSH server exposed to the other side of the firewall. For example, many DSL and cable-modem companies forbid sending e-mail from your own machine over port 25 (SMTP).

Our next example is sending mail to your company's SMTP server through your cable-modem connection. In this example, we use a shell account on the SMTP server, which is named The SSH command is:

ssh -L
Then, tell your mail transport agent to connect to port 9025 on localhost to send mail. This exercise should look quite similar to the last example; we are tunneling from local port 9025 to port 25 over As far as the firewall sees, it is passing normal SSH data on the normal SSH port, 22, between you and

A final example is connecting through an ISP firewall to a mail or news server inside a restricted network. What would this look like? In fact, it would be the same as the first example; can be walled away inside the network, inaccessible to the outside world. All you need is an SSH connection to a server that can see it, such as Is that neat or what?

Limitations/Refinements to Port Forwarding

If a port is reassigned on a computer (the local port in the examples above), every user of that computer sees the reassigned port. If the local system has multiple users, tunnel only from unused, high-numbered ports to avoid confusion. If you want to forward a privileged local port (lower than 1024), you need to do so as root. Forwarding a lower-numbered port might be useful if a program won't let you change its port, such as standard BSD FTP.

By default, a tunneled local port is accessible only to local users and not by remote connection. However, any user can make the tunneled port available remotely by using the -g option. Again, you can do this to privileged ports only if you are root.

Any user who can log in with SSH can expose any port inside a private network to the outside world using port forwarding. As an administrator, if you allow incoming SSH connections, you're really allowing incoming connections of any kind. You can configure the OpenSSH dæmon to refuse port forwarding with AllowTcpForwarding no, but a determined user can forward anyway.

A config file option is available to forward ports; it is called LocalForward. The first port-forwarding example given above could be written as:

Host forwardpop
LocalForward 9110 

This way, if you type ssh forwardpop you receive the same result as in the first example. This example uses the Host command described above and the HostName command, which specifies a real hostname with which to connect.

Finally, a command similar to LocalForward, called RemoteForward, forwards a port from the computer to which you are connected, to your computer. Please read the ssh_config man pages to find out how.

Piping Binary Data to a Remote Shell

Piping works transparently through SSH to remote shells. Consider:

cat myfile | ssh user@desktop lpr

tar -cf - source_dir | 
ssh user@desktop 'cat > dest.tar'

The first example pipes myfile to lpr running on the machine named desktop. The second example creates a tar file and writes it to the terminal (because the tar file name is specified as dash), which is then piped to the machine named desktop and redirected to a file.

Running Remote Shell Commands

With SSH, you don't need to open an interactive shell if you simply want some output from a remote command, such as:

ssh user@host w

This command runs the command w on host as user and displays the result. It can be used to automate commands, such as:

perl -e 'foreach $i (1 .. 12) 
{print `ssh server$i "w"`}'

Notice the back-ticks around the SSH command. This uses Perl to call SSH 12 times, each time running the command w on a different remote host, server1 through server12. In addition, you need to enter your password each time SSH makes a connection. However, read on for a way to eliminate the password requirement without sacrificing security.


How does SSH authenticate that you should be allowed to connect? Here are some options:

The most common authentication method is by password prompt, which is how most SSH installations are run out of the box.

However, public key encryption is worth investigating; it is considerably more secure than passwords, and by using it you can do away with all or most of your password typing.

Briefly, public key encryption relies on two keys: a public key to encrypt, which you don't keep secret, and a private key to decrypt, which is kept private on your local computer. The general idea is to run ssh-keygen to generate your keys. Press Return when it asks you for a passphrase. Then copy your public key to the remote computer's authorized_keys file.

The details depend on whether the computer to which you are connecting uses SSH1 or SSH2. For SSH1 type ssh-keygen -t rsa1, and copy ~/.ssh/ to the end of the file ~/.ssh/authorized_keys on the remote computer. For SSH2, type ssh-keygen -t rsa, and copy ~/.ssh/ to the end of the file ~/.ssh/authorized_keys on the remote computer. This file might be called ~/.ssh/authorized_keys2, depending on your OpenSSH version. If the first one doesn't work, try the second. The payoff is you can log in without typing a password.

You can use a passphrase that keeps the private key secret on your local computer. The passphrase encrypts the private key using 3DES. At no time is your passphrase or any secret information sent over the network. You still have to enter the passphrase when connecting to a remote computer.

Authentication Agent

You might wonder: if we want to use a passphrase, are we stuck back where we started, typing in a passphrase every time we log in? No. Instead, you can use a passphrase, but type it only once instead of every time you use the private key. To set up this passphrase, execute ssh-agent when you first start your session. Then execute ssh-add, which prompts for your passphrase and stores it in memory, not on disk. From then on, all connections authenticating with your private key use the version in memory, and you won't be asked for a password.

Your distribution may be set up to start ssh-agent when you start X. To see if it's already running, enter ssh-add -L. If the agent is not running already, you need to start it, which you can do by adding it to your .bash_login, logging out and logging back in again.

Authentication Agent Forwarding

If you connect from one server to another using public key authentication, you don't need to run an authentication agent on both. SSH automatically can pass any authentication requests coming from other servers, back to the agent running on your own computer. This way, it never passes your secret key to the remote computer; rather, it performs authentication on your computer and sends the results back to the remote computer.

To set up authentication agent forwarding, simply run ssh -A or add the following line to your config file:

ForwardAgent yes

You should use authentication agent forwarding only if you trust the administrators of the remote computer; you risk them using your keys as if they were you. Otherwise, it is quite secure.

Traveling with SSH Java Applet

Many people carry a floppy with PuTTY or another Windows SSH program, in case they need to use an unsecured computer while traveling. This method works if you have the ability to run programs from the floppy drive. You also can download PuTTY from the web site and run it.

Another alternative is putting an SSH Java applet on a web page that you can use from a browser. An excellent Java SSH client is Mindterm, which is free for noncommercial use. You can find it at


An SSH configuration can go wrong in a few places if you are using these various tricks. You can catch many problems by using ssh -v and watching the output. Of course, none of these tricks is essential to using SSH. Eventually, though, you may encounter situations where you're glad you know them. So give a few of them a try.

Daniel R. Allen ( discovered UNIX courtesy of a 1,200-baud modem, a free local dial-up and a guest account at MIT, back when those things existed. He has been an enthusiastic Linux user since 1995. He is president of Prescient Code Solutions, a software consulting company in Kitchener, Ontario and Ithaca, New York.

Re: Eleven SSH Tricks (Score: 0)
by Anonymous on Sunday, January 25, 2004
One trick I use a lot: set up aliases based on your known_hosts file so you get proper hostname completion. Try sticking this in ~/.bashrc:

if [ -f ~/.ssh/known_hosts ] ; then
while read host junk
alias "${host}=ssh ${host}"
done fi


Correction re: Tunnelled Connections (Score: 0)
by Anonymous on Friday, June 04, 2004
I believe I made a mistake in the "Tunnelled Connections" example- In the fourth paragraph, "tell your mail transport agent" should read "tell your mail user agent". In other words, change the settings in your email program.

The other situation, where you're running your own sendmail/postfix/exim and want to send out mail to the world, punching though an ISP firewall, is only possible if you have access to a mail relay running a ssh server to relay all your outgoing email, which is nearly the same as the above situation with a remote SMTP server.

Since there needs to be a server receiving the SSH connection at the other end, you'd otherwise need to figure out how to set up your mail server to establish a SSH connection to every server you emailed to, which isn't possible with regular SMTP.

Perhaps ultimately we should be happy for that, since if a way to transparently send SMTP over SSH were available, most ISPs would then be compelled to block all ports to prevent SSH connections, instead of only blocking SMTP ports to block spammers, and we'd all have yet another reason to hate spammers...

-Daniel Allen

Re: Eleven SSH Tricks (Score: 0)
by Anonymous on Friday, June 04, 2004 In the section Running Remote Shell Commands, perl seems a little overkill for running those consecutive ssh commands. You can replace the little perl code by straight bash:

for i in `seq 1 12`; do ssh server$i "w"; done

Remote backup using ssh, tar and cron by madadmin


Are you looking for a solution to backup your data to a remote location? While a solid backup solution such as Arkeia or TSM from IBM are nice from an enterprise point of view, simpler solutions are available from a home user's perspective. I will walk you through on you how you can backup your data to a remote server, using the default tools available on all linux systems. In a nutshell, we will use ssh capabilities to allow a cron job to transfer a tarball from you local machine to a remote machine.

For the purpose of this tutorial, the local machine will be called "localmachine" (running slackware) and the remote server will be called "remoteserver" (slackware as well). The user will be joe (me). You will have to substitute those 3 with your own machines names and user.

Generating your private/public key pair

To be able to logon to another server without being prompted for your password, you need to generate a key that will be trusted by the remote server, where your backups will be sent to. To accomplish this, follow the following steps as the user you will use (joe here).

You will then be prompted for a file name. Leave it as the default by simply pressing "Enter".

The last step of the key creation is the passphrase. Since the purpose of this is to not enter a password, hence being able to create batch jobs, just hit "Enter" twice, leaving them blank.

This just created 2 files in the user's home directory. ~/.ssh/id_rsa (the private key) and ~/.ssh/
The is your public key, which you share with the remote host. The id_rsa is your private key, and this is only for you. Do not lose it or share it with anyone, as this is your passkey! Make sure the file is not readable by anyone but you (chmod 600 ~/.ssh/id_rsa). Anyone having a copy of this key could usurpate your identity and login to this server as you. It is not any more dangerous to use this method as to use a traditional password, but I will not enter into a debate here.

Now that you have your keyring, it is time to send your public key to the remote machine, so that it can trust you.

Sharing your localmachine public key

First things first, let's make sure that the remote folder into which you will put this key exists (~/.ssh), and will only be readable by you.

This time, it will prompt you for your password. Enter it. If the remote directory didn't exist, everything should go without a hitch. If not you will receive a message like mkdir: cannot create directory `.ssh': File exists., which is fine. The permissions will be changed nevertheless.

Next step is to actually copy your public key in the remote directory, like this:

You should now be able to ssh remotemachine, and not being prompted for a password.

Creating the job to be run by cron

To make it easy, we will create the backup tarball first, then ssh it over to the remote host. Beforehand, let's make sure you have a remote directory where you will put the tarball, accessible to the user running the script. In this case, we will use 'backup' directory under joe's homedir, that you can create like this:

Here is what a shell script ( could look like. This is used to back up a whole home directory.

And this is it! Your tarball is now copied on your remote host. You can go there, check and make sure that the ball untars well, and that permissions were preserved (which they should because of the p switch.)

All that is left is to create a cron job for this user.

Let's say we want to backup every night at 2am.

Save the file, and you're done!


I hope this will help some people to better protect their personal data.
If I can be of any help, you can email me at chapeaurouge_AT_madpenguin_DOT_org. Thanks.

Fred Blaise

Disclaimer: I cannot be held responsible for any data loss due to this HOWTO.

This work is licensed under a
Creative Commons License.

Using ssh LG #61 By Matteo Dell'Omodarme

Starting SSH

There are mainly two different techniques to start sshd at boot time.

Establish a SSH connection

Once sshd is running on your machine you can test your configuration trying to login into it using the ssh client. Let's suppose that you machine is named host1 and your login name is myname. To start a ssh connection use the command:

ssh -l myname host1

In such a way ssh2 client (default client) tries to connect to host1 port 22 (default port). sshd2 daemon, running on host1, catches the request and asks for the myname password. If the password is correct it allows the login and open a shell.

Generating and managing ssh keys

Ssh allows another authentication mechanism, based upon authentication keys, a public key cryptography method. Each user wishing to use ssh with public key authentication must runs ssh-keygen command (without any option) to create authentication keys. The command starts the generation of the keys pair (public and private) and ask for a passphrase in order to protect them.
Two file are created in the $HOME/.ssh2/ directory: id_dsa_1024_a and, the user private and public key.

Let's suppose that we have two accounts, myname1 on host1 and myname2 on host2. We want to login from host1 to host2 using ssh public key authentication. In order to do that four steps are required:

  1. On host1 generate the key pair using ssh-keygen command, and choose a passphrase to protect it.
  2. Login into host2, using ssh password authentication, and repeat the previous operation. Then change directory to $HOME/.ssh2 and create a file, named identification, containing the following lines:
    # identification
    IdKey  id_dsa_1024_a

    This file is used by sshd to identify the key pair to be used during connections.

  3. From host2, get the ssh host1 public key and rename it in a suitable way (e.g.
    ftp host1
    cd .ssh2

    At the end of ftp process a copy of host1 public key, named, resides in host2 $HOME/.ssh2 directory.

  4. Create the file authorization containing the following lines:
    # authorization

    This file lists all trusted ssh public keys placed in $HOME/.ssh2 directory. When a ssh connection is started from a user whom public key matches one of the entry of authorization file the public key authentication scheme starts.

In order to test the previous configuration, you could try to connect from host1 to host2 using ssh. Sshd must reply asking for a passphrase, otherwise, if password is requested, some mistakes occurred in the configuration process and you must check carefully steps 1 to 4.
The passphrase required is your LOCAL passphrase (i.e. passphrase protecting host1 public key).

Tip of the Week: Automated File Synchronization Using rsync and ssh

The tip of the Week describes a procedure to automatically synchronize files using rsync over SSH.

A useful article on the subject to read is: (used as input of the tip)

SSH Access Without Passwords

When a user connects via SSH, he must prove his identity to the remote machine using one of several methods. A common question usually arise: "How can I access a remote host without entering a password at each login?".

SSH provides two solutions to allow remote logins without password rompt: - the first solution uses the /etc/shosts.equiv and .shosts method which is similar to the method using /etc/hosts.equiv and /.rhosts. This

form of authentication should not be allowed because it is not secure.

However this weak authentication method can be combined with RSA-based host authentication where the client's host key is checked with the known_hosts file of the remote machine.

- as second solution, SSH implements the RSA authentication protocol: the user creates his RSA key pair using ssh-keygen. The private key is stored in .ssh/identity and the public key in .ssh/ Both files are

located in the user's home directory. The user can then copy his to .ssh/authorized_keys in his home directory on the remote machine he wants to login to (this could also be the home directory of another user). The authorized_keys file corresponds to the conventional .rhosts file. Then the user is allowed to login to this remote machine without giving any password. RSA authentication is much more secure than classical .shosts authentication method.

In our situation, let's imagine that we have a user backup on a machine called master that needs to login to his account backup on a remote machine called mirror without providing a password for each login. This login without password prompt is necessary to automate the synchronization of a directory.

First, both machine should run SSH (

Then a personal key for master can be generated using ssh-keygen from the command line. The user will be prompted three times during the generation of the keys: once for the name of the output file and twice for the passphrase, just hit enter three times:

backup@master:~ > ssh-keygen Generating RSA keys: Key generation complete

Enter file in which to save the key (/home/backup/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/backup/.ssh/identity Your public key has been saved in /home/backup/.ssh/ The key fingerprint is:

0d:e1:9b:55:88:4d:fa::0c:c3:45:df:82:23:67:d8:57 backup@master

backup@master:~ > During a login, SSH will look for a file named

authorized_keys in the user's .ssh/ directory. This file contains the keys of users allowed to login to this account. Now master must copy the content of to the file .ssh/authorized_keys in the home directory of user backup on the machine mirror. If not present the directory .ssh should be created on the machine mirror:

backup@master:~ > scp .ssh/

backup@mirror:/home/backup/.ssh/authorized_keys backup@mirror's password: 100% *****************************| 329 00:00 backup@master:~ >

The access to authorized_keys must be restricted. Now the user backup on machine master should be able to login to the account backup on machine mirror without being prompted for a password:

backup@master:~ > ssh -l backup mirror Last login: Wed Jul 11 18:38:29 2001

from backup No mail. backup@mirror:~ >

Using rsync over SSH

rsync is a program that can be used in automated scripts to synchronize the content of a directory with the content of another directory. Recent versions of rsync have the capability of tunneling rsync data though SSH.

Now the user can automate the synchronization of a local directory (on master) with a remote directory on mirror. This command line could be used in a script to automate the process:

backup@master:~ > /usr/bin/rsync -r -e ssh /home/backup/test

backup@mirror:~> The options -r allows a recursive synchronization and -e

allows to specify SSH as tunnel. Other rsync options could be used to optimize the transfer.


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: October 01, 2017