Is a keyboard and monitor needed for initial startup?

Excellent question, and very relevant to my interest in Rpi clusters.  "Fresh out of the box" configuration over ssh would mean that the entire cluster setup can be automated through scripts, whereas if the first time requires video and keyboard/mouse to be connected physically to each board then the process would be partly manual and significantly more painful.

A bespoke SD image could easily be created with the necessary config on the Linux side of course, but it still leaves the question of whether there is something in the GPU boot that requires the physical devices once.

In these early days, the available SD Card images are very few and unlikely to do exactly what people want without loading some apps and doing some config.

Building your own custom SD Card image for a cluster or other such reason would be very easy and make the most sense to me.

If this question more about accessing a single Pi because you have no monitor, then I think it will be possible because I have seen a SSH server loading up when the Pi boots. I haven't tried it myself, but will have to give it a go next week when I get a chance.

I personally like working with "diskless clients". That means I boot machines over the network. I can alter their config even when the machine is not working. I just have to have one reliable server that can serve the root filesystems of the diskless clients. My fileservers are like that. They hold the big data-partitions, but not their own root.

Working with a RPi is very similar, but now you edit the config on the SD card. You just have to have a machine that can mount the SD card and edit the configuration any way you want.

Indeed, but the OP's question was whether ssh access was available for the initial startup in the default images.  We already know that ssh is available later, that goes without saying.

Diskless operation (thin clients) and headless operation (autonomous use or servers without HIDs) are more or less opposite configurations.  Once Rpi is in plentiful stock, I have direct uses for both, servers galore and thin clients in places like the kitchen to give good access to recipes.

What I'm trying to say, is that you pop it in, see what happens. If it doesn't provide you with the ssh access you want, then you put it in your PC, modify the SD card to activate the ssh deamon by default and you pop it in again.

If you really want it on your INITIAL boot, you should pop it into the PC first and make sure it's activated. As the difference is 2 minutes at most, I suggest you try first....

Actually distributing the OS images while having an SSH daemon activated is a security risk. The passwords are well-known. So I could have a daemon on the network (on a RPi?) that looks for booting RPi's and hacks them before the user behind the keyboard has a chance to enter their credentials. Then you'd have a hacked RPi, with say a backdoor installed. Of course reimaging the SD card is easy.

Remember when windows machines needed to connect to the internet to download (malware-protection) updates? And the download time was longer than the average time before the first infection with malware?

That is why the distribution images should NOT enable ssh access by default. If you want/need that, the procedure should be that you modify the login credentials and enable the ssh daemon at the time you prepare and image the SD card.  A tool to do that will surely be written once the RPIs are in the field.

The security risk appears only if a brand new Rpi is placed on the Internet directly and preconfigured with routing to a default gateway enabled.  That would be pretty foolish, and nobody has recommended that.

Instead, a sensible configuration would work in the same way as hundreds of millions of commodity routers work today, being preconfigured with a default password but the networking restricted to local subnet access only and an RFC1918 address.  This is nothing new, and provides no risk at all.

The security risk appears only if a brand new Rpi is placed on the Internet directly and preconfigured with routing to a default gateway enabled.  That would be pretty foolish, and nobody has recommended that.

Instead, a sensible configuration would work in the same way as hundreds of millions of commodity routers work today, being preconfigured with a default password but the networking restricted to local subnet access only and an RFC1918 address.  This is nothing new, and provides no risk at all.

The situation that I was thinking about was a room full of 'pi's that are available to students. Like in boys between the ages of 12 and 16.

About the routing, many networks are configured to provice DHCP. It is very convenient for DHCP to configure things like a gateway correctly. On the other hand many home installations indeed have NAT happening at the gateway which would mean you're safe from attacks from outside.

I don't agree with your "no risk at all" statement. It provides a risk, but acceptable to most people.

Hooking up your brand-new 'pi:

• to a home network where YOU control everything that goes on: Safe.
• to a room full of 'pi's where students have access: not safe
• to a university network where DHCP clients get globally routable internet addresses: not safe.

Microsoft thought you'd be hooking up your Windows98 machine to a private network. So, it would be convenient for the printer service to be open to the local network, right? What harm can come from that? Turns out that a small percentage, but still lots of people end up being directly connected to the global internet. So: Although convenient for a percentage of people, way more inconvenient (they got hacked) for another percentage  of people.

People making distributions should be careful in makeing things convenient. It is easily "too convenient" in a small percentage of cases.