Hi all,
I am close to getting ssh launched on my remote host after reboot.
But the only way I get ssh to work on the remote host is to first log in
to my account on the remote host, then the local machine can use ssh.
I am using opensuse 15.1 on the remote host.
The local host uses mint 19.3. Thanks for any help.
What exactly “cannot use” means? Paste here full commands and their (presumably, error) output when it does not work.
Like @avidjaar says.
And I do not understand it very good.How do you suppose that ssh is run on the “remote host”? Normaly someone first logs in before one can call ssh. And where does that remote host then try to connect to with that ssh? To the “local host”. And that "local hosts has a ssh-deamon then running?
In short, I do not quite get who is the SSH server and who is the SSH client. Or are they both server and client?
Ok. Here’s more details of what I want to have happen. I have 2 desktops. I would like to have one of those desktops (#1) in a different room NOT hooked up to keyboard or monitor. The other desktop (#2) is in my room hooked up to keyboard and monitor. I would like to reboot #1 and use #2 ssh to connect to #1 after the reboot. Then I can run a vnc session remotely to #1. Right now I am able to do this ONLY after I log into #1 using a keyboard and monitor. Right now I get this message after a reboot on #1:
[garyj@linux-mint] % ssh garysj@10.0.0.103ssh: connect to host 10.0.0.103 port 22: No route to host
But after I physically log into #1 I am able to do a successful ssh to 10.0.0.103?
To me it looks as if you are using Network manager on your SSH server system. And you then have not configured the NIC as a “system” configuration (ot how that is called, I do not use NM). And thus the network only comes up after a user logs in. That is the basic function of NM. Either configure as a “system” connection (which will then connect at boot) or use Wicked.
Just a few remarks.
I interprete your question now that you want to start sshd on your second/remote system, not ssh. It is very confusing if you mix up the server program with the client program.
When these are both desktops that are not carried around to different networks (like e.g. a laptop that you take to the retaurant, the airport, etc.) I would not use NetworkManager, but Wicked.
When it is a sort of computer room system, this is the more clear to me: I would always use Wicked (well, I nowadays go for systemd-networkd for such systems, but that is a bit different).
Thanks hcvv, I will try these suggestions. Makes sense what you said.
If you are using NetworkManager you can do a quick check about the connection details. For instance by issuing (as superuser):
# nmcli connection show <your connection ID>
the result should read as:
connection.id: <your connection ID>
<snip>
**connection.autoconnect: yes**
<snip>
**connection.permissions: --**
<snip>
or edit the connection with the GUI editor in your desktop or with:
# nmtui
so that “Automatically connect” and “Available to all users” are both checked.
If that works, you may choose to stay like that or switch to wicked as you prefer.
> systemctl list-unit-files | grep -i 'ssh'
sshd.service enabled
>
# systemctl status sshd.service
● sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2020-04-27 08:05:08 CEST; 3h 17min ago
Process: 2172 ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS (code=exited, status=0/SUCCESS)
Process: 2151 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
Main PID: 2180 (sshd)
Tasks: 1
CGroup: /system.slice/sshd.service
└─2180 /usr/sbin/sshd -D
Apr 27 08:05:08 xxx systemd[1]: Starting OpenSSH Daemon...
Apr 27 08:05:08 xxx sshd-gen-keys-start[2151]: Checking for missing server keys in /etc/ssh
Apr 27 08:05:08 xxx sshd[2180]: Server listening on 0.0.0.0 port 22.
Apr 27 08:05:08 xxx sshd[2180]: Server listening on :: port 22.
Apr 27 08:05:08 xxx systemd[1]: Started OpenSSH Daemon.
#
Have you, on the remote system, enabled the SSH Daemon systemd service?
Henk, not exactly true:
- If the machine has a physical Ethernet cable connection to the LAN then, Network Manager will connect at boot time – the Ethernet cable is by default a “system” connection and, therefore, it doesn’t need any keys or “secrets” …
- If the machine doesn’t have a physical Ethernet cable connection and, it only has a Wireless connection, then, either, Network Manager uses the Wireless “secrets” in the system wide configuration file (which ain’t world readable) or, it uses the “secrets” in the user’s password wallet – the WLAN fires up when the user logs in.
- If the machine has a physical Ethernet cable connection and, it also has a WLAN interface, then, when a user logs in, there are, normally, 2 LAN connections setup by Network Manager – the one via the Ethernet cable activated at boot time and, the other via the WLAN …
Basicaly a good question. My deductions:
- Like you I assume that the OP means sshd when he says ssh.
- The OP reports that sshd works as a user is loged in in the server!
- My conclusion is that the sshd.service is configured correctly to start on network connection.
- My second conclusion is that the network connection only starts after log in of a user.
- This leads me to assuming NetworkManager is used in it’s role of providing a loged in user with the network connection of his/her preference (the role for which it was designed) and not to establish network connection at boot.
Cure:, either tell NM to make this a connection “automaticaly” “for al users” as @OrsoBruno explains in detail, or switch to Wicked.
Sorry, trhis came to late for my last post above :(.
In any case, reading the report that login on the server is needed for sshd to work, I still think it very likely that it is NM (and after your post above, that no cable is used).
In any case, as an old hand, my preference is to use Wicked for systems like that. And maybe also for his other system, that also seems to be a desktop that is never moved to another network.
BTW, to be honest, I do not even use Wicked anymore on such systems, but systemd-networkd. It does just what is needed: set-up the NIC with IP address/netmask and add the default router. Nothing more, nothing less.
Yes, but, for the wireless case, a little bit more is needed:
- The “wpa_supplicant” package – <https://wiki.archlinux.org/index.php/Wpa_supplicant>.
- And, once the WLAN “secrets” have been setup – <https://wiki.archlinux.org/index.php/Systemd-networkd> …
That is why my advice is stil: Wicked. The negative side of it is that I do not use Wicked any more and that giving advice on how to use it must be done from memory, not from checking the YaST module (it will correctly refuse to do anything usefull on finding something else is already in use)
For the WLAN case, at system level, I would tend to suggest Network Manager because, the user interface (provided the user knows the “root” password) to setup the system wide WLAN “secrets” is quite simple and, probably less prone to error and, by default, relative secure …
I am fully aware of the fact that using Wicked even for Wireless in a desktop/computer room situation might be seen as old-fashioned. I have however good experiences by configuring Wifi with Wicked using YaST. As system manager I do not like to encourage any “normal” user (inclusing my person) to ever bother with network configuration and that includes the NM icon on the desktop.
You can also do what I did.
I autologin to the remote system but have the screensaver set to 1 minute and lock the screen.
If it reboots - I don’t have to logon to get wifi with network manager.
in the file /etc/sysconfig/displaymanager change the login from “” to the user you want.
## Type: string
## Default:
#
# Define the user whom should get logged in without request. If string
# is empty, display standard login dialog.
#
DISPLAYMANAGER_AUTOLOGIN="user"
To me it looks like a very intricate way to not use the correct solution: connect the system at boot.
But when you are happy with it.
That is not true. It happens automagicaly, but that does not mean that you (whatever user that may be) do not login.
I don’t have to manually login to the remote machine to get wifi on a server which was locked in a secure room - display manager does it for me is what I meant, so I do not have to get to the keyboard and select my username and type my password. Corporate IT folks controlled the updates and did the init 6 remotely and I had to wait until I could get access again to the machine. I wish I could have replaced the dead ethernet adapter but no open slots but it did have builtin wifi. Corporate folks glued covers on the USB port to keep unauthorized parts from being attached or I would have attached an USB ethernet adapter to it.
Thanks OrsoBruno for this. I will implement these fixes as soon as I get my USB WiFi adapter working. Murphys Law again 