Warning
the permissions setting is crucial, without this the passwordless connection fails, with no error message the keys are just silently ignored
Remember to kill the agent if a prior one is running:
source> ssh--keygen
A passphrase will be promted for twice, and key pairs created at:
~/.ssh/id_rsa
~/.ssh/id_dsa
~/.ssh/id_rsa.pub
~/.ssh/id_dsa.pub
If you have password access to the target:
source> ssh--putkey target
Otherwise copy/paste or attach the public .pub keys to an email and send to administrator of target machine.
Start the agent and give it the keys on the source machine, the passphrase used at key creation will be prompted for
source> ssh--agent-start
For debugging or to avoid running a “forced” command (eg from gateway to internal node) it is sometimes useful to revert to password authentication. Do so with:
source> ssh -o PubkeyAuthentication=no VT
This setting can be persisted in the config file under a new host name (add to ~/.ssh-local-config then sshconf-gen if using sshconf-)
host VTN
hostname gateway.domain
protocol 2
PubkeyAuthentication no
Passwordless ssh requires the ssh-agent to be running and authenticates and some envvars to identify the agent.
[blyth@belle7 ~]$ env -i SSH_AUTH_SOCK=/tmp/ssh-pXBvj24135/agent.24135 SSH_AGENT_PID=24136 ssh N1 hostname
belle1.nuu.edu.tw
[blyth@belle7 ~]$ env -i SSH_AUTH_SOCK=/tmp/ssh-pXBvj24135/agent.24135 ssh N1 hostname
belle1.nuu.edu.tw
[blyth@belle7 ~]$ env -i ssh N1 hostname
Enter passphrase for key '/home/blyth/.ssh/id_dsa':
[blyth@belle7 ~]$ cat .ssh-agent-info-N
SSH_AUTH_SOCK=/tmp/ssh-pXBvj24135/agent.24135; export SSH_AUTH_SOCK;
SSH_AGENT_PID=24136; export SSH_AGENT_PID;
#echo Agent pid 24136;
ssh works via client-daemon with config files for both client (man ssh_config) and daemon (man sshd_config) on both the nodes you are connecting
All 4 config files need to be reviewed and have:
scp ~/Downloads/id_dsa.pub C:.ssh/dybdb1.id_dsa.pub
scp ~/Downloads/id_rsa.pub C:.ssh/dybdb1.id_rsa.pub
C > cd .ssh ; cat dybdb1.id_dsa.pub dybdb1.id_rsa.pub >> authorized_keys2
NB this can be automated with ssh–putkey when you have control of both ends
sudo vi ~dayabayscp/.ssh/authorized_keys2
sudo bash -c "cat dybdb1.* >> ~dayabayscp/.ssh/authorized_keys2"
The problem: a remote node K is running a web server that you wish to test from your laptop but the remote node is not web accessible. How can you conveniently check webserver responses from browsers or commandlines on your laptop ?
Start the tunnel on laptop. The process goes to background so the terminal session can be closed without stopping the tunnel process:
simon:~ blyth$ ssh--
simon:~ blyth$ ssh--tunnel K 9090
-D Specifies a local dynamic'' application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address.
-N no remote command, just forward
-f go to background
kill the process to stop the tunnel
opening tunnel with command ... ssh -fND localhost:9090 K
Alternatively without the ssh–tunnel bash function can just directly do:
ssh -fND localhost:9090 K
Check the tunnel process:
simon:e blyth$ ps aux | grep localhost:9090
blyth 20464 0.0 0.0 77864 488 ?? Ss 12:43pm 0:00.01 ssh -fND localhost:9090 K
Warning
This ties up localhost:9090 so attempting to connect a local server instance on port 9090 at the same time as the tunnel is running fails
Because the request is not going via the local 9090 port setup:
simon:~ blyth$ curl http://130.87.106.59:9090/servlet/db/
^C
Some commandline tools support routing requests via the SOCKS proxy:
simon:~ blyth$ curl --socks5 localhost:9090 http://130.87.106.59:9090/servlet/db/
<exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist">
<exist:collection name="/db" owner="admin" group="dba" permissions="rwurwurwu">
<exist:collection name="test" created="Jun 20, 2013 08:56:20" owner="guest" group="guest" permissions="rwur-ur-u"/>
<exist:collection name="hfagc_tags" created="Jun 20, 2013 08:56:20" owner="admin" group="dba" permissions="rwur-ur-u"/>
<exist:collection name="hfagc" created="Jun 20, 2013 08:56:14" owner="admin" group="dba" permissions="rwur-ur-u"/>
</exist:collection>
</exist:result>
That is equivalent to ssh-ing into the remote node and running the query locally:
b2mc:~ heprez$ curl http://130.87.106.59:9090/servlet/db/
<exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist">
<exist:collection name="/db" owner="admin" group="dba" permissions="rwurwurwu">
<exist:collection name="test" created="Jun 20, 2013 08:56:20" owner="guest" group="guest" permissions="rwur-ur-u"/>
<exist:collection name="hfagc_tags" created="Jun 20, 2013 08:56:20" owner="admin" group="dba" permissions="rwur-ur-u"/>
<exist:collection name="hfagc" created="Jun 20, 2013 08:56:14" owner="admin" group="dba" permissions="rwur-ur-u"/>
</exist:collection>
</exist:result>
Add an if section to the ~/env/proxy/socks.pac file corresponding to the URL want to check:
function FindProxyForURL(url, host) {
...
if (url.substring(0,25) == "http://130.87.106.59:9090" ){
return "SOCKS 127.0.0.1:9090" ;
}
...
return "DIRECT" ;
}
Warning
experience suggests it is more reliable to use IP addresses rather than names
NB this will stop working when the session establishing the tunnel is closed
Check the tunnel process:
simon:e blyth$ ps aux | grep localhost:9090
blyth 20464 0.0 0.0 77864 488 ?? Ss 12:43pm 0:00.01 ssh -fND localhost:9090 K
After killing the tunnel process, curl responds with connection fails almost instantaneously:
simon:e blyth$ kill -9 20464
simon:e blyth$ curl --socks5 localhost:9090 http://130.87.106.59:9090/servlet/db/
curl: (7) couldnt connect to host
simon:proxy blyth$
Similarly Safari says “Contacting 130.87.106.59” and after a minute or so gives an error page:
Safari cant open the page.
Safari cant open the page http://130.87.106.59:9090/xmldb/db/test/ because the server where this page is located isnt responding.
Starting another tunnel immediately gives curl and Safari access again.
Receive keys as copy/pastes within email on Mac laptop. Paste em into files and scp over to target:
simon:~ blyth$ pbpaste > D2.id_rsa.pub
simon:~ blyth$ pbpaste > D2.id_dsa.pub
simon:~ blyth$ scp D2* C:
[blyth@cms01 ~]$ sudo bash -c "cat D2* >> ~dayabayscp/.ssh/authorized_keys2 "
[blyth@cms01 ~]$ sudo vi /home/dayabayscp/.ssh/authorized_keys2 # manually added some new lines
tunnel remote port onto local machine ... remember you will probably also need to edit ~/e/proxy/socks.pac and reload it in Firefox > Preferences >
An issue with this is that privileged ports can only be forwarded by root, but the nodes that would want to tunnel to usually would have password access switched off so that means would have to setup ssh keys for root.
So probably easier to prick holes in the iptables for specific ips while testing
list keys in local authorized_keys2
the entries indicate nodes/accounts from which this one can be accessed via ssh key. These should be kept to the minimum needed
Warning
not yet operational
When using a hub node which is backed up to multiple backup nodes, there can be quite a few keys to juggle.
Grabs the designated key, is not already present and distributes it to the backup nodes that need it.
This needs to be rerun after changing backup tags or designated server OR can be re-run just to check the keys are inplace
ssh–rmkey <type> <name> <node>
delete keys from local authorized_keys2 things that fit into a perlre can be used ie:
ssh--rmkey ".*" ".*" "pal.nuu.edu.tw" ssh--rmkey "..." "blyth" "al14" ssh--rmkey ".*" "blyth" "C2"
This is useful to extend access to a node that accepts login only via key to a new node, via transferring the nodes key via a node that already has keyed access.:
cd /tmp ; scp N:.ssh/id_rsa.pub id_rsa.pub ## grab the key of the new node
ssh--addkey H id_rsa.pub ## append it on the target
rm id_rsa.pub
Copy the key from remote node and store at the specified path, the form of the basename must follow the naming convention in order to identify which node to get it from and which type of key to get. eg:
ssh--grab-key $HOME/.ssh/YY.id_rsa.pub # grab remote key YY:.ssh/id_rsa.pub
resolved by uninstall/reinstall : but git was a casualty
simon:~ blyth$ sudo port uninstall openssh @5.5p1_2
---> Unable to uninstall openssh @5.5p1_2, the following ports depend on it:
---> git-core @1.6.3.1_0+doc+svn
---> git-core @1.7.2.2_0+doc
Error: port uninstall failed: Please uninstall the ports that depend on openssh first.
simon:~ blyth$
In /etc/sshd_config you might want to uncomment the lines:
PasswordAuthentication no
PermitEmptyPasswords no
Also, you want to make sure you have:
RSAAuthentication yes
PubkeyAuthentication yes
After this is done, you need to restart the ssh daemon. This is done in OSX with the following commands:
sudo launchctl stop com.openssh.sshd
sudo launchctl start com.openssh.sshd