Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I will be helping set up a bunch (>50) machines that are distributed geographically and across different networks. Thus, a priori, I will not be able to know what the IP address is of each of the machine. I will be able to add any software to the machines before they are deployed. The main thing is that I need to be able to ssh into each of them to update them from time to time after they have been deployed.

Is there a software package that will help me wrangle all of these machines? Is there a way for me to set up something that will allow them to "phone home" every so often and track their IP addresses? Is there a word I can Google for that will help to solve this problem?

share|improve this question
    
puppet –  Michael Hampton Oct 5 '12 at 4:02
2  
puppet and/or a VPN that connects into your network. –  Zoredache Oct 5 '12 at 4:02
    
@Zoredache can you expand a little on the setting up a VPN? It sounds interesting –  Scoop Oct 5 '12 at 6:51
    
Not in a comment no. There are already lots of questions about using a VPN here in SF. My personal preferences is OpenVPN. –  Zoredache Oct 5 '12 at 7:17

4 Answers 4

up vote 3 down vote accepted

This is exactly the sort of thing the DNS is good at, and IP addresses aren't. If you have each of the hosts set up to have an individual hostname, and to make a dynamic DNS update to a central server each time it connects to the network, then you'll always be able to ssh to (eg) server43.dynamic.example.com.

As you can tell from the example above, if you do this I'd recommend delegating a subzone for these dynamic hosts, to avoid anyone contaminating your main DNS.

Edit: first, you pick your domain. Let's assume you can get a subdomain off your main corporate one, let's say sub.example.com.

Then you get some DNS servers; two is a good number. Maybe you can piggyback on your corporate servers, maybe you have to get a couple of VPSes or rent NS hosting off someone with clue. You get your corporate DNS guys to delegate sub.example.com to those servers.

Then you configure all those client boxes to perform DDNS updates in that subdomain, to those nameservers. You set them all up with valid secrets to do TSIG updates, and you set the main servers to accept dynamic updates, but only when properly signed.

When a client comes online, say client33, it does an DDNS update for client33.sub.example.com as described above. Your central propagating box can at any time ssh to client33.sub.example.com knowing that the address will be up-to-date.

share|improve this answer
    
interesting, I'm still trying to wrap my head around how to do this. How do I set up a DNS with different computers to be in the same some domain? And how do I get the IP addresses of each of the computers initially? –  Scoop Oct 5 '12 at 6:49
1  
DNS, is a good idea, but you are kind of assuming the hosts will have a public address and be outside the firewall. –  Zoredache Oct 5 '12 at 7:14
    
Not at all; I'm merely assuming that both clients and servers have access to a usable DNS server. Since all are under his control, it's not too much of a stretch to assume either that one is available or can be easily provided; if it means putting one on the public internet and enabling eg TSIG updates to prevent malicious updating, that's not crazily complex. But you're dead right to note that infrastructure will be required. You're also right to note that I'm assuming a public IP address; but the OP is doing that in the question. –  MadHatter Oct 5 '12 at 10:22
1  
Following that idea, you can create a couple of DNS entries in dyndns.com and access the machines like blahblah1.dyndns.com. You can have a script giving report to dyndns for the new ip every N minutes/hours/whatever. You can find many examples in google –  Nikolaidis Fotis Oct 5 '12 at 12:18
    
That works, too! –  MadHatter Oct 5 '12 at 14:11

You can use SSH reverse tunnel. An example:

http://abechik.wordpress.com/2007/04/18/persistant-ssh-reverse-tunnel-connection/

For each client use a different port so you would connect using:

ssh localhost -p <client_port>
share|improve this answer
    
I like this idea. Very interesting! What would be the difference between doing this and setting up a VPN for everything to connect to? I read that "ssh is a poor mans VPN" but I'm still trying to wrap my head around everything and getting your opinion would be helpful and appreciated. –  Scoop Oct 5 '12 at 17:09

puppet might do the trick for you, however a homegrown solution might include:

creating an account on your central server (ideally chroot jail'ed) and set up an SSH key. Distribute the private key to all of the clients, and set them up to SSH to the central server using that key in cron:

ssh -i /home/user/.ssh/id_rsa_key_for_central_server user@centralserver "echo hostname is at $ipaddress >> sometracking.file"

share|improve this answer
    
would setting up a VPN work? –  Scoop Oct 5 '12 at 6:50
    
Security issue: all clients would have the same SSH key. Let puppet (or any other software) generate a new, different one for each client and, maybe, add the server's one to the "known hosts". Ah, no need for a VPN here. –  S19N Oct 17 '12 at 12:50

You can phone home a really simple ssh key solution.

Setup a technical user on each of the remote hosts before it gets deployed.

These users have a keypair (ssh-genkey), public key added to the authorized hosts on your home server. On the top of that you need to setup a cronjob which tries to login once an hour to the home server and register it's IP address.

How about that?

share|improve this answer
    
would setting up a VPN work? –  Scoop Oct 5 '12 at 6:50
    
Sure, there is no conflict with VPN, depends which IP address you want to save, you can safe all. –  Istvan Oct 7 '12 at 5:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.