Linux – SSH Config setting default user for multiple hosts under the same domain + aliases

linuxssh

This thread: In your ssh config is it possible to have one host entry for multiple machines on the same domain explained the 'aliases' part of my question, I was wondering if it's possible to set default username AS well as use domain aliases, so I can simply have to write something like:

ssh subdomain

I have the following in my /etc/resolv.conf file:

search my_cool_domain.com

and the following in my ssh_config file:

Host *.my_cool_domain.com
    User deploy

So I figured the following will work:

ssh subdomain

will try to connect to subdomain.my_cool_domain.com with user deploy but this does not work for some reason.

Although the following:

ssh deploy@subdomain does work, as well as:
ssh subdomain.my_cool_domain.com

Any idea how can I fix this (If it's even possible) in an elegant way?

Best Answer

The patterns after the keyword "Host" are not resolved in anyway to real host names, so you cannot detect that a subdomain that your dns lookup is configured for it actually a subdomain of your main domain.

From the ssh_config manpage -

         ... The host is the hostname argument given on the command line (i.e. the
         name is not converted to a canonicalized host name before match-
         ing).

Your alternative is to, either

Use "Host *" and set the default username for all hosts.
When/if you have some kinds of prefixes to your subdomains, use "Host pfx1* pfx2*".
Configure your shell completion and always use full host names, "Host *.mydomain" and "ssh subdomain" that completes it to "ssh subdomain.mydomain".
Shell aliases and function can also be used to add the ".mydomain" part automagically. For example, "ssh-alias subdomain" that is an alias for "ssh subdomain.mydomain".

METHOD 1 (use ssh-key on inter)

If you want to retain the authentication flow

local -- authenticate --> inter -- authenticate (ask password) --> final

This cannot be done with .ssh/config proxyhost.

What you need is bash shell alias (I hope you are using bash).

In ~/.bashrc, add following line

alias ssh-final='ssh -t inter ssh user2@final.com'

In command prompt, just type following

ssh-final

final section in ~/.ssh/config is not used.

Connection Details(1)

ssh -t inter ssh user2@final.com can be view as follow

local# ssh inter
inter# ssh user2@final.com

local is only "talking" to inter. There is no direct or indirect ssh connection between local and final. local is just displaying the output of ssh user2@final.com.

METHOD 2 (use ssh-key on local)

Authentication with same ssh-key

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Copy local ~/.ssh/id_ras.pub to

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Connection Details(2)

ssh tunneling

Before we go into detail of ProxyCommand, lets look at the following example

Step 1, on terminal window 1

local# ssh inter -L 2000:final.com:22

Step 2, on terminal window 2

local# ssh localhost -p 2000

In terminal 1, a tunnel is setup between local port 2000 and final.com port 22. Anything sent to local port 2000 will be forward to final.com port 22 and vice versa.

In terminal 2, ssh connect to local port 2000, but actually is communicating with final.com port 22, which is the sshd.

With tunneling, local ssh client in Step 2 is connected with final.com sshd directly.

The "output" of local port 2000, is "raw" ssh daemon traffic.

Common usage of such tunnel is to access internal web server or email server. Following is example for web server

local# ssh inter -L 2000:final.com:80

In the browser use following URL

http://localhost:2000

The two end points of the tunnel are local port 2000, and final.com port 80.

Traffic coming in and out of tunnel end point "AS IS". Lets call that "raw" traffic.

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

The ProxyCommand take it one step further. It skip the step of creating a local port and connect to it.

A ssh client will execute what ever command given behind ProxyCommand, and treat the output of that command as "raw" traffic. It is holding onto the local end point, and then start a ssh connection with it.

Why one work the other does not?

The following command

ssh inter nc final.com 22

basically means (1) connect to inter, then (2) on inter, run command nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

So nc final.com 22 will connect to final.com port 22, print out all incoming traffic to stdout, and send all stdin to the other side. It is a "tunnel" between nc stdin/out and final.com port 22.

Since nc is ran within the ssh session, all its stdout is passes back to the ssh client, as "raw" traffic. And the ssh client can pass traffic into nc stdin, which will end up at final.com port 22.

Through the above "tunnel", local ssh client will start a ssh session with final.com directly.

The following command

ssh -t inter ssh user2@final.com

does not work with ProxyCommand because the out of it is not "raw" traffic from a ssh daemon. It is the stdout of a ssh client. Client talk to client means no business.

Authentication with different ssh-key (OP original config)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Copy local ~/.ssh/id_ras.pub to

/home/user1/.ssh/authorized_keys in `inter`

Copy local ~/.ssh/id_ras_2.pub to

/home/user2/.ssh/authorized_keys in `final`

Both of the above will enable the following usage

local# ssh final

Additional Checking

Use verbose

local# ssh -v final

That should help identifying ssh problem.

Check nc

ProxcyCommand is executing nc on inter. Check if nc is actually available on inter.

local# ssh inter
inter# nc final.com 22

Check rsa key is setup properly

If different keys are to be used for inter and final, following files should exist in local machine

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Since you can ssh to inter already, check key setup on final. From your local machine

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

You should see content of id_rsa_2.pub there.