Taking Notes from Pro OpenSSH

Taking Notes from Pro OpenSSH

Analysis of Legacy Protocols

Telnet and FTP's first and most apparent security issue is that everything, including authentication credentials, are transmitted in clear-text format over the network, using freely available network sniffers such as Ethereal, you can see every piece of information passed over the network.

Several other network sniffing applications are freely available. In particular, for sniffing on a switched network, Cain & Abel works very nicely, available at http://www.oxid.it/cain.html.

with the emergence of tools such as HUNT (http://lin.fsid.cvut.cz/~kra/) and dsniff (http://www.monkey.org/~dugsong/dsniff/), insertion/session-hijacking attacks can be executed with ease.

A Brief Introduction to SSH

ssh -l user hostname

if a connection is attempted and the host key has not already been cached (trusted), it will print some messages including remote host's key fingerprint.

run the following command on remote host to verify that this is indeed the host it is thought to be.

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

The first time you connect to a host via SSH is very important, as this is a time when a man-in-the-middle attack is possible.When you accept the key (validate the key fingerprint), make sure you are confident the host is the intended target.

Basics of SSH

SSH involves the following pieces of configuration material:

Daemon(and Client) configuration files, Host key(s): Commonly found in /etc/ssh.

Known hosts caching of some kind.

Install OpenSSH

./configure --prefix=/usr --sysconfdir=/etc/ssh --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib/ssh --with-pam --with-tcp-wrappers 2>&1 | tee outputfile

make; make test; make install

Ubuntu SSHD Installation: apt-get install openssh-server openssh-client

Manually Starting and Stopping OpenSSH

/etc/init.d/sshd start; /etc/init.d/ssh start |stop(On Ubutn)

To check whether OpenSSH start: ps -ef | grep sshd | grep -v grep

Client Tools for Windows:WinSCP, PuTTY

PuTTY also provides a command-line-only SCP/SFTP interface.

Configuring OpenSSH

Source-compiled path: /usr/local/etc; Vendor-provided path: /etc/ssh


Each host generates one or more unique keys to identify itself. For using SSH protocol 1, this is the private key using the RSA algorithm. When using SSH protocol 2, the private key file names are ssh_host_rsa_key and ssh_host_dsa_key.


sshd_config: The sshd_config file controls almost every aspect of the SSH daemon.

ssh_known_hosts: OpenSSH caches public keys of known hosts in a file, by default, this is done on a per-user basis.

sshd, ssh-keygen

Source-compiled path: /usr/local/sbin; Vendor-provided path: /usr/sbin

Client Configuration Files


Source-compiled path: /usr/local/etc;Vendor-provided path: /etc/ssh

Path: $HOME/.ssh

identity, id_dsa, id_rsa

If a user decides to use public key authentication, the private key file

is by default named id_dsa or id_rsa for protocol 2. The counterparts to these files are pub files, which are the public key equivalents. These are distributed to remote systems to allow authentication. identity is the name of the user-created SSH protocol 1 private key.


This is the main configuration file for the OpenSSH client software, from the user perspective.

known_hosts: known_hosts is the user’s list of hosts whose public keys were accepted by the user.


The authorized_keys file lists all the public keys for those users who are authorized to assume the user’s identity without a password. By default, with StrictModes enabled, the server will not allow public key authentication if this file is world-readable or writable.


The environment file is responsible for setting environmental values at login. Whether or not this feature is available is determined by sshd_config. If this file is missing or blank, /etc/environment is used.

rc: The rc file lists commands or scripts that are run automatically upon successful login.

.Xauthority: Path: $HOME

OpenSSH has the ability to tunnel X11 sessions to prevent clear-text data transmissions. The .Xauthority file is created or updated upon login if X11Forwarding is enabled for a given session.

agent.<ppid> Path: /tmp

agent.<ppid> is the UNIX domain socket file used to contain the connection to the authentication agent. The authentication agent is software that will store your digital credentials as a form of non-interactive authentication.


The ssh-add executable utility adds, deletes, lists, and locks authentication credentials to the authentication agent software

ssh, scp, sftp


The executable ssh-agent sets up a shell environment that holds private keys to use for public key authentication (RSA or DSA). ssh-agent can be started in the beginning of an X-session, login session, or shell. All other X11 windows or programs are aware of the ssh-agent program, and thus will use ssh-agent to allow public key authentication to occur.

The OpenSSH Server

Checking the Syntax of sshd_config:/usr/sbin/sshd -t -f /etc/ssh/sshd_config_new

sshd -t validates the syntax of the server configuration file

Changing the Default Configuration File and Port

/usr/sbin/sshd -f /etc/ssh/sshd_config_new -p 99; ssh -p 99

Running the OpenSSH Server in Debug Mode

/usr/sbin/sshd -d -p 99 -f /etc/ssh/sshd_config_new

Reloading Configuration Files

To reload an SSH configuration, you can simply run HUP or

kill -1 on the PID. Sending a -1 or HUP signal does not drop any connections currently utilizing the sshd server.

Managing the OpenSSH Server

OpenSSH sshd_config

AllowGroups, AllowUsers, Banner, Compression, PasswordAuthentication, PermitEmptyPasswords, Port, PrintLastLog, Protocol, PubkeyAuthentication,

AuthorizedKeysFile, The default location is $HOME/.ssh/authorized_keys. The file authorized_keys2 is also checked to allow for backward compatibility. On legacy systems, sometimes symbolic links are made between authorized_keys and authorized_keys2


AllowTCPForwarding tells the sshd server whether or not it should allow tunneled connections of other TCP protocols over SSH.


When using forwarding, normally the forwarded connection is only bound to the localhost, because it binds to the loopback address. If gateway ports are specified, remote machines can use a forwarded port on the local system because the forwarded connections bind to all addresses on the machine.


The HostKey directive requires a path to the private host key as an argument. By default, the file /etc/ssh/ssh_host_key is used for protocol 1. The files /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key are used for protocol 2.


The PermitRootLogin directive offers special behavior for the root account outside of AllowUsers and DenyUsers. Root’s login can be controlled using four possible arguments: yes, no, without-password, Forced-commands-only.


The StrictModes directive determines whether sshd should check permissions on the user’s files and home directory before allowing a public key authenticated login.


When forwarding X11 connections, sshd sets the display variable to something like localhost:10.0. If you run more than ten X11 servers on the machine running sshd, increment the X11DisplayOffset variable as needed.

X11DisplayOffset 10


When set to yes, as in the syntax example, X11Forwarding will establish a tunnel for X11 traffic over an SSH connection. This will encrypt X11 traffic and automatically set your $DISPLAY variable.

OpenSSH Client: ssh, scp, and sftp

ssh: ssh user@remoteHost; ssh -l user remoteHost

Remote Commands

ssh stahnke@www uptime; ssh root@rack echo \$PATH

ssh www bash




ssh Acting As a Transport Mechanism

ssh supports secure connectivity between hosts.

dd if=/dev/cdrom |ssh rack dd of=my_cd.iso

This will use the dd command to dump the contents of /dev/cdrom bit by bit to the ssh pipe and then execute dd on the remote host rack to create the ISO file.

Escape Sequences

stahnke@rack:~$ ~?

Supported escape sequences:

~. - terminate connection (and any multiplexed sessions)

~B - send a BREAK to the remote system

~C - open a command line

~R - Request rekey (SSH protocol 2 only)

~^Z - suspend ssh

~# - list forwarded connections

~& - background ssh (when waiting for connections to terminate)

~? - this message

~~ - send the escape character by typing it twice

ssh Command-line Options

-1(Protocol 1), -2(Protocol 2)

-4(-6) will require the ssh client to use IPv4(IPv6) addresses only

-A(ForwardAgent yes), -a(ForwardAgent no)

-b bind_address, -C(Compression yes), -F config_file, -l login_name, -p port, -q(quiet)

-f: ssh -X -f www xterm

If you want to run ssh commands in the background, but also want to require a passphrase or password to do so, the -f option will enable this task.

-g(GatewayPorts yes)

When forwarding connections, normally only the localhost can connect to the forwarded host. If a scenario occurs where the remote host needs to connect to the forwarded connection, you need to use the -g option

-i identity_file,

-L port:host:hostport

When forwarding a connection, the -L option specifies the local (client-side) system is to connect a local port to a remote port over a secured connection.

ssh -L12345:localhost:23 user@www

In another window, I can then telnet to port 12345 on the localhost and end up talking to the telnet server on www, all the while encrypting the traffic.

telnet localhost 12345


When forwarding connections, the -N option can be used so that no remote command is needed.

ssh -f -N -L 12345:localhost:23 www

telnet localhost 12345


This command-line option tells ssh to redirect input from the /dev/null device, thus not allowing stdin to be used. To run ssh in the background, -n is commonly used.

-o option: ssh -o "BatchMode yes" www

Any option allowed in the ssh_config file can be specified on the command line using the -o option. This is useful for options that do not have a dedicated command-line option such as BatchMode.

-R port:host:hostport

When forwarding ports remotely, the -R option is used. Forwarding ports remotely entails specifying a port on the remote system to be forwarded to a port on the local system. To forward the telnet server on www using port 54321 on rack, I can execute the following from www:

ssh -f -N -R54321:www:23 rack

Remote forwarding can also be specified in the ssh_config file. IPv6 syntax is available by using the / character instead of :. RemoteForward 54321 rack:23


If you are having trouble with authentication or configuration issues, verbosity can normally pinpoint what is not behaving as desired.

-X(ForwardX11 yes), -x(ForwardX11 no)


Using Regular Expressions with scp: scp root@www:"/var/log/messages.[1-4]" ./log

File Transfer and Rename: scp root@www:/var/log/messages ~/logs/www_messages

Implied Path

the syntax for scp is user@host:path. if no path is specified (the : is still required), the user’s home directory is assumed to be the path.

Recursive Copy: -r scp -r /code/php/* root@www:/var/www

Local Copy: scp ldap.pl /home/stahnke

Implied User

scp Options

-1, -2, -4,-6, -C(Compression yes), -F config_file,-i identity_file, -o ssh_option, -p port, -q(quiet), -r(recursive)

-B When using scp in scripts or loops, batch mode can be enabled.

-l limit Bandwidth utilization can be limited for scp using the -l option.

sftp: sftp user@remoteHost

Batching sftp Commands

sftp can also be run in a batch mode quite simply. The -b option specifies a batch file.

sftp -b batch_file stahnke@localhost

cat batch_file

cd /var/log

get messages

If the - character is added at the beginning of a line in an sftp batch file, the batch script will continue, even if an error occurs.

sftp Command-line Options

-1, -B buffer_size, -F config_file, -o ssh_option

Interactive Commands

bye, cd path, chgrp GID path, chmod mode path, chown own path,

get [flags] remote-path [local-path]

get can include a -P option to preserve the file permissions and access time from the remote host

lcd path, lls [ls-options [path]], lmkdir path, ln source link, lpwd, ls [flags] [path], mkdir path, put [flags] local-path [remote-path], pwd, rename oldpath newpath, rm path, rmdir path, symlink source link, version,?,exit,quit.

! command Excute local sheel commands


An ! without any arguments will return you to your normal shell. When you exit that shell, you will be returned

to the sftp> prompt.

/etc/ssh/ssh_config: user-specific files are called config: /home/stahnke/.ssh/config.

ssh_config keywords

BatchMode, EscapeChar, ForwardAgent, ForwardX11, IdentityFile, PreferredAuthentications, Protocol, Port, PubkeyAuthentication, SendEnv, UserKnownHostsFile,


Normally, when forwarding a TCP connection, it is bound to the localhost (see the following code example). If having other hosts connecting to the forwarded connection is desired, set GatewayPorts to yes.


the default is /etc/ssh/ssh_known_hosts.


Remote forwarding of TCP traffic can be done via SSH. To specify a remote forward, use the RemoteForward keyword


Public Key Authentication asymmetric encryption algorithm

Using the -v Option to Determine If the Remote Server Allows Public Authentication

ssh -v www

debug1: Authentications that can continue: publickey,password

debug1: Next authentication method: publickey

Ensuring the Client Allows Public Key Authentication


PreferredAuthentications publickey,keyboard-interactive,password

PubkeyAuthentication yes

Setting Up Public Key Authentication

Setting up public key authentication involves generating a key pair for a user, installing the public key on remote host(s), and ensuring permissions and ownership of the key files are correct.

Generating Your Key Pair

ssh-keygen -t rsa -b 1024

It is considered best practice to have a passphrase on private keys. Once key pair has been generated, the private key file is stored in ~/.ssh/id_rsa. The public counterpart is at ~/.ssh/id_rsa.pub.

Installing a Public Key on a Remote Host(s)

scp /home/stahnke/.ssh/id_rsa.pub stahnke@www:.ssh/public_key

ssh stahnke@www "cat /home/stahnke/.ssh/public_key >> /home/stahnke/.ssh/authorized_keys"

These can be siplified into one command:

ssh user@remote_host cat < $HOME/.ssh/id_rsa.pub ">>" .ssh/authorized_keys

The authorized_keys File

To install your public key on a remote host, simply use scp to copy the public key file over to your remote systems and place the contents in a $HOME/.ssh/authorized_keys file. The authorized keys file consists of public keys, one per line.

The $HOME/.ssh directory should have the most restrictive permissions possible. Owner-controlled directories are best (700). $HOME/.ssh/authorized_keys files are a target for attackers, so watch them carefully.

In older implementations of OpenSSH, the authorized_keys file designed for protocol 2 was called authorized_keys2. This file is still consulted for backward compatibility, but it has been deprecated. Therefore, authorized_keys (without the 2) should be used to store public keys for users.

Troubleshooting Public Key Authentication

Invalid authorized_keys Entry

Password Expiry

File Ownership and Permissions

Public Key Restrictions

The public keys created for OpenSSH offer additional security and restrictions by using one or more keywords at the beginning of the public key specified in the authorized_keys file. Restrictions can limit source nodes, limit commands, or allow restrictions on agent forwarding.

The format for keyword restrictions requires that they be placed before the main text of the key. Multiple options are comma delimited, and white space is not permitted unless it is in double quotes.

Source Restriction: from

As an additional method of access control, in an authorized_keys file, a source host can be specified, which will only enable public key authentication from specific hostnames or IP addresses. Simple regular expressions using an * or a ? are permitted, The from restriction can deny specified hosts using the ! operator.

from="rack,!*.badguy.com" ssh-rsa ....

Command Restriction: command

Restricting the commands a key can perform is also permitted inside of an authorized_keys file.

command="/usr/bin/uptime" ssh-rsa ...

Environment Restriction: environment

Port Forwarding Restriction: no-port-forwarding

To disable port forwarding, the no-port-forwarding option should be used in the authorized_keys file.

command="/usr/bin/uptime",no-port-forwarding ssh-rsa ...

X11 Forwarding Restriction: no-X11-forwarding

Agent Forwarding Restriction: no-agent-forwarding

TTY Restriction: no-pty

authorized_keys files are valuable targets for attackers and users looking to somehow escalate privilege.

Key Generation Information

-l: The -l option will list the fingerprint (md5 checksum) of the public key file.

-p: The -p option allows the user to change the passphrase on a private key file.

ssh-keygen -p -f id_rsa

-q(quiet), -C comment

-t type: The -t option specifies the type of key to generate.

-y: The -y option will regenerate the public key when provided with a private key. This can be useful if the public key was accidentally deleted or overwritten.

ssh-keygen -y -f /home/stahnke/.ssh/id_rsa

-N new passphrase

When generating a key, the passphrase can also be specified on the command line. This can be done using the -N option: ssh-keygen -N "My New Passphrase" -t dsa

-P passphrase

The -P option specifies the old passphrase on the command line. When used in conjunction with -p and -N, it is possible to change a passphrase in a noninteractive mode.

ssh-keygen -p -N "newphrase" -P "oldphrase" -f ~/.ssh/id_dsa

-R: ssh-keygen -R rack

Running ssh-keygen -R with a hostname as an argument will remove a hostname from a user’s $HOME/.ssh/known_hosts file.

SSH Agents

The concept behind an ssh-agent is that you store your identity (authentication information) at the beginning of a session, and then when remote connections are being established, they consult the agent behind the scenes. The program ssh-agent sets up a socket that stores authentication information normally in /tmp, and sets up some environment variables to make the ssh client and shell aware of the socket’s existence.


After an ssh-agent is created, a private key must be loaded into the agent. ssh-add with no argument will load private

keys from the default locations of $HOME/.ssh/id_dsa and $HOME/.ssh/id_rsa for protocol 2 and $HOME/.ssh/identity for protocol 1. If other names are used for private keys, they must be specified as arguments.

ssh-agent Hints

On systems that contain my private key(s), I normally start ssh-agent during login script execution. This traditionally involves modifying a .profile or .bashrc file by including the line eval `ssh-agent` in the file. This process also requires the use of ssh-agent -k in a .logout or .bash_logout file. When I am going to use an X session or an X11 program like Konsole, I run ssh-agent start-kde or ssh-agent konsole from the command line. This invokes the X11 application inside of ssh-agent, so every process spawned from it is aware of the ssh-agent.


-k: ssh-agent -k

The -k option will kill the agent defined in the $SSH_AGENT_PID environment variable


-l: The -l option will list the fingerprints of the keys currently loaded into the agent.

-d: remove a key

If only one identity is present, there is no need to specify which key file to remove from the agent.

-D:To remove all keys from the agent

-x: ssh-add -x

When walking away from the terminal or workstation with your loaded agents, it is best practice to lock it. This will prevent other users from using your agent to authenticate onto remote systems.

-X:To unlock a locked agent

Agent Forwarding

ssh-agent forwarding relies on configurations in both the client and server configuration files. If enabled, a user can make multiple ssh connection hops without returning to the server on which his or her private key resides.

Agent forwarding requires that the same public key be installed oneach host.

In the client configuration, add the following line to config or ssh_config to enable agent forwarding:ForwardAgent yes

A Quick Reference to Authentication

Reference: Setting Up User Public Key Authentication

1. Generate a key with a good passphrase: ssh-keygen –t dsa –b 1024

2. Install a public key file:

ssh user@remote_host cat < $HOME/.ssh/id_rsa.pub ">>" .ssh/authorized_keys

TCP Forwarding

OpenSSH offers an advanced set of features that allow users and administrators to forward, or tunnel, otherwise insecure protocols inside a secure SSH connection. Forwarding protocols inside of SSH uses TCP forwarding.

In addition to providing the obvious advantages such as encryption and strong authentication, SSH can forward many of these weaker protocols in a transparent manner, allowing users to continue using their otherwise insecure applications in the typical manner while at the same time capitalizing on these secure features.

For encryption of FTP data traffic, use vsftpd(http://vsftpd.beasts.org/) with OpenSSL support.

Port Investigation: lsof and netstat

netstat -an | grep LISTEN

As an alternative, you can always use the Network Mapper, known as nmap

TCP Connection Forwarding

Setting Up the Tunnel

Ensure that TCP forwarding is allowed by the remote system, in sshd_config, set AllowTcpForwarding to yes: AllowTcpForwarding yes

ssh -L<local port>:<local system>:<remote port> <remote system>

stahnke@rack: ~> ssh -L12345:localhost:23 www

Using this set of options, I am logged in to remote server www.

This tunnel will stay open as long as this session to www stays alive.

This configuration of forwarding will kill the forwarding

mechanism when the initial session is closed. To avoid this, you can specify the -N option with your ssh command. -N does not execute remote commands and allows port forwarding with SSH protocol 2 only. The -f tells ssh to fork a new process, therefore you get to keep your terminal session on the host you started.

stahnke@rack: ~> ssh -f -N -L12345:localhost:23 www

If you have a need to allow other systems to connect to the forwarded port, you can specify a -g option. The -g option enables gateway ports, which basically means binding to all addresses and not just the loopback. You can also specify this in your sshd_config file with the following directive:

GatewayPorts yes

Tunnel Setup via ssh Client Escape Sequence

stahnke@www: ~> ~C

ssh> -L12345:localhost:23

VNC: http://www.realvnc.com

By default, VNC listens on port 5900.and VNC is clear-text protocol, so it is one of the most common applications tunneled through SSH.

stahnke@rack: ~> ssh -L 5900:localhost:5901 www

Normally, to use VNC, you run something like this:

stahnke@rack: ~> vncviewer www:0

Instead, now that I have forwarded the port, I can run vncviewer on the localhost and have encrypted connections.

stahnke@rack: ~> vncviewer localhost:0

Tunneling Through Firewalls

OpenSSH can help you tunnel various forms of TCP traffic though that firewall using port 22.

Pass-through Forwarding

Many firewalls allow SSH connections to pass through.

stahnke@ringo: ~> ssh -L12345:john:389 paul

This command run from ringo will set up a tunnel starting at ringo, ending at john, and having paul in the middle. When you nmap the systems, both ringo and paul will have port 12345 open.

Remote Forwarding: -R

stahnke@www: ~> ssh -R12345:www:23 rack

I must be on rack and telnet to the localhost on port 12345 to be forwarded to www’s telnet server. The only difference is that I set up the forwarding remotely.

Creating Forwarded Connection via $HOME/.ssh/config

LocalForward 12345 www:143

Remote forwarding can be done using very similar syntax:

RemoteForward 12345 rack:143

Forwarding Collisions: -o ClearAllForwardings=yes

Host www

Localforward 12345 www:389

Normally, this would forward port 389 on www to my localhost port 12345. if I connect to www in multiple terminal windows simultaneously, An error is produced because each connection attempts to create the tunnel on port 12345

If ClearAllForwardings option is enabled. ssh client will not attempt to create the locally forwarded tunnel, even though the $HOME/.ssh/config file requests it.

Dynamic Forwarding

Using standard TCP forwarding, the connection ports are explicitly defined. With dynamic forwarding, the SSH client acts as a SOCKS proxy server, which means that the remote application will negotiate which ports to open, with the SSH client acting as a SOCKS server. Client applications using dynamic forwarding must be SOCKS aware.

First, you must ensure the remote sshd server allows TCP forwarding. After that, you establish a connection to the remote system and set up the dynamic forward tunnel:

stahnma@lan_host: ~> ssh -D 1080 external_host

This creates a dynamically forwarded connection on port 1080 of the localhost.

The next step is to configure your browser on the LAN host to use the SOCKS connection at localhost port 1080. Start by bringing up the Preferences dialog box and clicking the Connection Settings button. Inside the Connection Settings dialog box, select Manual proxy configuration, and fill in the appropriate host and port values.

X11 Forwarding

X11 has its advantages over other display techniques because it was designed to be network transparent, which means users running an X server on their desktop can receive windows from other hosts. This is useful when you need to run a Graphical User Interface (GUI) utility or application from a remote system.

A Primer in the X11 Windowing System

X11, as is SSH, is a client/server network application. A user running an X desktop or X server can view X protocol traffic sent to his or her desktop. In the case of X, the clients are the programs, such as the Firefox browser, xterm, and xclock. The server portion services the requests of the X clients and draws material on the screen.

X11 calls for a DISPLAY variable to be set. While many applications allow the display to be specified dynamically, almost without exception, users set DISPLAY upon login and never think about it again. The DISPLAY variable is composed of the following components:

<hostname>:<display number>:<visual number>

The display number component determines the identifying number of the destination X server. Most of the time, a system is only running a single X server; however, if you are running more than one, you should set this component accordingly. The visual number component determines the screen inside of the specified X server. display number and visual display number both start at zero.

stahnke@www: ~> export DISPLAY=rack:0.0

The X server also can perform some access control over what hosts can be an X client. This is done by the command xhost. The xhost command allows you to specify what hosts are either allowed or denied connection rights.

stahnma@rack: ~> xhost +www

To remove www from the access list, aminus sign is used. Many people run an X server with xhost +, meaning all X clients are allowed.

Making OpenSSH Work with X11

Inside sshd_config

X11Forwarding yes • X11DisplayOffset 10 • X11UseLocalhost yes

Inside ssh_config

ForwardX11 yes • ForwardX11Trusted no

Scripting with OpenSSH


To effectively script tasks involving SSH, authentication must be automated. Through the use of an ssh-agent, a key without a passphrase, or a keychain (which also uses ssh-agent), this is easy to accomplish


Redirection and Pipes

ssh root@www uptime > file

keep the file remotely:

ssh root@www "uptime > file"; ssh root@www "cat file"

determine whether two files differ on different systems.

cat /etc/bashrc | ssh root@www diff - /etc/bashrc

dd bs=2048 if=/dev/cdrom | ssh root@www dd of=my_cd.iso

ssh root@www "cat $myfile | awk -F: '{print \$1}'"

Scripting Using a “Here Document”

for system in `cat list`


echo "${system}"

ssh root@${system} /bin/sh <<\EOD

for user in `cut -f1 -d: /etc/passwd`; do

homedir=`grep ^\$user: /etc/passwd | cut -d: -f6`

space=`[ -d $homedir ] && cd $homedir && du -sh . | cut -f1`

echo $user $homedir $space




Locally Run Script

for system in `cat list`


echo $system

ssh $system /bin/sh < disk_check.sh


Post a Comment


Java (159) Lucene-Solr (110) All (60) Interview (59) J2SE (53) Algorithm (37) Eclipse (35) Soft Skills (35) Code Example (31) Linux (26) JavaScript (23) Spring (22) Windows (22) Web Development (20) Tools (19) Nutch2 (18) Bugs (17) Debug (15) Defects (14) Text Mining (14) J2EE (13) Network (13) PowerShell (11) Chrome (9) Continuous Integration (9) How to (9) Learning code (9) Performance (9) UIMA (9) html (9) Design (8) Dynamic Languages (8) Http Client (8) Maven (8) Security (8) Trouble Shooting (8) bat (8) blogger (8) Big Data (7) Google (7) Guava (7) JSON (7) Problem Solving (7) ANT (6) Coding Skills (6) Database (6) Scala (6) Shell (6) css (6) Algorithm Series (5) Cache (5) IDE (5) Lesson Learned (5) Miscs (5) Programmer Skills (5) System Design (5) Tips (5) adsense (5) xml (5) AIX (4) Code Quality (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) OpenNLP (4) Project Managment (4) Python (4) Spark (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Become a Better You (3) Concurrency (3) Eclipse RCP (3) English (3) Firefox (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Distributed (2) Fiddler (2) Google Drive (2) Gson (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Life (2) Logging (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Bit Operation (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Mac (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) Review (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Troubleshooting (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts