I currently have an AlarmPI (Arch Linux) but no screen apart from a crappy projector from which can't read the tty.

I have managed to ssh into it by guessing the IP address (it is currently connected via Ethernet to the router) but I would like to make sure I have access to it after a reboot.

I have a laptop acting as an SSH server configured so that all users on the Raspberry can do passwordless login to it.

Hence, from the Pi I can do:

scp file [email protected]:/home/user/

with no problem.

I created a systemd service on the raspi

# vim /etc/systemd/system/getip.service
Description=Dump ifconfig into a file and scp it to laptop 



and enabled it

# systemctl enable getip.service

The script is as follow


ifconfig >  /home/alarm/raspi_ip
arp -a   >> /home/alarm/raspi_ip
scp /home/alarm/raspi_ip [email protected]:/home/user/

but I am not sure if this will work tho, because the SSH key allowing passwordless login are stored under /root/.ssh/ and /alarm/.ssh.

I guess my question is: which user and which SSH keys will the script under systemd be using? And if not root, how to make this work?

  • Why not just set a static IP either on the pi or reserved on your router? Commented Dec 10, 2016 at 14:55
  • I don't know if have any power over the router, is this possible with a sky router?
    – Three Diag
    Commented Dec 10, 2016 at 14:58
  • Not familiar with that brand but a quick Google search says yes it's possible Commented Dec 10, 2016 at 15:07

2 Answers 2


You can explicitly indicate the private key with -i. By default, scp does the same as ssh -- from man ssh:

-i identity_file

Selects a file from which the identity (private key) for public key authentication is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files).

I believe those are the default names used by ssh-keygen depending on the value of the -t option.

In short, you can either add -i explicitly, or make sure the key paths are as indicated above.

There is a further caveat: It may not work unless the keys are set mode 600 (i.e., read-write by owner, no access to anyone else). This is how they are when created, but you may want to double check with stat.

Note that there are other methods to accomplish the goal here besides what you are doing -- although I admit to doing something vaguely similar: I have little UDP services that run and respond to broadcast requests with an arbitrary hostname; the corresponding clients add the hostname and IP to their local /etc/hosts file. That's a sort of simplified version of zeroconf, but it's a bit silly in that there's already a proper zeroconf implementation that runs by default on Raspbian, avahi. You can find documentation around for it, and it is possible to use an arbitrary hostname (as in, one that is different from the one in /etc/hostname or comes from the hostname command) with that too, and all common operating systems including those on smartphones have simple clients that will pick it up (although with, e.g. Android, this means literally a port scanner as described below, but those will probably deploy zeroconf as well and list the hostname sent back).

Simply add:


To /etc/avahi/avahi-daemon.conf, then systemctl restart avahi-daemon and you will have a system that can be found via a zeroconf client with the hostname foo.bar.

You can also use a port scanner to find a Pi if you are using the ethernet jack or Pi 3's built in wifi, because it will pick up on the OUI used by the Raspberry Pi Foundation. For example:

nmap -sT -p22

Will scan a LAN with that subnet mask for nodes and show whether port 22 (the SSH port) is active. Even if you aren't using one of the built in NIC's that would be a big clue unless you have a lot of computers on the network running an sshd server.


As it turns out, the systemd service under /etc/systemd/system/ are launched by root, hence allowing root passwordless login works.

The real issue I had was getting the service/script to be launched after the network is up, which I solved by restarting 30sec after failure as in the script above.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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